Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross Device Interest Groups and Attribution in the Case of Authenticated User Agents (PENGUIN) #607

Open
thegreatfatzby opened this issue Jun 5, 2023 · 5 comments
Labels
Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility

Comments

@thegreatfatzby
Copy link
Contributor

The Problem

You're a fresh grad at widgets.com; after a successful internship last summer where your boss convinced you you did something useful, you are now managing their advertising campaigns, trying to reach new customers and/or achieve some kind of performance metric, using your budget effectively while delighting existing and potential clients. It's a lot.

You are able to target an appropriate user set, not show them the same Limu Emu ad too many times, and understand if they've paid for your widget based on the wonderful tools that Chrome gives you. You send your Grandma a link, so she can be proud of your clever usage of Interest Groups, the Attribution API, and Bard 0.2 (you're on a budget, you can't afford ChatGPT!) generated textual creatives. She buys a widget to show her support, and sends you a card saying how proud of you she is. It's a lot.

Now Grandma goes to use her Android "Cell Phone Device" and opens the widget purchase thank you email to clear the notification. But now, she keeps getting ads from widgets.com even on her "Cell Phone Device". She is sad and confused. She wonders if you got her card. She wonders if you care that she is on a fixed income. She worries aloud, why does he keep showing me ads for widgets I already bought, but the widget ads just won't stop! It's too much!

She tries to find a family counselor she can afford with her Medicare Advantage plan. But the counselor's ad bids low because it isn't aware she's in the TechSavvyGrandma Interest Group on her laptop, and due to Medicare cuts the plan's ads never outbid your highly optimized Interest Group based re-targeting campaign, which never fails because the WASM execution in Chromium is bug free. Angry and frustrated, she drops you from her will, you're disinvited from Thanksgiving, and you're left to wonder how you could have solved this "cross device same person same site" problem without losing your family. It's a lot.

Finally your boss fires you because you lost a customer and had significant overspend trying to target an existing customer. "Why didn't you know it was the same person!!!" she demands to know! It's a lot.

Current Solution

In the current ecosystem, "Cross Device" is a technique which allows for coordinating targeting, capping, and attribution/measurement across multiple devices that are agents for "the same person". The way Cross Device works today is, in my experience, based on graph data that is collected through some "foo", and then at ad time the identity expansion is handled server side so that the capping, targeting, and measurement can happen "Across Devices". This would allow you to, for instance, frequency cap and target across a users laptop and mobile, remove someone from targeting after conversion, etc.

PENGUIN for Privacy Sandbox

In the Privacy Sandbox world, Interest Groups, and more broadly user data, are held by the users agent and used in a way that ensures privacy in an on-device or TEE based auction. We believe that doing it this way disables passive tracking the user wouldn't explicitly agree to while maintaining a decent advertising experience that supports publishers creating content.

Enabling targeting, capping, and attribution to happen across device, without additional privacy-attack-vectors, would be a significant improvement in the new-ecosystem's ability to provide publishers incentive to create content and advertisers the ability to advertise in a consistent and privacy respecting way.

In the case of a User who is using the same (or related) User Agents across Devices, and in particular a User Agent that supports some form of Authentication to the tool itself (a la Chrome and Edge), the driver of privacy can still be satisfied if those user agents coordinate with each other while maintaining the same partitioning scheme.

So what I'm proposing for discussion is that the User Agent allow The User to opt-in to this limited sharing within their account, and the Authenticated User Agents then coordinate such that the TechSavvyGrandma Interest Group from Grandma's laptop is also available on her Android "Cellular Phone Device", no one gets disinvited from Thanksgiving, and everyone keeps their job.

(A bird name here could be: PENGUIN (Potentially Enable Narrow Global Useragent Individualized Networking)).

How to Coordinate

I'm more aiming to propose this overall, see what people think about the privacy aspects, and get thoughts. Certainly some kind of coordination could happen server side, which surely has issues; the clients could potentially sync with each other, and then everything would look the same from the auctions perspective (i.e. it doesn't know it's getting a blob from 2 machines), but that has it's own issues.

