LGTM2 On Thu, Jul 6, 2023, 7:29 PM Rick Byers <rby...@chromium.org> wrote:
> On Wed, Jun 28, 2023 at 5:23 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> >> 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. >> > > 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 <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/CAFUtAY8OgcRphN%2BUYnLhGQBJOtxybRLxxhA%3D13cLXj%3DFMRSOZw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8OgcRphN%2BUYnLhGQBJOtxybRLxxhA%3D13cLXj%3DFMRSOZw%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/CAOMQ%2Bw8-cQad%3D8mExu8CcNGR_W%2BDJa916_SPWsMCQQ60r9L9jw%40mail.gmail.com.
