Re: [docs-and-reports] Principle: user opt-out should be undetectable (#49)

This question or something similar to it has come up in a few different contexts.  Maybe aggregate measurement is sufficiently different from those other use cases, in a way that makes this principle OK here even though it doesn't fully generalize.  Anyway, I'll try to list the analogues we've run into, and I welcome discussion.

1. **Incognito / Private Browsing mode.**  When a person chooses to visit a site in this mode, there is of course risk that the site will say "Nope sorry you may not visit in incognito mode, please use regular browsing mode instead."  Chrome wanted to block 3p cookies in incognito, but we worried that this would make the incognito choice detectable.  After internal debate we _did_ decide to default incognito to 3p-cookie blocking, but part of the decision was "There are enough other reasons 3p cookies might not be available that this wouldn't really enable incognito detection."

2. **Ramp-up debugging.**  During the period where Chrome is rolling out the new Privacy Sandbox APIs for on-device ad selection, the new APIs might not yet be available everywhere, for a long list of reasons: only half of people are eligible, a site needs to set a permissions policy, a user needs to have seen some notification, etc.  For users who have opted out, we have sometimes treated them like the many other reasons an API might not be available, so that feature detection would fail.  This could risk retaliation if it were _likely_ that API absence was caused by a user action, but if there are lots of other reasons as well, this may be OK.  People trying to use the API would benefit from being able to tell the difference between "The API is inexplicably broken x% of the time" and "The API is deliberately unavailable y% and inexplicably broken z%", where x = y + z.

3. **Avoiding expensive operations.**  We have cases where an API's existence triggers adding some HTTP header, which means some additional network bytes that are useless.  In this case I agree with the principle as written, and I think we should just send the header even for opted-out users.  But I'm worried about future cases where the thing we need to do to maintain the fiction of the API being available might be more expensive than tens of bytes on the wire.  For example, if the party calling the aggregation API wants to aggregate some expensive-to-compute value, they could roll a d20 and only compute it 5% of the time  Both the API caller and the user might be happier with a browser-supported API extension that lets the caller ask "Please tell me if I should compute this expensive value with p=0.05", and which was very likely to tell them to _not_ compute the value if the reporting API was turned off.  (Maybe there is a DP version of this which satisfies "should be undetectable"?)

None of these is a slam-dunk case; feel free to tell me to go home.  But I'm a little wary of over-generalizing this undetectability principle to cases where it imposes other costs on the user.


-- 
GitHub Notification of comment by michaelkleber
Please view or discuss this issue at https://github.com/patcg/docs-and-reports/issues/49#issuecomment-1799789987 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 7 November 2023 19:48:39 UTC