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. 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/CALW6VLxesPj9MY3PQXtjH4K1mRtkWTHX_OdUnbpm7k%3DzkHws%2Bw%40mail.gmail.com.
