Thanks Akash.
This is not quite the level of detail I was hoping for (I've more or
less grokked that from the commits themselves), but I'm satisfied with
the compat implications of always requiring the ar_debug cookie.
LGTM1
On 4/26/24 5:10 PM, Akash Nadan wrote:
Hi Mike,
We have not fully considered adding this functionality to WPT and it
may be challenging due to delays and noise added by the Attribution
Reporting API, but we will evaluate what is possible here.
Thanks - even if challenging, this is super important for long-term
interop. So whatever we can do to improve the status quo will be
worthwhile, IMHO.
Thanks for the suggestions regarding the features. We will make sure
to break apart the I2S based on features that can be grouped together
in the future.
Regarding the motivation for the features:
1. Spec verbose debug report for max channel capacity and max trigger
states cardinality
<https://github.com/WICG/attribution-reporting-api/pull/1223>
For debugging completeness of potential errors that can occur. This is
an important debug error signal for the flexible event level reporting
feature.
2. Report source reporting origins per site limit explicitly
<https://github.com/WICG/attribution-reporting-api/pull/1225>
For debugging completeness of potential errors.
3. Gate all source verbose debug reports behind cookie access
<https://github.com/WICG/attribution-reporting-api/pull/1204>
For reducing complexity across all source verbose debug reports by
applying the same requirement across all of them.
4. Split attribution rate-limit into separate event & aggregate
rate-limits <https://github.com/WICG/attribution-reporting-api/pull/1211>
For the ability to properly account for report deletions and support
the flexible event level reporting feature (which may produce more
than 1 event report per trigger registration, whereas aggregate
reports would not).
Regarding the interoperability and compatibility question, it is
currently not possible to register for a specific error signal. The
API caller would register to receive a debug report and the API then
provides the error that occurs (assuming an error occurs).
Additionally, it would be extremely unlikely for sites to only be
interested in the source-destination-limit and
source-destination-rate-limit errors, since they would most likely be
interested in also understanding any error signals that may be
impacting their conversions as well.
Thanks,
Akash
On Thursday, April 25, 2024 at 11:17:05 AM UTC-7 Mike Taylor wrote:
Apologies for the delay here - it's a bit challenging to review 4
features at once.
(Aside: it seems like this particular intent could have been split
into 2... one for 2 debug report features, and another for rate
limits?)
On 4/19/24 12:51 PM, 'Akash Nadan' via blink-dev wrote:
Contact emails
akash...@google.com, lin...@chromium.org, john...@chromium.org
Explainer
Attribution Reporting with event-level reports
<https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md>
Attribution Reporting API with Aggregatable Reports
<https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md>
Aggregation Service for the Attribution Reporting API
<https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.md>
Specification
https://wicg.github.io/attribution-reporting-api/
<https://wicg.github.io/attribution-reporting-api/>
Blink component
Internals > AttributionReporting
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>
Summary
We are landing the following changes to the Attribution Reporting
API focused on:
*
additional debugging support by supporting new verbose debug
reports
*
improving privacy & security by adding additional gating to
source verbose debug reports
*
improving rate limit accounting by separating the attribution
count for the two ARA report types
Explainer/Spec changes
1. Spec verbose debug report for max channel capacity and max
trigger states cardinality
<https://github.com/WICG/attribution-reporting-api/pull/1223>
2.
Report source reporting origins per site limit explicitly
<https://github.com/WICG/attribution-reporting-api/pull/1225>
3.
Gate all source verbose debug reports behind cookie access
<https://github.com/WICG/attribution-reporting-api/pull/1204>
4.
Split attribution rate-limit into separate event & aggregate
rate-limits
<https://github.com/WICG/attribution-reporting-api/pull/1211>
These are also challenging to review, as each PR doesn't have a
corresponding issue, or given a _why_, just the what (or maybe I'm
missing something). The diffs for the explainers also aren't super
enlightening. Could you write a few sentences on the motivations
for each of these changes?
Risks
Interoperability and Compatibility
(1 <https://github.com/WICG/attribution-reporting-api/pull/1223>,
2 <https://github.com/WICG/attribution-reporting-api/pull/1225>)
Additional verbose debug reports and (4
<https://github.com/WICG/attribution-reporting-api/pull/1211>)
splitting the attribution rate limit into separate limits for
event and aggregate are fully backwards compatible changes.
Feature (3
<https://github.com/WICG/attribution-reporting-api/pull/1204>)
gating all source verbose debug reports is a backwards
incompatible change because now source-destination-limit and
source-destination-rate-limit verbose debug reports now require
the ar_debug cookie to be set at source registration time. This
is not a major concern because all other current source verbose
debug signals already require the ar_debug cookie to be set and
most ad-techs would already be setting this cookie at source
registration time.
Is it reasonable to assume that there aren't sites only
registering for source-destination-limit and
source-destination-rate-limit reports? Do we have usecounters or
UKM to verify?
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
The attribution reporting feature bundle will be supported on all
platforms with the exception of Android WebView
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
Estimated milestones
This feature bundle is anticipated to ship as part ofChrome 125
<https://chromiumdash.appspot.com/schedule>.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5146883686400000
<https://chromestatus.com/feature/5146883686400000>
Links to previous Intent discussions
Previous I2S:
Intent to Ship: Attribution Reporting API
<https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY>
Intent to Ship: Attribution Reporting features M117
<https://groups.google.com/a/chromium.org/g/blink-dev/c/nWF61c8xu-M/m/uMmH1ewcAQAJ>
Intent to Ship: Attribution Reporting features M118
<https://groups.google.com/a/chromium.org/g/blink-dev/c/Mh-mJiyJZFk/m/HlgzpphYBQAJ>
Intent to Ship: Attribution Reporting features M119
<https://groups.google.com/a/chromium.org/g/blink-dev/c/6e44SBtEtcQ>
Intent to Ship: Attribution Reporting features M120
<https://groups.google.com/a/chromium.org/g/blink-dev/c/jSk3xpNPzGQ/m/VZPsdYgGCAAJ>
Intent to Ship: Attribution Reporting features M121
<https://groups.google.com/a/chromium.org/g/blink-dev/c/g9KiC6Rg_mA/m/V679WcWuAQAJ>
Intent to Ship: Attribution Reporting features M123
<https://groups.google.com/a/chromium.org/g/blink-dev/c/NE7VGke1Bjc/m/bIX00t4CAAAJ>
Intent to Ship: Attribution Reporting features M124
<https://groups.google.com/a/chromium.org/g/blink-dev/c/aregp1li6xk/m/IhBB2z8tBQAJ>
Thanks,
Akash
--
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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/194f8cc0-03b3-47e5-ad1c-0938c1a686ben%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/194f8cc0-03b3-47e5-ad1c-0938c1a686ben%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/2315138d-11ef-4988-9352-e640c927c0f4%40chromium.org.
