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

> Is "we" here a royal "we" or any particular "we"? ;)

Sorry that's the royal we. Labeling in general is not possible unless we can pick the specific inference (i.e. ad selection) and say whether it was a success or failure (or maybe something a little finer grained).

> More to the point, I still don't quite get it why 64b is exactly needed. I don't want to be overly picky (despite I maybe am a bit), but while I understand your reply to 2.2, I don't get it where those 64b come from.

64 exact bits aren't fully needed, but you basically want a scheme that lets you avoid too many collisions (i.e. the scheme is "event-level" where we can pinpoint a specific event like an ad-click and label that). We could probably reduce this down, but as you probably know, anything >= 33 bits can identify an individual on earth, and you likely need a lot less to identify a user on a particular site in a given 2 day window, so we only really start getting meaningful privacy protections if the impression metadata is reduced below 32 bits. However, as soon as you start getting into a regime where your click ids are colliding a lot (you are using the full bit space), utility decreases a lot.

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.

> But I wonder if you could not discuss/agree on any convergence in particular. Because at the moment it seems we're exploring two different specs that deal with indeed pretty similar tasks. I am not sure if this kind of enrichment makes web platform a better place.

Yes I think we should try to align on convergence. I think many of these API differences can be resolved by aligning on API surface, and having some sort of "configuration" advertising the valid inputs. For instance, a UA that wants the impression metadata to be 6 bits can use the same attribute but advertise that they only accept 6 bit input. Similarly, the reportingdomain could only accept e.g. publisher or addestination domains for UAs that want those guarantees.

cc @johnwilander

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