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/EVENT.md>
https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.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
<https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATION_SERVICE_TEE.md>
Specification
https://wicg.github.io/conversion-measurement-api
<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/
<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
<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
<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
<https://github.com/mozilla/standards-positions/issues/791>)
WebKit: No official position
(https://github.com/WebKit/standards-positions/issues/180
<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/
<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
<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
<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/
<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
<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
<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
<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
<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
<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
<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>.
