clarification regarding registerAdBeacon and additional browser reserved events

[rdgordon-index]

https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#design talks about the design principles of reportEvent, and calls out that (emphasis added):

The following summarizes the sequence of events for the buyer and seller. Distinguishing these flows here, since in principle, one should be able to report without the help of the other.

Based on our understanding, this means that events like reserved.top_navigation should be able to be registered by the seller in reportResult without any buyer involvement.

What's unclear is how the destination for such an event can be configured by the seller, given that

a new setReportEventDataForAutomaticBeacons API can be invoked from within the fenced frame

Since the fenced frames run the buyer's scripts, where can this API be involved without the help of the other (buyer)?

Furthermore, as noted in #452, WICG/fenced-frame#8, and #264 (comment) (which talks very useful intersection-observer events), we're also looking for an API for additional browser-creatd reserved events that can be registered by the seller alone for events such as render and viewability, in addition to the click (top_navigation) that currently exists.

To be clear, the request isn't about user interactions within the opaque ad itself (e.g. did the user click on pixel X or Y within the ad) -- rather, as a seller, we're looking to generate events that are useful to report back to the publisher -- events that publisher expect sellers to provide today for contextual auctions. That is, did the user click at all, was the ad fully within the viewport, does it meet the MRC definitions for viewability, and the like.

Is there any in the privacy model that would preclude the addition of such browser events?

[shivanigithub]

@rdgordon-index Thanks for the issue! There are 2 parts to this:

1. Can automatic beacons like reserved.top_navigation be sent to a seller who registered via registerAdBeacon without buyer script's involvement? - This is something we are working on as part of Update automatic beacon explainer for new sending behavior #808. cc @blu25
2. Can an automatic viewability event be created? - Would you have more inputs on what exact viewability definitions/formats would be most useful to you e.g. is the format something like: the frame was visible 'x' percentage for 'y' time? Are there any specific values of 'x' and 'y'?

cc @michaelkleber

[michaelkleber]

For 2. I think we should try to take inspiration from Intersection Observer. But maybe we will need to extend that for statically-declared periods of time, since we don't want to kick off a JS callback, but rather send a report.

[blu25]

For 1: After a security review, it was decided that the buyer script in the ad frame needs to have control over whether the reserved.top_navigation signal can be sent. Without it, this could be considered a cross-origin information leak if the buyer doesn't want to have that information sent out.

The security reviewers did approve a slightly different approach. The buyer script will still need to invoke setReportEventDataForAutomaticBeacons(), but once invoked, every destination that called registerAdBeacon() for reserved.top_navigation will get a beacon, but only the destinations specified in the destinations field will get data. While this will still require the buyer script's involvement, if a beacon goes to the buyer, it will also go to the seller.

[rdgordon-index]

For 1: After a security review, it was decided that the buyer script in the ad frame needs to have control over whether the reserved.top_navigation signal can be sent. Without it, this could be considered a cross-origin information leak if the buyer doesn't want to have that information sent out.

Can you elaborate on why only the buyer gets to decide if a reserved.top_navigation event is sent out?

[rdgordon-index]

For 2. I think we should try to take inspiration from Intersection Observer. But maybe we will need to extend that for statically-declared periods of time, since we don't want to kick off a JS callback, but rather send a report.

That API sounds like it's well-suited for this purpose -- as for specific examples, the MRC has well-defined parameters for viewability that are extremely useful.

[blu25]

Can you elaborate on why only the buyer gets to decide if a reserved.top_navigation event is sent out?

One of the security guarantees of the web is that information isn't allowed to leak across origins unless the frame the information originates in explicitly wants that information sent out. If we were to allow reserved.top_navigation automatic beacons to be sent without any sort of opt in from a frame, then the knowledge that a click happened from within a frame can be exfiltrated across origins. Since knowledge about a click happening is information that originates from the ad frame for the buyer, that frame needs to have the final say in whether knowledge about the click gets to be sent out to cross-origin parties.

[rdgordon-index]

the ad frame for the buyer

It's the "for the buyer" part that I'm trying to better understand.

Yes, what's being rendered in the frame is ultimately sourced from the buyer's renderURL -- however, in the context of on an on-device auction, there's always a seller, too -- without whom there would be no ad to render.

to be sent without any sort of opt in from a frame

The publisher chooses which entities are allowed to execute runAdAuction and joinInterestGroup via Permissions-Policy; a user agrees to enable Privacy Sandbox APIs; publishers declare which sellers are part of on-device auctions, and seller declare which IG buyers are eligible for submitting bids.

That's a significant number of "opt-in" steps -- and therefore IMHO this should be sufficient to determine the "final say". In other words, I'm suggesting that all frames resulting from PAAPI, by definition, should be 'expected' to report results to both buyer and seller -- as governed by attestation.

[michaelkleber]

@rdgordon-index Any time there is a 3rd-party <iframe> on a web page, it's only there because the site owner enabled it, directly or via some chain of delegation. That doesn't give the enabler the power to dictate the behavior of the embedded content, here or anywhere else on the web.

Note also that the renderURL of the ad could be any URL in the world; there is nothing in the creative itself which declares its ad-ness. So we cannot weaken the security model of standard web embedding; if we did, then any attacker could embed anything on their own site with this technique to get weaker embedder protections = more attack surface for the site owner to exploit.

[rdgordon-index]

Would it be sufficient if the site owner 'enabled it' (it = automatic beacons) when the frame was created? Rather than needing to call setReportEventDataForAutomaticBeacons from within said frame? If so, then we can figure out a way to ensure that this becomes explicit, but still the default, with permissioning in the event that the iframe creator wants the existing behaviour.

[shivanigithub]

Would it be sufficient if the site owner 'enabled it' (it = automatic beacons) when the frame was created? Rather than needing to call setReportEventDataForAutomaticBeacons from within said frame? If so, then we can figure out a way to ensure that this becomes explicit, but still the default, with permissioning in the event that the iframe creator wants the existing behaviour.

Can you elaborate a bit more on why it's easier to opt-in at creation time via, say, response headers as compared to JS call. Either approach requires the creative's site to do an explicit opt-in. Specifically, since the setReportEventDataForAutomaticBeacons will need to be invoked in order for any site to receive automatic beacons (including the buyer), it seems there is a high probability that it will be invoked but I might be missing some context.

[rdgordon-index]

Can you elaborate a bit more on why it's easier to opt-in at creation time via, say, response headers as compared to JS call. Either approach requires the creative's site to do an explicit opt-in.

The JS call would need to be made by the buyer's creative, within the frame, which the seller has no control over -- in other words, there's no guarantee such a call would be made.

If this is tied to the frame itself, rather than the contents of the frame, then the site -- or, more correctly, javascript running on the site that creates the frame, can ensure that all such frames trigger these automatic beacons.

[blu25]

If this is tied to the frame itself, rather than the contents of the frame, then the site -- or, more correctly, javascript running on the site that creates the frame, can ensure that all such frames trigger these automatic beacons.

That seems reasonable. We discussed this with Chrome security and have a design that will work with your use case.

We're proposing adding a new response header to allow using automatic beacons. If that header is set, automatic beacons will be sent out, even if the document never called setReportEventDataForAutomaticBeacons() (there will obviously not be any data attached to the beacon in this case). The document can still choose to set event data through a JavaScript call, and, in the absence of the opt-in response header, the JS call will still function as the document opting in.

The same header will also support the cross-origin subframe issue as described in the response here.