On Wed, Jun 28, 2023 at 5:23 AM Yoav Weiss <[email protected]> wrote:
> > On Tue, Jun 27, 2023 at 9:43 PM John Delaney <[email protected]> > 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. > Reviewing the current state of those issues, it seems things are in pretty good shape, with a few small loose ends to tie up that don't seem too risky to. me. LGTM1 > >> On Mon, Jun 26, 2023 at 12:08 PM Rick Byers <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jun 20, 2023 at 10:35 PM John Delaney <[email protected]> >>>>> wrote: >>>>> >>>>>> Contact emails >>>>>> >>>>>> [email protected], [email protected] >>>>>> >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8OgcRphN%2BUYnLhGQBJOtxybRLxxhA%3D13cLXj%3DFMRSOZw%40mail.gmail.com.
