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

Update for support for component ads #391

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

shivanigithub
Copy link
Contributor

The solution here has been discussed here as part of the issue: #332 (comment). The PR simply adds what was in the doc linked in the issue (https://docs.google.com/document/d/1nRkV8BEsU_JzGgq4-fXTVCeLWNxA_2Pdz2NCVpUD_W0/edit?usp=sharing) to the explainer.

The solution here has been discussed here as part of the issue: WICG#332 (comment)
The PR simply adds what was in the doc linked in the issue (https://docs.google.com/document/d/1nRkV8BEsU_JzGgq4-fXTVCeLWNxA_2Pdz2NCVpUD_W0/edit?usp=sharing) to the explainer.
@shivanigithub
Copy link
Contributor Author

@JensenPaul PTAL, thanks!

@shivanigithub
Copy link
Contributor Author

@JensenPaul friendly ping, thanks!


The issue [here](https://github.com/WICG/turtledove/issues/332) points out a reasonable use case where the user clicks on a component ad and the ad-tech server would want to be notified of that via reportEvent mechanism since a click on a nested component ad is a significant enough event.

However reportEvent() only works if there is an associated registerAdBeacon() call and that metadata is only associated with the root fenced frame (the parent ad). If we were to also associate that metadata with the nested ads then that would imply that the server can join arbitrary data from the component ads and the parent ad, which is not a desired FLEDGE information flow (more details below). Note that reportEvent() can be called anytime and with arbitrary data and is not gated on a user click/gesture.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
However reportEvent() only works if there is an associated registerAdBeacon() call and that metadata is only associated with the root fenced frame (the parent ad). If we were to also associate that metadata with the nested ads then that would imply that the server can join arbitrary data from the component ads and the parent ad, which is not a desired FLEDGE information flow (more details below). Note that reportEvent() can be called anytime and with arbitrary data and is not gated on a user click/gesture.
However `reportEvent()` only works if there is an associated `registerAdBeacon()` call and that metadata is only associated with the root fenced frame (the parent ad). If we were to also associate that metadata with the nested ads then that would imply that the server can join arbitrary data from the component ads and the parent ad, which is not a desired FLEDGE information flow (more details below). Note that `reportEvent()` can be called anytime and with arbitrary data and is not gated on a user click/gesture.


A related issue is how a [click in the component ad can be used for attribution reporting.](https://github.com/WICG/turtledove/issues/281#issuecomment-1225746871)

To allow event level attribution reporting, the mechanism used by ad-tech is that reportEvent() from the parent FF carries a generated id which is also associated with the click based navigation and that helps join the 2 at the server side and attribute the navigation to the specific ad slot (fenced frame).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To allow event level attribution reporting, the mechanism used by ad-tech is that reportEvent() from the parent FF carries a generated id which is also associated with the click based navigation and that helps join the 2 at the server side and attribute the navigation to the specific ad slot (fenced frame).
To allow event level attribution reporting, the mechanism used by ad-tech is that `reportEvent()` from the parent Fenced Frame carries a generated identifier which is also associated with the click based navigation and that helps join the two at the server side and attribute the navigation to the specific ad slot (Fenced Frame).


To allow event level attribution reporting, the mechanism used by ad-tech is that reportEvent() from the parent FF carries a generated id which is also associated with the click based navigation and that helps join the 2 at the server side and attribute the navigation to the specific ad slot (fenced frame).

This can be fixed if reportEvent() were allowed from the component fenced frame. It can then create its own id and that can also be joined at the server side to the already joined <id-in-registerAdBeacon, id-in-parent-fenced-frame> since this reportEvent will be resulting in a ping to the same reporting url as the parent fenced frame.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This can be fixed if reportEvent() were allowed from the component fenced frame. It can then create its own id and that can also be joined at the server side to the already joined <id-in-registerAdBeacon, id-in-parent-fenced-frame> since this reportEvent will be resulting in a ping to the same reporting url as the parent fenced frame.
This can be fixed if `reportEvent()` were allowed from the component Fenced Frame. It can then create its own identifier and that can also be joined at the server side to the already joined <id-in-registerAdBeacon, id-in-parent-fenced-frame> since this `reportEvent()` will be resulting in a ping to the same reporting URL as the parent fenced frame.


### Privacy impact of reportEvent from component ad

registerAdBeacon is only allowed from [reportWin](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#52-buyer-reporting-on-render-and-ad-events) or [reportResult](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#51-seller-reporting-on-render), neither of which have the component ads information, so the combined event level reporting from reportWin, reportResult and FFAR does not allow a join of the main ad and components ads.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
registerAdBeacon is only allowed from [reportWin](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#52-buyer-reporting-on-render-and-ad-events) or [reportResult](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#51-seller-reporting-on-render), neither of which have the component ads information, so the combined event level reporting from reportWin, reportResult and FFAR does not allow a join of the main ad and components ads.
`registerAdBeacon()` is only allowed from [`reportWin()`](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#52-buyer-reporting-on-render-and-ad-events) or [`reportResult()`](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#51-seller-reporting-on-render), neither of which have the component ads information, so the combined event level reporting from `reportWin()`, `reportResult()` and calls to `reportEvent()` from the parent Fenced Frame do not allow a join of the main ad and components ads.


registerAdBeacon is only allowed from [reportWin](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#52-buyer-reporting-on-render-and-ad-events) or [reportResult](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#51-seller-reporting-on-render), neither of which have the component ads information, so the combined event level reporting from reportWin, reportResult and FFAR does not allow a join of the main ad and components ads.

If reportEvent() was allowed from a component ad, the combination of main ad and component ads would now be known at the server which goes against the privacy assumption where each of the main and component urls are k-anonymous and their join would not necessarily be k-anonymous.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If reportEvent() was allowed from a component ad, the combination of main ad and component ads would now be known at the server which goes against the privacy assumption where each of the main and component urls are k-anonymous and their join would not necessarily be k-anonymous.
If `reportEvent()` was allowed from a component ad, the combination of main ad and component ads would now be known at the server which goes against the privacy assumption where each of the main and component urls are k-anonymous and their join would not necessarily be k-anonymous.


### Fix and privacy impact

The fix could be to allow reportEvent from the component fenced frame but only if it received a click/transient user activation. To further reduce the amount of information leaked we will restrict it to at most one such reportEvent among all the component ads fenced frames for a given parent fenced frame.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The fix could be to allow reportEvent from the component fenced frame but only if it received a click/transient user activation. To further reduce the amount of information leaked we will restrict it to at most one such reportEvent among all the component ads fenced frames for a given parent fenced frame.
The fix could be to allow reportEvent from the component fenced frame but only if it received a click/transient user activation. To further reduce the amount of information leaked we will restrict it to at most one such `reportEvent()` among all the component ads Fenced Frames for a given parent Fenced Frame.


The fix could be to allow reportEvent from the component fenced frame but only if it received a click/transient user activation. To further reduce the amount of information leaked we will restrict it to at most one such reportEvent among all the component ads fenced frames for a given parent fenced frame.

Privacy-wise this can lead to at most 2 k-anonymous urls to be joined (that of the parent and the component that was clicked) but that seems acceptable as this additional information is gated on user activation on that component ad.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Privacy-wise this can lead to at most 2 k-anonymous urls to be joined (that of the parent and the component that was clicked) but that seems acceptable as this additional information is gated on user activation on that component ad.
Privacy-wise this can lead to at most two k-anonymous URLs being joined (that of the parent and the component that was clicked) but that seems acceptable as this additional information is gated on user activation on that component ad.


### Alternatives considered

An alternative could be to propagate the click event from component ad fenced frames to the parent fenced frame. Since it will be gated on user activation and does not carry arbitrary information, it is ok to have this limited communication channel between the nested component FF and its parent. However see below for concerns with this approach:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
An alternative could be to propagate the click event from component ad fenced frames to the parent fenced frame. Since it will be gated on user activation and does not carry arbitrary information, it is ok to have this limited communication channel between the nested component FF and its parent. However see below for concerns with this approach:
An alternative could be to propagate the click event from component ad Fenced Frames to the parent Fenced Frame. Since it will be gated on user activation and does not carry arbitrary information, it is okay to have this limited communication channel between the nested component Fenced Frame and its parent. However see below for concerns with this approach:


This API when invoked from the component ad fenced frame will let the browser know to invoke the same functionality as if window.fence.reportEvent(‘click’) was invoked from the parent frame.

The important difference between this and a reportEvent call is that there is no arbitrary data and arbitrary values of event type allowed. This however does not fix the attribution reporting issue mentioned above because there is no associated id in the reportEvent ping and the navigation resulting from the click.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The important difference between this and a reportEvent call is that there is no arbitrary data and arbitrary values of event type allowed. This however does not fix the attribution reporting issue mentioned above because there is no associated id in the reportEvent ping and the navigation resulting from the click.
The important difference between this and a `reportEvent()` call is that there is no arbitrary data and arbitrary values of event type allowed. This however does not fix the attribution reporting issue mentioned above because there is no associated identifier in the `reportEvent()` ping and the navigation resulting from the click.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants