- From: Charlie Harrison <notifications@github.com>
- Date: Mon, 09 Dec 2019 12:48:48 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Monday, 9 December 2019 20:48:50 UTC
Hey @lknik , thanks for the response. > 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? I agree this is an arbitrary number. We picked it for two reasons: 1. It is large enough to prevent collisions, which improves the utility. We wanted data to be "event-level" at the impression side. 2. It is small enough that it won't be misused as something other than a click identifier. For instance, we didn't want people putting arbitrary text in there, and relying on that behavior especially in the event that browsers in the future would want to ramp down the maximum. This is why we didn't like "no limit". 60 bits vs 64 bits I believe makes no practical difference to utility or privacy, so we went with the rounder number. -- 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-563431480
Received on Monday, 9 December 2019 20:48:50 UTC