jkarlin
commented
2 years ago Thanks Rachel for the well explained use case!
You've proposed to have a stable (but can tolerate noise) per-third-party low-entropy id, which can then be used server-side for experimentation purposes. A tricky part here is the per-third-party part, as that means if multiple third-parties collude, than can join their identifiers together to form a global identifier. On the other hand, a browser-wide identifier would extend beyond the capabilities of today's third-party cookies which is a privacy problem of its own. It would be nice if we could do something like we do with Topics here, which is to assign to each user multiple ids (say 5), and give different sites access to a different id, making it harder to join the user across sites. I don't think that works well for experiments though, as something like Lift measurement requires consistency across sites. Ideas very much welcome here in how we might reduce the cross-site information!
The second tricky part is the number of bits provided. This is fingerprinting information that gets compounded with other surfaces (IP address, User Agent, etc..). So we want to reduce such surfaces as much as possible. One mechanism we use already in Shared Storage is Fenced Frames & User Gesture. That is, the destination site can't learn the low-entropy id until the resulting fenced frame navigates (which requires a click). This at least slows down the propagation of the bits, but they still can get out there. The more bits per click, the faster a site can be tied to a globally consistent and unique identifier. This could be mitigated by ensuring that the top-level navigation from the fenced frame doesn't convey the third-party state, or that the information leakage is temporary (e.g., clearing state on the destination site, or making the visit from the fenced frame happen in incognito mode).
Another thing that's different between your proposal and Shared Storage is that Shared Storage assumes that the cross-site information used to make a decision could be different each time. That is, each time information is leaked, we have to assume that it's new information. But your use case requires the same bits be provided each time. There is room for budgeting optimization here in Shared Storage. We could not count the leakage of the same information twice. That would take some careful thought for how we might do that in an efficient and easy-to-use way.
Finally, I think the existing output gate that you might use for this (runURLSelectionOperation) isn't a perfect fit. You don't actually want to supply 256 URLs, it'd be simpler if you just provided a URL template (e.g.,"https:// example.com/ad_requests?user_low_entropy_id=%d" and Shared Storage could write in a few bits. We'd still need to make sure that the output url is k-anonymous, but there is no privacy/security difference between that and runURLSelectionOperation as it stands. This is mostly seems like an ergonomics issue and is lower concern than above.
rwiens
pythagoraskitty
Hi! I'm really excited to see that this Shared Storage API proposal is trying to create a solution for cross-site experiments. However the current proposal seems best suited for experimenting on within-browser changes, such as additional filtering after an ad network has already delivered an ad. We're strongly interested in enabling user-consistent cross-site server-side experiments, such as controlling whether a new ad format type would even be included in the initial server-side auction, or changing how an ad creative is rendered before it's sent to the browser.
Are there options here to expand this design to better suit server-side experiments (or possibly even experiments with simultaneous client and server-side changes)? There's a very large number of different types of filtering and logic that happens on server-side, so we'd really appreciate a solution that can scale well to a variety of use cases.
If you're uncertain about requirements, here's a few of ours that may be helpful as you think about this:
As a potential starting point idea for you to consider, if you're able to allow third-parties access to a k-anonymous, random bucket ID that's user-sticky and consistent across sites, this would allow us to run cross-site experiments. Each 3rd party (e.g. the ad network) would want an independent user-to-bucket grouping so they don't influence one another's metrics, and that should also benefit the user by making it harder to identify common users across different 3rd parties. It'd be nice if the number of bucket IDs available to a 3rd party was proportional to the traffic the party receives since anonymity is closely tied to the underlying population - e.g. 1 bit can be identifying if you have 2 users, but it's not identifying if it's evenly split among 1000 users. I haven't fully thought through all the attack vectors and privacy implications here so I imagine this rough idea will need improvement. Please let me know if there's further details you'd like to discuss, and thanks for your time.