- From: Yoav Weiss <notifications@github.com>
- Date: Thu, 26 Jun 2025 02:41:01 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/878/3007858204@github.com>
yoavweiss left a comment (w3ctag/design-reviews#878) We discussed this on the TAG call and we don't have concerns with this particular API. Its use of differential privacy explicitly avoids exposing information about any particular user, which is great. One point which may benefit web developers would be if the spec mandated or recommended a certain epsilon value across different implementations, and that would allow developers to debias their metrics across different implementations. With that said, the fact that the value is reflected using randomizedTriggerRate would still enable developers to handle differences between implementations if those arise. At the same time, there's some concern related to fingerprinting and web performance APIs in general. Slow users (through various dimensions of slowness: network latency, bandwidth or CPU) are likely to be slow across different sites, which can contribute fingerprinting bits to would allow for their persistent re-identification across sites. This information is available through [ancillary APIs](https://www.w3.org/TR/privacy-principles/#dfn-ancillary-apis-computed-from-existing-information) and [non-ancillary APIs](https://www.w3.org/TR/privacy-principles/#dfn-non-ancillary-apis) alike, and hence it seems unlikely that the situation can be improved. At the same time, it could be good to mention that concern in the relevant APIs' Privacy and Security sections. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/878#issuecomment-3007858204 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/878/3007858204@github.com>
Received on Thursday, 26 June 2025 09:41:05 UTC