RFC6265bis: should `__` as a prefix be reserved?

[bagder]

We have introduced __Secure- and __Host- as prefixes to cookie names in the past, at the expense that existing cookies using such prefixed names would be treated completely differently (assuming there were any).

Would it make sense to "reserve" __ as a prefix in the spec for future similar extensions to avoid such new prefixes to break cookies in use? It could perhaps reduce breakage for future users.

[sbingler]

Interesting idea, do you have any potential new prefixes in mind?

In any case we'd want to get some numbers on how common double underscore prefixing is.

[bagder]

No, it just struck me that every time we "nick" a prefix like this, it potentially ruins someone's cookies. And since we have done it twice in the past, it feels like there is a risk that it will happen again.

[sbingler]

I'll look into getting some numbers. I'll also leave this in scope for the moment, but we may end up deferring it.

[dveditz]

since we have done it twice in the past

Technically once, with two different but related names. I believe at the time Mike looked for cookies using those specific names (to the extent you can, using data from non-logged in scans), but grabbing all "__" names up front seems much riskier. What are the odds someone is using any name like that vs. the likelihood we'll want to deploy this kind of ugly hack again?

Most proposed cookie changes can go right into new cookie attributes. These name prefixes were directly aimed at cookie-shadowing attacks, and once all your cookies are "__Host-..." those are no longer possible. Solving the more general problem of reflecting attributes back to the host (or even a document) is a bigger change and will require a different API (such as was proposed with the long ago Cookie2, or the newer Cookie Store DOM API proposal from Google).

[davidben]

If we do this, we need to be careful about what "reserved" means here. __Host- and __Secure- also relied on them being accepted in existing clients, or else they would have been unusable for servers. Specifically:

1. For clients, we needed a prefix that (next to) no server was actually using, so that we could safely change their semantics without breaking existing servers.
2. However, for servers, we needed a prefix that server allowed to use by existing clients, so that servers could safely migrate to prefixed cookies without breaking existing clients. (Those existing clients would not get the security benefits, but I expect servers would have wanted them to stay working. If not, we could have just invented Cookie2 and not bothered keeping continuity with today's cookies.)

If __ were marked as special, I suspect (2) would not have worked out because some older clients would have treated it differently. And if no existing clients treat it differently, "reserving" the value doesn't actually have any teeth. Just a friendly request in the spec not to make up your own __ names because we might try to squat them later.

[bagder]

Very good points.

Of course my argument can also be turned the other way around: it worked fine to introduce __-prefixes in the past so chances are good that if we need to do it again, it seems reasonable to suspect that it would be possible next time as well.