Re: Some half-baked thoughts about cookies.

On Tue, Aug 14, 2018 at 2:07 PM Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> --------
> In message <CAKXHy=
> d6EaSO-SKRTEVDWfBcgf_FoFBj2gN4xmrR5q79yxSpXw@mail.gmail.com>, Mike West
> writes:
>
> >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.
>
> Well, pretty much exactly what I proposed early in the HTTP/2 cycle,
> so I'm all for it.
>

Oh, great! Can you point me to the proposal? I'd love to read it.


> I would dedicate the top bit of the session-id, still under client
> control, to tell the server if this should be considered a ephemeral
> or persistent session, to make it easier for the server to garbage
> collect state.
>
> If the top bit is zero, this session is ephemeral and when the
> browser leaves, the session ceases to exist.  UX wise this would
> typically be browsing in "private mode" or if "do not track" is
> set.
>

Hrm. Some browser vendors attempt to hide the fact that a user is running
in "private mode". Advertising it via the top bit of the identifier might
butt up against that goal.

But assuming we ran with this model, what heuristics would you expect
servers to use when cleaning up session identifiers that are no longer in
use?

PS:  64 bits is not enough for everybody, in particularly not when
> they are randomly generated by less than perfect implementations.
> Make then 128 bit from the start.
>

After a discussion on Twitter
<https://twitter.com/patricktoomey/status/1029318457957871616>, I
ended up bumping
this to 256 bits
<https://github.com/mikewest/http-state-tokens/commit/2fc6f828c1641eaf78bf85a64aea1ef7507647c1>.
I think there's probably more discussion to be had around exactly the right
length and whether that's too long, but I agree that 64 isn't enough.

-mike