Re: Some half-baked thoughts about cookies.

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.
> 
> Things that make me think that include:
> 
> - 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
> 
> - 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
> 
> 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.
> 

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.

AYJ