Subject: Proposal: Optional "Purpose" Attribute for Set-Cookie Header
From: João Penteado <[email-masked]>
To: [email-masked]
Date: Sun, 25 Aug 2024 03:06:46 +0900
List-Id: <ietf-http-wg.w3.org>

Hi all,

I'd like to start a discussion about introducing a new optional "Purpose" (or a
generic "Tag") attribute in the Set-Cookie header specification.

The intended use case for this would be for servers to automatically signal to
the client's browser the specific functionality provided by the cookie being
set. IANA could maintain a registry of standardized purposes, such as "auth",
"functional", "preferences", "analytics", "error-reporting", "marketing" and
others.

This could be implemented as follows:

> Set-Cookie: id=1234567890; Purpose=auth

The primary goal of this proposal is to alleviate the current UX issues caused
by cookie consent pop-ups, which have become prevalent since the introduction of
the GDPR and similar privacy regulations. Leaving aside the discussion about
whether or not these pop-ups are actually required by different privacy
legislations or if they were their intent in the first place, the fact is that
many websites adopt this behavior nowadays and it is very frustrating. The
idea is that users could set their cookie preferences at the browser level,
potentially reducing the need for repetitive pop-up interactions.

Of course, this proposal hinges on the assumption that servers would be willing
to adopt this standard and honestly disclose a cookie's purpose. I believe this
is a reasonable expectation for the following reasons:

1. Websites that implement cookie consent pop-ups are already disclosing the
purpose of cookies, albeit with a suboptimal user experience. Misrepresentation
could expose them to legal risks. The UX issues are not present in websites not
implementing the pop-ups, so it wouldn't affect them anyway.

2. These websites also care about user experience, as it directly impacts brand
perception, sales, and other business metrics.

Given how widespread and obnoxious these pop-ups have become, I find it
surprising that a similar proposal hasn't been widely adopted yet. If this idea
has been previously discussed and dismissed, I would appreciate any references
to those discussions, as I couldn't find them easily.

I look forward to hearing what other folks in the industry think about this.

Thanks,

- João