Re: Privacy properties of a cookie replacement (was "Re: Some half-baked thoughts about cookies.")

Hiya,

(Sorry for the slow response...)

On 16/08/18 09:56, Mike West wrote:
> Hey Stephen!
> 
...
>> What I'm asking is that, if doing this, we aim for a real
>> improvement in privacy too, and include relevant actors and
>> incentives in the analysis. We might fail to meet that goal
>> of course, but I reckon we really ought try.
>>
> 
> I agree that it would be helpful to spell out the axes along which we think
> cookies need improvement from a privacy perspective. In this thread, I've
> talked about the ways in which this proposal impacts two privacy-relevant
> aspects of cookies:
> 
> 1.  They are potentially delivered in plaintext.
> 2.  They enable third-party tracking.
> 
> I think this proposal has significantly positive impact on the first
> insofar as it prevents plaintext delivery, and minorly positive impact on
> the second insofar as it requires an initial same-site request in order to
> enable subsequent cross-site delivery.

Seems about right (though I'm not sure I yet get the cross-site
details but that's ok for now).

> 
> I'm sure, however, that th> Forking this into a separate thread to focus the conversation.
> 
> On Thu, Aug 16, 2018 at 9:53 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> 
>> On 16/08/18 08:20, Mike West wrote:
>>> On 16/08/18 03:26, Amos Jeffries wrote:
>>>> 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. :)
>>
>> I don't think asking that we aim for a better than ~neutral
>> privacy outcome is fairly cast anything related to perfection.
>> (I'm not saying anyone's being unfair, it's just not particularly
>> useful rhetoric;-)
>>
> 
> I take that point, thanks.
> 
> 
>> I do think we ought try for, and perhaps require, any long
>> term cookie dis/re-placement scheme have better privacy
>> properties than the current miasma.
>>
> 
> I suspect that we'll agree on this, as "better" doesn't seem difficult to
> achieve with respect to the status quo.
> 
> 
>> I fully agree that aiming for better than ~neutral makes a
>> hard problem harder though, and maybe we'd find that there's
>> no feasible approach. OTOH, in one recent case (SNI encryption),
>> we do seem to have made progress despite that problem appearing
>> practically unsolveable for quite a while.
>>ere's a lot more here to discuss, and that y'all
> have thought about the problem deeply over the years. 

I wouldn't claim to ever have had deep thoughts:-)

> For instance, you
> mentioned incentives for UAs and servers to behave in more privacy-friendly
> ways: did you have anything in particular in mind?

Fair question.

What I'd like (but don't know how to get) is something like:

- an HTTP state mechanism that is not likely to be used when
  not needed for managing state
- stateless operation to become a more normal thing, e.g. I'd
  like stateless operation to work more often/better when
  browsing sites with which I don't have a relationship
- a mechanism that is harder to abuse, and where abuse could
  be detected (possibly that last would need an auditor or
  researcher to figure out clever ways to spot abuse)
- and a pony :-)

I think there could be incentives for servers, if the above
was more efficient than the status quo ante, and if they
ended up with higher quality information about the user
agents that actually matter to them, and didn't have to
deal with the chaff from every UA that ever made a connection.
(And the potential costs if that chaff leaks due to some
incident in a server or partner site.)

Similarly, I'd hope reducing stateful operation could be
viewed as a positive by UAs, if it allowed them to render
pages more quickly in enough cases. i.e. if the servers
were incented to play this kind of game for enough content,
then maybe it'd also be attractive to UAs.

I'm not sure how that'd translate into something that
could be used, but perhaps something like: default to not
send any identifier on 1st contact, to start sending short
identifiers when needed (making 'em longer as needed), and
with those identifiers cycled by default (e.g. for new
TLS sessions) with some way that a server who needs to
could spend a bit of effort that'd allow them to know
that a chain of identifiers are from the same UA. (That
starts to sound a bit like the quic connection ID
discussion though.)

If the upshot of all that was that real HTTP state
management was less likely to be used for tracking and
that those wanting to track were left with cookies, and
if turning off cookies worked well more often, then I
guess that'd be a win.

Cheers,
S.


> 
> Thanks!
> 
> -mike
>