Replying to this thread for visibility on a vendor-specific value change.
We see from UMA metrics that ~6% of sources are being dropped due to the 1024 sources per source origin limit. The issue was also reported <https://github.com/WICG/attribution-reporting-api/issues/1103> by external testers. The limit will be increased from 1024 to 4096. This change will be effective from the Chrome Release M120. On Monday, July 10, 2023 at 3:56:53 PM UTC-4 Mike Taylor wrote: > LGTM3 > On 7/10/23 12:15 PM, Chris Harrelson wrote: > > 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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8-cQad%3D8mExu8CcNGR_W%2BDJa916_SPWsMCQQ60r9L9jw%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/a6985c86-2ec1-4203-8020-0d709e11e625n%40chromium.org.
