Re: Some half-baked thoughts about cookies.

Hi Rigo,

(This topic maybe belongs more in the other thread?)

On 16/08/18 09:38, Rigo Wenning wrote:
> Stephen, 
> 
> On Thursday, August 16, 2018 9:53:48 AM CEST Stephen Farrell wrote:
>> Hiya,
> 
> long time no talk. Normally Mike and I have near to insurmountable 
> differences over near to all aspects of web technology :) This time 
> it seems different to a certain extend.
> 
> Unique IDs remain uniqueIDs. AFAI understand (or to me), this is not 
> a proposal to stop tracking by uniqueIDs. And in the very large 
> picture, there is no big difference as we replace UniqueIDs by 
> UniqueIDs. 

Not sure I agree there, if UAs by default sent a different
64 bit randomly generated ID to each origin and kept those
IDs for a long time, that seems worse to me than the current
situation. (I'm not saying that's Mike's proposal, but
just disagreeing with your "no big difference" statement.)

> But the proposal offers some interesting properties.
> 
> We need uniqueIDs for stateful browsing and many other purposes. I 
> don't think this proposal will mean one can technically stop abusing 
> uniqueIDs for bad things. In this case, it should use anonymous 
> credentials and the things Jan Camenisch and David Chaum suggest 
> since a long time. 

I'm not arguing for something that'd prevent all abuses. I
am arguing that since we know abuses will occur, we need to
consider the privacy aspects of that and try to do better
than the current situation.

> The attacking scenario is a different one. If we assume that the 
> service follows the purpose given to the UniqueID (behave as 
> stated), the proposal can help further data self determination. This 
> is the "data protection" aspect, rather than the "privacy" US aspect 
> that looks into secrecy or access control. Data protection looks 
> more into "dossiers". 

I'm not following that. What is "data self determination"
and I don't get what you mean by dossiers.

> This should not replace cookies. It is just a new attempt (P3P was 
> the last one we tried) to distinguish between good IDs and bad IDs. 

So RFC 3514 then? ;-)

> And my suggestion is NOT to start with "authentication" and 
> "advertisement". My suggestion is to start with "authentication" 
> only. This has more social merits than technical merits. 

I've no problem with the idea of trying to address HTTP state
in a way that doesn't set out to try help advertising. But I
think we do need to consider unintended but known possible
(ab)uses of any new HTTP state mechanism.

> The 
> "authentication" token will have an expected use and behaviour. In 
> regulated environments like the EU, the purpose can be enforced. By 
> minting its own uniqueIDs, the browser has more control over the 
> semantics of it and when to send or lie. 
> 
> This will carve out a space where uniqueIDs are not considered 
> harmful. 

Possibly, yes. (Though s/uniqueIDs/a new HTTP state mechanism/)

> Like Mike pointed out, it can require TLS to send the ID, 
> which helps with pervasive monitoring. 

That helps with PM from intermediaries, yes, which is a fine
thing. There is still PM done by servers e.g. for commercial
reasons. Again, I'm not arguing that a new HTTP state mechanism
must solve that problem, but that we need to take it into
account and try do better than today.

> There are many more little 
> improvements possible this way. As the ID is on the user agent, it 
> rather considers the user while a site (cookies) will consider more 
> its own needs. 

Bit of a nit but I'm not sure that the user's and the UA's
goals are always the same here. The point being that the
requirements for a new HTTP state mechanism may not be the
exact same for users and for UA developers. Asking that we
try do better wrt privacy I hope makes us consider that in
our analysis of a new mechanism.

Cheers,
S.


> On the long run, more 80/20 cases can be taken up in 
> standardization, like "advertisement" or "audience measurement". But 
> I wouldn't start with those as it makes the content of the 
> specification too contentious to go through. DNT was a nice proposal
> and suffered especially from the clash between certain branches of 
> the industry. "Authentication" only could avoid that here. "Audience 
> measurement" is also not too contentious but far from unanimity.
> 
>  --Rigo
> 
>> 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 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 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.
> 
>> 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.
> 
>> Cheers,
>> S.
> 
> 
> 
> 
>