On Tue, Feb 13, 2024 at 12:10 PM Nan Lin <[email protected]> wrote:
> Hi Yoav, > > On Tue, Feb 13, 2024 at 3:10 AM Yoav Weiss (@Shopify) < > [email protected]> wrote: > >> >> >> On Fri, Feb 9, 2024 at 5:59 AM Nan Lin <[email protected]> wrote: >> >>> Hi Yoav, >>> >>> On Thu, Feb 8, 2024 at 11:09 PM Yoav Weiss (@Shopify) < >>> [email protected]> wrote: >>> >>>> >>>> >>>> >>>> >>>> On Wed, Feb 7, 2024 at 12:58 PM Nan Lin <[email protected]> wrote: >>>> >>>>> Thanks Mike. >>>>> >>>>> On Wed, Feb 7, 2024 at 12:50 AM Mike Taylor <[email protected]> >>>>> wrote: >>>>> >>>>>> On 2/6/24 3:59 AM, Nan Lin wrote: >>>>>> >>>>>> Hi Mike, >>>>>> >>>>>> Thanks for reviewing. Please see responses inline. >>>>>> >>>>>> Nan >>>>>> >>>>>> On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Nan, >>>>>>> On 2/2/24 5:00 AM, Nan Lin wrote: >>>>>>> >>>>>>> Contact emails >>>>>>> >>>>>>> [email protected], [email protected] >>>>>>> >>>>>>> Explainer >>>>>>> >>>>>>> Cross App and Web Attribution Measurement >>>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md> >>>>>>> >>>>>>> Specification >>>>>>> >>>>>>> https://wicg.github.io/attribution-reporting-api/#cross-app-and-web >>>>>>> >>>>>>> Summary >>>>>>> >>>>>>> This is an extension to the Attribution Reporting API >>>>>>> <https://github.com/WICG/conversion-measurement-api> that has >>>>>>> already shipped. >>>>>>> >>>>>>> Currently, the Attribution Reporting API >>>>>>> <https://github.com/WICG/conversion-measurement-api> supports >>>>>>> attributing events within a single browser instance. This proposal >>>>>>> expands >>>>>>> the scope of attribution to allow attributing conversions that happen on >>>>>>> the web to events that happen off the browser on the same device, within >>>>>>> other applications such as mobile applications, or vice-versa. >>>>>>> >>>>>>> The proposal here leverages OS-level support for attribution. In >>>>>>> particular, it gives the developer an option to allow events on the >>>>>>> mobile >>>>>>> web to be delegated to Android’s Privacy Sandbox >>>>>>> <https://developer.android.com/design-for-safety/privacy-sandbox/attribution>, >>>>>>> although support for other platforms could also be implemented in the >>>>>>> future. >>>>>>> >>>>>>> Note that with this proposal new features shipped by the OS may be >>>>>>> implicitly supported without web API changes. For example, Android may >>>>>>> ship >>>>>>> support for new registration fields not supported in the existing >>>>>>> Attribution Reporting API. Once a developer elects to delegate events to >>>>>>> the OS, there is no way web-visible to introspect this. >>>>>>> >>>>>>> Could you help me better understand the implications of this? Does >>>>>>> it just mean that debugging becomes challenging for new fields, or are >>>>>>> there other possible implications depending on new OS features? Or >>>>>>> possibly >>>>>>> the web API lags behind what is possible via the platform, until the web >>>>>>> API catches up formally? >>>>>>> >>>>>> >>>>>> It’s not about debugging. Currently the web API and the Android’s >>>>>> implementation of the Attribution Reporting API are expected to be >>>>>> interoperable. However it’s possible that Android may ship support for >>>>>> new >>>>>> registration fields in the OS-level API, which may or may not be >>>>>> supported >>>>>> in the web API. The web API may lag behind, or even not implement the new >>>>>> features at all. Once the event is delegated to the OS, the attribution >>>>>> registration will be handled by the OS and possibly using the new >>>>>> features >>>>>> in its API. >>>>>> >>>>>> >>>> Can you provide an example of how future OS-level changes can result in >>>> semantics changes for the web exposed API? >>>> Is the information flow here strictly from the web API to the OS API? >>>> Or is it possible for the OS attribution to flow into the web? (e.g. if an >>>> ad on a native app ends up landing on a website) >>>> >>> >>> Please see my response below for the workflow to delegate a web event to >>> the OS. >>> >> >> Thanks for the clarifications! >> >>> >>> For example, the OS API implements a new feature, and allows developers >>> to opt in this feature with a new field in the >>> Attribution-Reporting-Register-Source/Trigger JSON. >>> >>> The web API only delegates the registration url (to which the OS API >>> will ping) to the OS API, and the registration url can respond to OS API >>> ping with the new field in the Attribution Reporting response headers to >>> opt in the new feature implemented by the OS API. >>> >>> All the cross app web attribution is handled by the OS API. For app to >>> web flow (an ad on a native app ends up landing on a website), the >>> reporting origin can respond with Attribution-Reporting-Register-OS-Trigger >>> header to delegate the trigger event to the OS API to perform the >>> attribution within the OS API. So yes, the information flow is strictly >>> from the web API to the OS API. >>> >> >> So if the OS API registers an event source >> <https://developer.android.com/design-for-safety/privacy-sandbox/attribution#register-attribution-source> >> with a parameter that the Web API doesn't recognize, would that parameter >> be ignored when that event is triggered by the web API? >> > > The parameter would not be ignored by the OS API even if the event is > triggered by the web API. When the event is delegated to the OS API, it > will be completely handled by the OS API and can use all features available > in the OS API even if some features may not be supported in the web API. > Does that mean that when a trigger is called on the web API in that scenario, that trigger would be delegated to the OS, and the OS would be the one doing the reporting? > >> >>> >>> Thanks for the response! I'm still trying to understand what a >>>>>> registration field is in the context of this API - is that a possible >>>>>> future item added to the OS registration struct in >>>>>> https://wicg.github.io/attribution-reporting-api/#os-registration? >>>>>> (Apologies, I can't find any reference to "registration field" in the >>>>>> draft >>>>>> spec...). >>>>>> >>>>> >>>>> Sorry for the confusion. The registration field in the context of the >>>>> Attribution Reporting API is a JSON field in the >>>>> Attribution-Reporting-Register-Source ( >>>>> >>>>> https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#registering-attribution-sources) >>>>> and Attribution-Reporting-Register-Trigger ( >>>>> >>>>> https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#triggering-attribution >>>>> ) headers. Android also implements the Attribution Reporting API that >>>>> supports header-based registration ( >>>>> >>>>> https://developer.android.com/design-for-safety/privacy-sandbox/attribution#enroll-ad-tech-platform >>>>> ). >>>>> >>>>> The workflow to delegate a web event to the OS is as follows: >>>>> 1. In the web API, the reporting origin can respond with a list of >>>>> registration urls in the Attribution-Reporting-Register-OS-Source and >>>>> Attribution-Reporting-Register-OS-Trigger headers. >>>>> 2. The browser delegates the registration urls to the OS-level API. >>>>> 3. The OS-level API makes a request to the registration url. >>>>> 4. The registration url responds with the >>>>> Attribution-Reporting-Register-Source or >>>>> Attribution-Reporting-Register-Trigger header, which is handled by the >>>>> OS-level API. >>>>> >>>>> If the OS-level API supports a new registration field in the >>>>> Attribution-Reporting-Register-Source or >>>>> Attribution-Reporting-Register-Trigger JSON, in step 4 above the >>>>> registration url could respond with the new registration field for new >>>>> features supported in the OS-level API but not the web API. >>>>> >>>>> Hope that clarifies. >>>>> >>>>> >>>>>> This can happen without web API change and there’s no way web-visible >>>>>> to introspect this. >>>>>> >>>>>> OK, so introspection here is not about debugging, but being able to >>>>>> make decisions programmatically at runtime? Is that correct? >>>>>> >>>>> >>>>> Yes, that’s correct. Once the web event is delegated to the OS, the >>>>> attribution registration will be handled by the OS-level API, and there’s >>>>> no way for the web API to decide or even know the actual registration. >>>>> >>>>> >>>>>> >>>>>>> Blink component >>>>>>> >>>>>>> Internals > AttributionReporting >>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting> >>>>>>> >>>>>>> >>>>>>> TAG review >>>>>>> >>>>>>> >>>>>>> https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938 >>>>>>> >>>>>>> TAG review status >>>>>>> >>>>>>> Pending >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> >>>>>>> See the Attribution Reporting API I2S >>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY> >>>>>>> for information on the other general measurement proposals in this >>>>>>> space. >>>>>>> >>>>>>> Private Click Measurement in Safari supports app to web measurement ( >>>>>>> https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement). >>>>>>> On iOS, some web to app measurement is supported via SKAdNetwork ( >>>>>>> https://developer.apple.com/documentation/skadnetworkforwebads). >>>>>>> There is currently no interop between these proposals and the cross app >>>>>>> web >>>>>>> API for Attribution Reporting. >>>>>>> >>>>>>> If Blink ever ships on iOS (at least in the EU, given recent >>>>>>> announcements by Apple), would it be possible to expect interop between >>>>>>> iOS >>>>>>> and Android? >>>>>>> >>>>>> >>>>>> There’s no official position from WebKit yet, but there’s some >>>>>> concern on the interoperability between Safari’s Private Click >>>>>> Measurement >>>>>> and the Attribution Reporting API. We may expect similar concerns on >>>>>> supporting Attribution Reporting API on iOS, therefore would not expect >>>>>> interoperability between iOS and Android in the short term. >>>>>> >>>>>> Thanks - ignoring the PCM API proposal, my question was more along >>>>>> the lines of if it would be possible to implement this proposal were >>>>>> Blink >>>>>> to be shipped on iOS (rather than the current Bling architecture), i.e., >>>>>> do >>>>>> the underlying iOS APIs allow for implementing this proposal. I don't >>>>>> think >>>>>> this is a blocking concern today, but an interesting interop concern for >>>>>> a >>>>>> future state. >>>>>> >>>>> >>>>> Thanks for explaining. To implement this proposal on iOS, it requires >>>>> the iOS API to support a similar registration url based interface and >>>>> handle the attribution registration. This is currently not supported by >>>>> the >>>>> underlying iOS API and we would not expect this happen in the short term. >>>>> But I agree that it’s a reasonable interop concern in the future were >>>>> Blink >>>>> to be shipped on iOS. >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Gecko: No official position ( >>>>>>> https://github.com/mozilla/standards-positions/issues/791#issuecomment-1908359889 >>>>>>> ) >>>>>>> >>>>>>> Any reason we didn't file a new issue w/ Mozilla (or TAG...), but we >>>>>>> did with WebKit? >>>>>>> >>>>>> >>>>>> We initially requested feedbacks for TAG, Mozilla and Webkit all in >>>>>> the comments of the Attribution Reporting API requests as it’s an >>>>>> extension >>>>>> of that API. We were then suggested by WebKit folks to file a new issue >>>>>> instead as it’s easier for their system to handle new requests. >>>>>> >>>>>> >>>>>>> >>>>>>> WebKit: No official position ( >>>>>>> https://github.com/WebKit/standards-positions/issues/307) >>>>>>> >>>>>>> Web developers: Positive. Some testers are currently implementing >>>>>>> and providing feedback and more usage expected in 2024. Developers have >>>>>>> requested expansion of coverage of this feature (example: >>>>>>> https://github.com/WICG/attribution-reporting-api/issues/1125). >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> The Attribution Reporting API utilizes DevTools and an internal page >>>>>>> (chrome://attribution-internals) to facilitate testing and >>>>>>> integration. The debugging information for OS registrations from Chrome >>>>>>> will be displayed in DevTools and the internal page as well. >>>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#optional-transitional-debugging-reports> >>>>>>> >>>>>>> Additionally, debug reports >>>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md#optional-debugging-reports> >>>>>>> are supported for OS registrations. The Attribution Reporting API for >>>>>>> Android also implements a similar debugging reports framework >>>>>>> <https://developer.android.com/design-for-safety/privacy-sandbox/attribution-app-to-web#transitional-debugging> >>>>>>> to facilitate cross app and web testing. >>>>>>> >>>>>>> >>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>> >>>>>>> The Attribution-Reporting-Support header is supported on all >>>>>>> platforms. Today, only Android offers a native Attribution Reporting >>>>>>> API, >>>>>>> so the ability to register with the OS is only supported on those >>>>>>> platforms >>>>>>> (Android and Android WebView). >>>>>>> >>>>>>> Is this feature fully tested by web-platform-tests >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>> ? >>>>>>> >>>>>>> The Attribution-Reporting-Support header is tested by web platform >>>>>>> tests, but the integration with OS is not as web platform tests are >>>>>>> not supported for Android. >>>>>>> >>>>>>> Requires code in //chrome? >>>>>>> >>>>>>> False >>>>>>> >>>>>>> Estimated milestones >>>>>>> >>>>>>> Chrome 123 >>>>>>> >>>>>>> Launch bug >>>>>>> >>>>>>> https://launch.corp.google.com/launch/4238495 >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> >>>>>>> https://chromestatus.com/feature/4994430156668928 >>>>>>> >>>>>>> Links to previous Intent discussions >>>>>>> >>>>>>> Cross App and Web Attribution Measurement Intent to Experiment >>>>>>> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gTvI5x-qex8> >>>>>>> >>>>>>> Cross App and Web Attribution Measurement Intent to Extend Experiment >>>>>>> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/0drGQpsOKh0> >>>>>>> >>>>>>> Attribution Reporting API Intent to Ship >>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "blink-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgP%3DZDhgDguTkPXBnPOk8CpOVkxKHyBoeUR9%3D43c7p6wZuw%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgP%3DZDhgDguTkPXBnPOk8CpOVkxKHyBoeUR9%3D43c7p6wZuw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgPn%2BCBi6AEExLWMrwRF9y68cs5GGQ4vhFPxXCHmwndZeCQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgPn%2BCBi6AEExLWMrwRF9y68cs5GGQ4vhFPxXCHmwndZeCQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BRxWFiSU1mcgVSk-tSHDH5U42C8QktHhw%3D8KC%3D8i84VA%40mail.gmail.com.
