Re: [w3ctag/design-reviews] Event-Level Click Conversion Measurement API (#418)

Thanks a lot for the updates. My following input.

> In this case in the design we chose 64 bits because we felt moving below 33 would prove tricky utility wise due to collisions, and reducing the 64 bits to some number > 33 didn't really improve privacy at the margin.



So it seems to me you acknowledge that size (erm...) matters, which is sensible indeed, but on the other hand we're all also aware that much less than 33b is sufficient for tracking. In this case, the 64b is closer to "just a bit more than we really need", or closer to "just right", and if so, why? Sounds a bit arbitrary to some extent still. So if this is an arbitrary choice, why not, say, 60 bits, or 1024 bits, or no limit and leaving it to the browser? Which would mean that for example Safari would have its bit length, and other browsers, maybe other numbers (since it seems both UAs go for different numbers anyway).

There is, of course, also the report uri attribute.


> > But I wonder if you could not discuss/agree on any convergence in particular. 
> 
> Yes I think we should try to align on convergence. [...]

Indeed would be great. I don't know, however, how such co-op should start. Is there any progress on starting the conversation somehow, somewhere?


@michaelkleber 
> Putting the browser in control of the rate, entropy, and noise is also a "meaningful privacy protection". And sure, blocking information flow altogether is of course "more private", but it also doesn't solve the problem at hand.

I see your point. Though I actually wonder what is the main point here. Solve cross-site tracking potential? Civilise tracking a bit to give compelling arguments for softer anti-tracker blocking, since you mention above blocking information flows?



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/418#issuecomment-561733539