Re: _HttpOnly cookie prefix?

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

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!

Received on Monday, 16 June 2025 21:16:38 UTC