On Fri, Feb 9, 2024 at 5:59 AM Nan Lin <lin...@chromium.org> wrote:
> Hi Yoav, > > On Thu, Feb 8, 2024 at 11:09 PM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> >> >> >> >> On Wed, Feb 7, 2024 at 12:58 PM Nan Lin <lin...@chromium.org> wrote: >> >>> Thanks Mike. >>> >>> On Wed, Feb 7, 2024 at 12:50 AM Mike Taylor <miketa...@chromium.org> >>> 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 <miketa...@chromium.org> >>>> wrote: >>>> >>>>> Hi Nan, >>>>> On 2/2/24 5:00 AM, Nan Lin wrote: >>>>> >>>>> Contact emails >>>>> >>>>> lin...@chromium.org, johni...@chromium.org >>>>> >>>>> 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? > > 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 blink-dev+unsubscr...@chromium.org. >>>>> 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 blink-dev+unsubscr...@chromium.org. >>> >> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKKBRyrxJGh6dvoFN-v5LyQDWOrFva8Y3r2fppkzTQPcA%40mail.gmail.com.
