LGTM3 On Wed, Feb 14, 2024 at 7:48 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote:
> LGTM2 > > On Tuesday, February 13, 2024 at 1:42:39 PM UTC+1 Nan Lin wrote: > > On Tue, Feb 13, 2024 at 7:35 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > > > > On Tue, Feb 13, 2024 at 12:10 PM Nan Lin <lin...@chromium.org> wrote: > > Hi Yoav, > > On Tue, Feb 13, 2024 at 3:10 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > > > > 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? > > > 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? > > > That’s right. This design places trust in the OS to process cross app web > attribution reporting. When the trigger is delegated to the OS, it could be > attributed to an app source, or a web source that was delegated to the OS, > and an attribution report would be scheduled by the OS API if any. > > > That makes sense. Thanks for bearing with me :) > > > > > > > > > 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%3DZDhgDguTkPXBnPOk8CpOVkxKHyBo > eUR9%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%2BCBi6AEExLWMrwRF9y68cs5GGQ4vh > FPxXCHmwndZeCQ%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/5164e08a-c56c-4948-a72e-a2d7b86d0094n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5164e08a-c56c-4948-a72e-a2d7b86d0094n%40chromium.org?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/CAOMQ%2Bw8QyqJen_bx0kSCt%3D1%2BeZYvX7GsLLzTbF3fJG-JEjuFwA%40mail.gmail.com.
