Re: Some half-baked thoughts about cookies.

On Wed, Aug 15, 2018 at 6:37 AM Mark Nottingham <mnot@mnot.net> wrote:

> Hi Mike,
>
> On 14 Aug 2018, at 8:38 pm, Mike West <mkwst@google.com> 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.
>
> This reminds me very much of a proposal from Apple that was floating
> around a few years ago. Do you remember the source? I can dig around if you
> don't.
>

I don't remember it. I'd love to take a look if you can dig it up!

I think the pushback at the time was that it didn't have significantly
> better privacy properties as compared to cookies. Looking at what you've
> written, it seems like you're trying to "reset the defaults" for cookies
> more than anything -- i.e., make them origin-scoped, secure, etc. out of
> the box.
>
> Personally I think that's a worthy goal, for the same reasons that you
> point out at the top of the doc; current security mechanisms are getting
> abysmally low deployment.
>

I don't believe this proposal significantly changes the technical privacy
story (except insofar as it locks the identifier to encrypted connections,
which mitigates their usefulness for pervasive monitoring). I do think it
resets the defaults, as you say, and I think that's quite valuable.

By it's nature, this is a very long-term process (much as the transition to
> HTTPS is, although hopefully less painful). It's probably premature to
> speculate about how exactly the transition will happen (in terms of
> incentives), but *some* sense that it's at least possible would be good.
> Maybe the HTTPS transition is proof enough.
>
> Overall, I personally think this is worth pursuing, as long as we
> understand it's a very long-term thing.
>

That's the way I'm looking at it. I would like to create a thing that we
collectively think is better-suited to managing HTTP state today, and point
people to it as a better option. Over time, we can encourage that option's
usage, but I agree both that this is a long-term play, and that the
encouragement mechanisms are currently speculative.

One specific thing -- requiring a single token that's generated by the
> client precludes a server using this to distribute state to load balancers,
> CDNs, etc. for various purposes, which is a fairly common pattern. I
> suspect that the current design is going to create friction against
> deployment as a result; it effectively places all state at the origin.


That might be the case.
https://github.com/mikewest/http-state-tokens#server-controlled-values
hints at an alternative that would allow the server control over the
token's value. I prefer to put it completely under the client's control, as
that gives some nice guarantees around the lack of interesting information
in the identifier itself, but I recognize that it's a big shift.

-mike