On Tue, Jun 27, 2023 at 9:43 PM John Delaney <johni...@chromium.org> wrote:
> Thanks, Yoav and Rick for the questions/discussion. See responses below. > > Can you expand (or point to existing docs) about the differences between >> this and PCM? What's the likelihood of future convergence? What are >> developers expected to do in the meantime? >> > > Unfortunately, while we were able to converge with the PCM authors on > nomenclature > <https://github.com/privacycg/private-click-measurement/pull/75>, the > Attribution Reporting API differs substantially from PCM in quite a few > ways. We don’t have a detailed write-up of all the differences, but if it > seems useful we can draft a document in our repo outlining detailed > differences (tracking issue here > <https://github.com/WICG/attribution-reporting-api/issues/866>). Here is > a short summary: > > > - > > ARA has support for "viewed" impressions, where PCM only supports > clicks > - > > The ability for attribution to be scoped to, and reports sent to, > third parties (issue > <https://github.com/privacycg/private-click-measurement/issues/57>) > - > > Registration is performed via different mechanisms, HTTP headers for > ARA, PCM uses a combination of html attributes and .well-known request > parsing (see this issue > <https://github.com/privacycg/private-click-measurement/issues/93> as > an example of divergence) > - > > Reports contain different types of information, for example a 64-bit > identifier in event-level ARA, and an 8 bit identifier PCM > - > > Different limitations on the number and timing of reports which are > sent (issue > <https://github.com/privacycg/private-click-measurement/issues/95>) > > > There is some documentation on high-level design dimensions within PATCG > here > <https://github.com/patcg/docs-and-reports/blob/main/design-dimensions/README.md> > . > > Future convergence right now is not entirely clear, but it's something we > are actively working on in the PATCG. > > We expect that developers will develop for these measurement APIs when > they are providing value for their use-cases and customers, and that this > will require multiple different implementations switched on UA currently. > It's worth noting that, at present, the API surfaces for these two APIs do > not conflict with each other (PCM won't cause any issues in Chrome and vice > versa). > > +1. I spent 30 min looking over open issues, and while many didn't have >> responses yet they largely all felt like possible future extensions. Here's >> a couple which seemed to me to be worthy of at least a response or >> follow-up (if not a resolution) before I'd be comfortable approving the >> I2S. There may be others though, so I'd appreciate at least a quick triage >> pass by experts on the team to focus API owner attention on the issues >> which may cause future compat problems or otherwise inhibit an >> interoperable implementation. > > > We went through and added a "compat" label for issues that we feel have > compat risk. For the issues linked here, we are following up on those > individually and will provide an update soon. > Thanks! Going through the issues <https://github.com/WICG/attribution-reporting-api/issues?q=is%3Aissue+is%3Aopen+label%3Acompat>, I see a couple that I'm not sure have real compat implications, but 4 more that do seem like it'd be good to settle (or at least have a mental image of future-compatible changes) before shipping. > > On Mon, Jun 26, 2023 at 12:08 PM Rick Byers <rby...@chromium.org> wrote: > >> There's clearly a lot of interop risk around all the different proposals >> in this space. At the same time, it's clear this is one of the most >> important aspects to the ads industry and so the huge amount of >> collaborative experimentation and open sharing of information on pros/cons >> seems net beneficial to the industry to me. I'm optimistic that we'll see >> convergence over time. >> >> On Mon, Jun 26, 2023 at 6:01 AM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> A few words with my spec-mentor hat on: >>> * I reviewed the specification, and I believe it is well-integrated with >>> other web platform specifications. >>> * There's one case where I think the algorithm can be more precise >>> <https://github.com/WICG/attribution-reporting-api/issues/806>, but I >>> wouldn't consider this a blocker. >>> * The choice of JSON header values is non-orthodox, but I was convinced >>> that Structured Fields cannot support the API's use case. (due to nesting) >>> * There are 85 open issues. It'd probably be good to give them labels >>> that'd enable reviewers to see how many of them may impact compat. >>> >> >> +1. I spent 30 min looking over open issues, and while many didn't have >> responses yet they largely all felt like possible future extensions. Here's >> a couple which seemed to me to be worthy of at least a response or >> follow-up (if not a resolution) before I'd be comfortable approving the >> I2S. There may be others though, so I'd appreciate at least a quick triage >> pass by experts on the team to focus API owner attention on the issues >> which may cause future compat problems or otherwise inhibit an >> interoperable implementation. >> >> https://github.com/WICG/attribution-reporting-api/issues/488 >> https://github.com/WICG/attribution-reporting-api/issues/221 >> https://github.com/WICG/attribution-reporting-api/issues/220 >> https://github.com/WICG/attribution-reporting-api/issues/358 >> >> * One thing I just now realized (apologies for not catching this sooner), >>> is that it'd be better to fully integrate the FencedFrames monkeypatch >>> <https://wicg.github.io/attribution-reporting-api/#fenced-frame-monkeypatches> >>> into the FencedFrames spec. I wouldn't consider this a blocker to shipping. >>> >>> On Fri, Jun 23, 2023 at 9:03 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> On Tue, Jun 20, 2023 at 10:35 PM John Delaney <johni...@chromium.org> >>>> wrote: >>>> >>>>> Contact emails >>>>> >>>>> johni...@chromium.org, csharri...@chromium.org >>>>> >>>>> Explainer >>>>> >>>>> https://github.com/WICG/conversion-measurement-api/blob/main/EVENT.md >>>>> >>>>> >>>>> https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md >>>>> >>>>> >>>>> https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATION_SERVICE_TEE.md >>>>> >>>>> Specification >>>>> >>>>> https://wicg.github.io/conversion-measurement-api >>>>> >>>>> Summary >>>>> >>>>> This API measures ad conversions (e.g. purchases) and attributes them >>>>> to ad interactions without using cross-site persistent identifiers like >>>>> third-party cookies. The API allows measurement through both event-level >>>>> reports sent directly from the browser, and aggregatable reports which can >>>>> be processed through a trusted service to create summary reports of >>>>> attribution data. >>>>> >>>>> While we believe the current version of the API covers the core use >>>>> cases, we are working in parallel to ship future updates with a number of >>>>> auxiliary features that are still in development, including multiple >>>>> aggregation service coordinator support and report verification, among >>>>> others. >>>>> >>>>> 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 >>>>> >>>>> TAG review status >>>>> >>>>> Pending >>>>> >>>>> Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> There are several other different attribution measurement proposals >>>>> from a variety of browser vendors and companies, each offering different >>>>> forms of privacy and utility. >>>>> >>>>> Safari has proposed and implemented Private Click Measurement ( >>>>> https://privacycg.github.io/private-click-measurement/). >>>>> >>>> >>>> Can you expand (or point to existing docs) about the differences >>>> between this and PCM? What's the likelihood of future convergence? What are >>>> developers expected to do in the meantime? >>>> >>>> >>>>> >>>>> Interoperable Private Attribution ( >>>>> https://github.com/patcg-individual-drafts/ipa/blob/main/IPA-End-to-End.md) >>>>> has been proposed by Mozilla and Meta for Private Measurement within the >>>>> Private Advertising Technology Community Group. See >>>>> https://github.com/patcg-individual-drafts/ipa/issues/59 for our >>>>> position on this proposal. >>>>> >>>> >>>> I appreciate y'all's engagement with that proposal and your commitment >>>> <https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/chrome-shipping/#:~:text=Chrome%20would%20provide%20a%20careful%20migration%20to%20any%20possible%20interoperable%20replacement.> >>>> . >>>> >>>> >>>>> >>>>> Gecko: No official position ( >>>>> https://github.com/mozilla/standards-positions/issues/791) >>>>> >>>>> WebKit: No official position ( >>>>> https://github.com/WebKit/standards-positions/issues/180) >>>>> >>>>> Web developers: Positive engagement in origin trial from 9+ testers >>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/ara-tester-list.md> >>>>> >>>>> See the post: Why Chrome plans to ship the Attribution Reporting API ( >>>>> https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/chrome-shipping/) >>>>> for additional context on interop risk and how we are thinking about the >>>>> other proposals and the active work being done in this space. >>>>> >>>>> Ergonomics >>>>> >>>>> Attribution Reporting allows integration via HTTP headers and common >>>>> loading APIs, which are widely used for attribution measurement today to >>>>> ease adoption. >>>>> >>>>> >>>>> Activation >>>>> >>>>> A successful API flow involves registering multiple events across >>>>> multiple different navigations/pages. API reports contain either coarse or >>>>> encrypted information that can be difficult to compare directly with >>>>> cookie-based measurement. The current proposal includes a debugging mode >>>>> to >>>>> facilitate testing and integration. >>>>> >>>>> >>>>> WebView application risks >>>>> >>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> >>>>> No >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> The proposal includes debugging features ( >>>>> https://wicg.github.io/attribution-reporting-api/#issue-verbose-debug-report-request), >>>>> which are gated behind SameSite=None cookies to support migration from >>>>> existing cookie-based measurement to the Attribution Reporting API. >>>>> >>>>> Developer documentation on debug reports: Debug Attribution Reporting >>>>> <https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting-debugging/> >>>>> >>>>> Developer documentation on Noise Lab: Experiment with summary report >>>>> design decisions >>>>> <https://developer.chrome.com/docs/privacy-sandbox/summary-reports/design-decisions/> >>>>> >>>>> Attribution Reporting API Internals: chrome://attribution-internals/ >>>>> >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>> >>>>> No, this feature is not supported on Android WebView. We plan to >>>>> support WebView attribution measurement through Cross App and Web >>>>> Attribution Reporting ( >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/gTvI5x-qex8/m/tK2huQq9AwAJ >>>>> ) >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> Reports sent through the API are subject to large delays and noise. Most >>>>> tests >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/attribution-reporting/> >>>>> are currently internal web tests, and we are proposing new WebDriver >>>>> APIs <https://github.com/WICG/attribution-reporting-api/pull/843> to >>>>> support testing via web-platform-tests. See this doc >>>>> <https://docs.google.com/document/d/1WZ_absA9vSyeWNyzyrb8SEKiQdmV_bJUs3IZEsSB7lc/edit> >>>>> for more information on the complexities of testing this feature. >>>>> >>>>> DevTrial instructions >>>>> >>>>> >>>>> https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/ >>>>> >>>>> Requires code in //chrome? >>>>> >>>>> False >>>>> >>>>> Tracking bug >>>>> >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1014604 >>>>> >>>>> Estimated milestones >>>>> >>>>> We intend to do an incremental ramp to 100% in Stable starting with >>>>> Chrome Release M115 (see https://chromiumdash.appspot.com/schedule). >>>>> >>>>> >>>>> Anticipated spec changes >>>>> >>>>> We have a number of auxiliary features we are planning to add support >>>>> for: >>>>> >>>>> - >>>>> >>>>> Report verification >>>>> >>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/report_verification.md> >>>>> - >>>>> >>>>> Flexible event-level configurations >>>>> >>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md> >>>>> - >>>>> >>>>> Support for multiple aggregation services >>>>> >>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#data-processing-through-a-secure-aggregation-service> >>>>> - >>>>> >>>>> Custom lookback windows >>>>> <https://github.com/WICG/attribution-reporting-api/issues/769> >>>>> - >>>>> >>>>> Aggregate debug reporting >>>>> >>>>> <https://github.com/WICG/attribution-reporting-api/issues/705#issuecomment-1529717079> >>>>> >>>>> >>>>> These are backwards compatible changes which add new reporting >>>>> capabilities not possible in the core API. >>>>> >>>>> We anticipate potential changes to certain parameters and limits >>>>> <https://wicg.github.io/attribution-reporting-api/#vendor-specific-values> >>>>> in response to developer feedback. >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/6412002824028160 >>>>> >>>>> Links to previous Intent discussions >>>>> >>>>> Intent to prototype: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/7B0ldtZR_68/m/GjLBu0n4DgAJ >>>>> >>>>> Intent to Experiment: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/jEnNpideO1Y/m/nlEDdjmnCgAJ >>>>> >>>>> Intent to Extend Experiment: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/jEnNpideO1Y/m/nlEDdjmnCgAJ >>>>> >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>>> -- >>>>> 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/9402d8f1-1700-4eb3-8709-eaba907784aen%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9402d8f1-1700-4eb3-8709-eaba907784aen%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/CAL5BFfUD87zTwdL-bF-TkXO9ZDZx_Zsj%2B4MJQ0LZ3PSENVRzDw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUD87zTwdL-bF-TkXO9ZDZx_Zsj%2B4MJQ0LZ3PSENVRzDw%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/CAL5BFfV9FVtJOCv6dsZz73mHGj5hVkpYpi9%3Dc3TW5kWKFp9V0w%40mail.gmail.com.
