-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC6265bis: should __
as a prefix be reserved?
#2264
Comments
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. |
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. |
I'll look into getting some numbers. I'll also leave this in scope for the moment, but we may end up deferring it. |
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). |
If we do this, we need to be careful about what "reserved" means here.
If |
Very good points. Of course my argument can also be turned the other way around: it worked fine to introduce |
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.The text was updated successfully, but these errors were encountered: