Re: _HttpOnly cookie prefix?

On Tue, Jun 17, 2025 at 7:06 PM Rory Hewitt <rory.hewitt@gmail.com> wrote:

> > 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 raised this as a concern in a prior email several months ago:
>
> "I'm not sure how the various __Secure-* and __Host-* cookies would play
> with __HttpOnly-* cookies proposed by Yoav. Would this end up with cookie
> names like "__HttpOnly__Secure-string"?"
>
> I like Chris's idea of having a generic "__Prefixed{strings}" format, but
> surely the actual double-underscore is itself the prefix? do we need more
> than that?
>
> IOW, can't we simply define it as:
>
>     __{unordered-case-sensitive-prefixes}-{string}
>
> where {unordered-case-sensitive-prefixes} is one or more of the following *in
> any order*:
>
>     *Secure*
>     *Host*
>     *Http* (I prefer this to "HttpOnly', simply because for some
> reason we've gone for case-sensitive cookie names, and if we're talking
> CamelCase prefixes, then that can confuse things)
>     *Unpartitioned* (Chris's 'dummy' name)
>     ...more to come...
>
> So all of these would be equivalent:
>
>     __SecureHttpUnpartioned-myname
>     __HttpSecureUnpartioned-myname
>     __UnpartitionedSecureHttp-myname
>

While I like the terseness and the smaller name, this would be harder to
parse correctly and efficiently.
It could also be an issue when it comes to forward compat, where
user-agents will not be able to ignore restrictions they don't yet support.

Maybe introducing a single chat delimiter isn't awful?

e.g. `__Host_Unpartitioned-name`


> This would require some tinkering to ensure that the current rules that
> apply to e.g. "__Secure-" and "__Host-" cookies can ensure that e.g. a
> cookie named "__HostSecureUnpartitioned-myname" can't be created with a
> Path prefix other than /, since that would clash with the existing "__Host"
> cookie definitions. And, of course, the existing double-underscore cookie
> naming would have to be ported in a backwards-compatible manner.
>
> The nice thing is that just using a double-underscore with 1+ unordered
> prefixes is simple and keeps the name of the cookie as small as possible.
>
> Rory
>
> On Mon, Jun 16, 2025 at 9:44 PM Yoav Weiss <yoav.weiss@shopify.com> wrote:
>
>> 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!
>>>
>>
>
> --
> Rory Hewitt
>
> https://www.linkedin.com/in/roryhewitt
>