Re: Some half-baked thoughts about cookies.

On Fri, Aug 17, 2018 at 5:51 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> On 17/08/18 16:44, Poul-Henning Kamp wrote:
> > --------
> > In message <7999a7ef-cc5e-7d75-df9f-24acbb4a47f7@cs.tcd.ie>, Stephen
> Farrell wr
> > ites:
> >
> >> Not sure I agree there, if UAs by default sent a different
> >> 64 bit randomly generated ID to each origin and kept those
> >> IDs for a long time, that seems worse to me than the current
> >> situation. (I'm not saying that's Mike's proposal, but
> >> just disagreeing with your "no big difference" statement.)
> >
> > How is that worse than sending an opaque cookie,
>
> If it was always sent, with no opt-out. (Again, I'm not
> saying that was Mike's proposal though.)
>

IMO, users must always have the ability to opt-out of sending this
identifier to any entity, just as they do with cookies today. User agents
should likely aim above that bar, but an opt-out is the bare minimum.

It also seems reasonable to either (a) give servers the ability to opt-out
of an identifier which the user agent creates by default, or (b) give
servers the ability to opt-into an identifier which the user agent does not
create by default. It seems to me that (a) is more practical if we want to
get away without letting the server control the identifier's value and
without exposing the value to JavaScript, as the server would otherwise be
unable to bind the initial request with subsequent requests. That said, (b)
is by no means out of the question, and I'm sure we could make it work with
some efficiency loss if that's the direction we end up deciding to run in.

> possibly
> > containing imcompetently protected GDPR-covered personal
> > information for a long time ?
> >
> > At least with a randomly generated ID, you know it cannot
> > leak information on the local machine (hacked/lost/discarded).
>
> True.
>

Indeed.

Thanks!

-mike