Re: draft-west-cookie-prefixes-05 comments

On Fri, Dec 4, 2015 at 5:25 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> Is this a risk that can be mitigated by selecting another character,
> say '*' or '~'?


I'd first ask whether this is a risk worth mitigating. I'm not sure that it
is. :)


> Just looking at the definition for token, I see: !#$%'*+.^|~ as all
> being valid.  Obviously, RFC 2068 attached the semblance of a semantic
> to '$', so that might be a bit of a mistake, as noted


Right, we can't use "$" as a leading character; I've already gotten reports
from 3 developers who have tried and failed to get that working with their
cookie-parsing code (one at a Large Californian Internet Company). That's a
pretty high failure rate for a feature that isn't actually shipping yet. :)

On 4 December 2015 at 01:47, Eitan Adler <lists@eitanadler.com> wrote:
> >> I'd be interested in hearing about the use cases for other prefixes,
> but I'm
> >> hopeful that we won't need/want to add many prefixes. The two defined in
> >> https://tools.ietf.org/html/draft-west-cookie-prefixes seem to close
> the
> >> most pressing gaps.
> >
> > Ideally we won't need any other prefixes.  That said, the RFC should
> > be explicit about this.
>

What would you like the RFC to say in this regard?


> > In other words its the difference between
> >
> >  - All cookies that begin with "__-" are special
> > vs
> > - Some cookies that begin with __, __SECURE, and __HOST, have special
> > meaning, but most don't.
>

Another way of phrasing this is "All cookies that begin with `__SECURE-`
and `__HOST-` are special." I'd suggest that this rule is fairly easily
understood.

> Another concern is that in the unlikely event we will want another
> > prefix other than SECURE or HOST we won't need to scour the web to
> > ensure that the newly defined word isn't already used.
>

Honestly, I see this as a benefit. Adding prefixes should be hard, and we
shouldn't do it often. Asking whether it's worth it to scour the web for a
suitable prefix seems like a totally reasonable hurdle to place in front of
implementers.

Hurdles to the side, I also worry a bit about breaking applications that
use strangely named cookies. This is a miniscule risk, but Chrome's
telemetry system certainly has blind spots (most notably in The Enterprise,
where folks turn off any feature that looks like it might send remotely
interesting data to Google as a matter of course); I imagine Mozilla's
system is similarly hobbled. Given the known unknowns, I would prefer to
make the smallest change possible.

-mike