So since the perfect is the enemy of the good I'm going to say "I'm not sure", but am hoping to discuss this further.

@michaelkleber
Copy link
Collaborator

Hi Isaac,

The question of recognizing the same user across devices, and using that information appropriately, has been more heavily discussed in the context of the measurement and attribution APIs rather than the targeting APIs, with particular focus on the use case where a person sees an ad on their phone and then converts on their laptop.

Measurement discussions are mostly happening in the Private Advertising Technologies Community Group, and indeed the PATCG meeting last week included a lengthy discussion of this topic. Notes are in here in this Google Doc for now; I'm not sure if they will end up migrated to GitHub at some point.

If the measurement APIs steer a course through this tricky subject, then the targeting APIs may try to follow their lead. Even that isn't a guarantee, though — measurement with appropriate noise can offer quite a lot of privacy protection, while the high specificity of targeting poses some real challenges here.

@JensenPaul JensenPaul added the Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility label Jun 23, 2023
@thegreatfatzby
Copy link
Contributor Author

Hey Fwend!

I found the PATCG discussions on XD Attribution quite good, and have been trying to dig through IPA (I forgot I like math!). I would love to hear your thoughts on the "high specificity of targeting pos(ing) some real challenges here", specifically from a privacy perspective. I am aware that there would be engineering challenges to make any pretty pictures work in reality; from a privacy model perspective I'm not clear what is violated, which certainly may be because I don't have all of that embedded in my brain's execution path yet. From a "boxes on whiteboard" view I would think:

  • Partitioning by domain can still be accomplished.
  • Differential privacy requirements can still be met, K anonymity can still be done, we can still noise reports, etc.
  • Data can still stay on client and the auction can be run there.

Doing something cross-device certainly feels less private, and a person might very well say they don't want to do it (although lots of folks use cross-device capabilities for reasons outside of ads). Things I wonder if I'm missing:

  • Does the model specify a single user agent?
  • Would the differential privacy be "accomplished but just less well", I guess bigger epsilon or some such.
  • Is it that more data is in more places and so the overall risk is just higher?

Help me understand why this PENGUIN can't fly.

@michaelkleber
Copy link
Collaborator

I think this is a great discussion topic for a future PATCG meeting, having listened to the a wide range of interesting thinking on the Measurement side.

But I would say that for this purpose, there is a deep and essential difference between targeting and measurement. Measurement outcomes can be highly noised in a way that means they are useless at the level of the individual, and only provide useful information after aggregation — indeed, that is at the root of Differential Privacy. But targeting decisions must be useful at the level of the individual — if they are not, then the targeting mechanism definitionally cannot achieve a goal like increasing expected conversions from the people who see the ad.

@thegreatfatzby
Copy link
Contributor Author

That type of thought is helpful to understanding how folks are looking at this, I will try to incorporate this more into my thinking and get back, and yes would be great to discuss further at some meeting (although, in my W3C infancy I'm not clear why PATCG).

@michaelkleber
Copy link
Collaborator

Great, I'm glad this discussion is helpful. (And apologies in advance that discussion is about to slow down in honor of summer vacations season.)

This seems like a topic about private advertising technologies in a very general sense, and so the Private Advertising Technologies Community Group seems like a natural venue because it's inherently in their scope.

Discussions about FLEDGE Protected Audience in particular, for now, are being held in the catch-all incubation group WICG, because PATCG is heavily focused on measurement stuff and felt they would rather not split their attention and resources across two different efforts. I will guess that cross-browser alignment on targeting stuff is most likely to happen in PATCG once that group has landed its measurement work. (Note that spreading it across two groups does not seem likely to make it happen sooner — the resources and attention that are the limiting factor are those of the people involved in the discussion, not of the venue where the discussion takes place!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility
Projects
None yet
Development

No branches or pull requests

3 participants