Re: _HttpOnly cookie prefix?

Thanks!

On Mon, Jun 16, 2025 at 11:19 PM Chris Fredrickson <cfredric@google.com>
wrote:

> This comment is orthogonal to this proposal (by which I mean, I don't
> intend to block the proposal on solving this), but I noticed that this
> proposal wants, in principle, to convey a single boolean signal in the
> cookie name (i.e. whether the cookie was marked HttpOnly or not). But due
> to the fact that prefixes don't compose well, Yoav was forced to create two
> new prefixes instead of one (and it would have been worse if the new
> prefixes didn't happen to require the Secure attribute).
>
> I think this shows the current prefix-based approach is hard to extend,
> and if we wanted to add another prefix (e.g. __Unpartitioned-, just off the
> top of my head), we'd actually have to add a handful of variants, due to
> the combinatorial explosion.
>
> I think this is solvable if we design a prefix system that's
> order-insensitive. My gut instinct is to want something like:
> __Prefixed(Host,HttpOnly,Unpartitioned)-mycookie
>

> Some of those characters are forbidden in cookie names (which are tokens:
> https://datatracker.ietf.org/doc/html/rfc9110#name-tokens), though, so we
> could do something like this instead:
> __Prefixed!Host&HttpOnly&Unpartitioned!-mycookie
>

A potentially simpler/shorter option could be: __Host__HttpOnly-mycookie
(where __HttpOnly__Host would work similarly, and we could also compound
future prefixes as well, e.g. __Unpartitioned__HttpOnly).


> I realize there's going to be a lot of details to work out on this
> regarding backward compatibility, forward compatibility, security,
> particulars about the spelling, etc. But it might be nice to make the
> system more extensible now, rather than the next time someone tries to
> extend it.
>
> Curious if anyone else has thoughts!
>