Re: Some half-baked thoughts about cookies.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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. 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. 

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". 

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. 
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. 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. Like Mike pointed out, it can require TLS to send the ID, 
which helps with pervasive monitoring. 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. 

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.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEvjoqZTaQXUCffv5tfUgJiEo2QCsFAlt1OAQACgkQfUgJiEo2
QCtOYRAAqSw6KmQWO4mbqTUalVvwskYRfuTd5Q1Qsjqy8DLx4NJ46/TRDGVHv1fq
EfAjY8O2/oIMzNRLdJlISMMYzh/En6Iafr5IxTlzuuhtMqjw//PWiRdooeMeiUeb
gNV+Z7HQe6afJFWNAm1yFrtj/yr14W1DBJjqe6w6TZA7OQHKNNV1wB2EggpjH0th
pYp9qLDFeonk9z9mpzGfEcM0h01Zuzw6frh+vEKZb4MKGK9qwXQat343rh1dsE57
CwXXI9MvwqIhvS7ThZnt1+FmZ9xrCzQ+Pn2zPv6o9XYeWV8vuNg/5AA5XwZ5y1MO
VstR1OKYi4bZ77vOGXsypW8EImc3+5cqHJ5/TKydC+fMMdlv2d73lmh3gk8TDH+m
cGij89IpjKaDYC/iPF3oGf2jaYNDVbBTilKsSUTEf9tbJ6ptQ4mwtjP1zWyMx8p7
niluggoZvi52ljH5nqLgsvWNn6NAGWIW99isuqdrt/nyH4NyKgl1yj4SWTjHZsQ/
gL0tKaaqqFPw2yaPBPyWr7PvW2v/fFboLi+uPxRhYwWGyyCu1r7VM+VWgJRVBBl8
SNMsG4j0gdN/hZqO/rt5bvVj7OXePi9TIDp7xuRHRNJjgXvHOI50NK+0gUwZlxpg
6uB2oMo5BbSwTGUTNLUPTN5ulbKsLWz90dIQU2OXr0+WU8fZdVc=
=gWd4
-----END PGP SIGNATURE-----

Received on Thursday, 16 August 2018 08:38:37 UTC