Update for support for component ads

[shivanigithub]

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.

[shivanigithub]

@JensenPaul PTAL, thanks!

[shivanigithub]

@JensenPaul friendly ping, thanks!

[JensenPaul]

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.

[JensenPaul]

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).

[JensenPaul]

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.

[JensenPaul]

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.

[JensenPaul]

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.

[JensenPaul]

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.

[JensenPaul]

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.

[JensenPaul]

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:

[JensenPaul]

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.