Re: Some half-baked thoughts about cookies.

Combining Stephen's and Amos' responses here:

On Thu, Aug 16, 2018 at 4:31 AM Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 16/08/18 10:20, Stephen Farrell wrote:
> >
> > Hiya,
> >
> > On 14/08/18 11:38, Mike West wrote:
> >> Hey folks,
> >>
> >> https://github.com/mikewest/http-state-tokens suggests that we should
> >> introduce a client-controlled, origin-bound, HTTPS-only session
> identifier
> >> for network-level state management. And eventually deprecate cookies.
> >>
> >> I think there's a conversation here worth having, and this group has
> >> thought a lot about the space over the last decade or two. I'd
> appreciate
> >> y'all's feedback, both about the problems the document discusses with
> >> regard to cookies as they exist today, and about the sketchy proposal it
> >> advances about managing HTTP state in the future.
> >
> > I'd be very keen to see HTTP state management become more privacy
> > friendly, but I don't see how this moves us in that direction tbh.
> > Be happy to be wrong though.
>

As noted in my response to Mark, I don't think that this proposal is
technically different to cookies with regard to privacy (modulo
encryption). It has better security properties, which reflects my
underlying goals.

In some discussion at Dagstuhl, some folks suggested that there may be
regulatory impacts to taking control of the identifier away from the site
and giving it to the user agent, and to the suggestion that the user agent
create a purposeful story around the identifier's goals. Rigo Wenning
spelled out his views on that subject in
https://github.com/mikewest/http-state-tokens/pull/2. I am neither a
lawyer, nor a regulator (nor do I actually agree with everything Rigo wrote
in that PR! :) ), so I don't know how compelling that story actually is,
but it does intuitively make sense to me that splitting "authentication"
and "advertising" into distinct things that can be manipulated separately
would be valuable.

> - new unique IDs for clients seems like a bad plan (64 bits seems way
> >   too many from a re-identification POV), the idea of the web UA just
> >   automatically spewing those out seems particularly misdirected, if
> >   that is the idea
>

It's non-obvious from the proposal doc, but the UA would only "spew"
identifiers for same-site requests, given the defaults. It would not spew
cross-site identifiers until the relevant origin was visited in a same-site
context and explicitly declared its tokens as being deliverable cross-site
(at which point the UA could make some decisions about how to handle that
declaration). That's not nothing.

> - I don't see how this'd incent web UAs nor web servers to behave in
> >   more privacy friendly ways, at best it seems neutral
>

As above, there are distinctions around the margins, but I agree that it's
~neutral from a privacy perspective.


> > That said, I do support discussing these ideas, just not (what I think
> > is) this particular less-baked plan in it's as-is state.
>

I'm not dead-set on this proposal as-written. :) I hope it sparks some good
conversation, and that we end up with something better in the long run.

It moves us all one step closer to the situation where the security vs
> privacy model scoped at just session-ID values can be reasoned about and
> tightened up far better than the free-for-all values Cookie may contain.
>
> Unfortunately Cookie are so weak in regards to those properties that a
> session ID performing what is actually current practice get thrown out
> immediately as terrible design from either security or privacy viewpoint.
>
> As you say, its a neutral proposal. That itself places it on the losing
> side in the perfection-or-nothing battle.


I agree with this assessment, and I'd suggest that we're unlikely to
practically deploy perfection (assuming that we can even define it!). This
proposal feels radical in some ways, and would have some interesting
impacts if deployed. I look forward to exploring those with y'all. :)

-mike