Thanks - the risk seems pretty low from a compat POV.
LGTM1
On 8/9/23 12:43 PM, John Delaney wrote:
> Is this based on metrics you have in front of you, or something
else? Also, what might breakage look like in this situation?
We don't have metrics measuring the usage of this key directly, but we
have checked with a number of known partners from the origin trial to
see if this was being used. Breakage in this situation, similar to
below, would not be user-visible or immediately web-visible.
Ultimately, this will cause reports to be matched/generated
differently than before, so a developer may see a different set of
reports for the same set of events, or no reports at all.
> Why would a negative duration be used today? It sounds weird, but
I've also seen "max-age=-1" w/ cookies to mean "like, now-now". Are we
aware of any usage of negative durations?
Currently, negatives are clamped to the minimum of 1 day, and don't
hold any special value. They would only be used if someone had
observed they were clamped to the minimum, and decided to rely on that
behavior rather than setting the minimum themself (or even 0). Similar
to above, we are not aware of any usage but do not have targeted
metrics for this.
On Friday, August 4, 2023 at 2:13:45 PM UTC-4 Mike Taylor wrote:
On 8/3/23 4:39 PM, John Delaney wrote:
Contact emails
johni...@chromium.org, csharri...@chromium.org
Explainer
https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#phase-1-lite-flexible-event-level
<https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#phase-1-lite-flexible-event-level>*
*
https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md
<https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.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 plan on landing a number of changes to the Attribution
Reporting API focused on:
*
registration ergonomics allowing better flexibility when
controlling whether attribution should occur based on the
time between the two events
*
support for developer controlled configurations that allow
for callers to specify the windowing scheme and number of
reports to receive for an event, in order to more efficiently
extract utility out of the privacy mechanism
Spec changes
1.
Allow expiry, event_report_window, aggregatable_report_window
fields to be integers
<https://github.com/WICG/attribution-reporting-api/pull/895>
2.
Lookback window in filters
<https://github.com/WICG/attribution-reporting-api/pull/914>
3.
Developer defined configurations for reporting windows and
maximum # of reports
<https://github.com/WICG/attribution-reporting-api/pull/856>
*
Separate verbose debug report for start time
<https://github.com/WICG/attribution-reporting-api/pull/916>
4.
Reduce min event report window time from 1 day to 1 hour and
prohibit negative durations
<https://github.com/WICG/attribution-reporting-api/pull/876>
Risks
Interoperability and Compatibility
Changes (1) (3) are all fully backwards compatible.
(2) (3) are optional, additive changes to the API surface which
allow for additional information to be provided by developers at
registration time.
(2) is largely backwards compatible except in the
case a developer was previously using a key with the name
"_lookback_window", where they will now see different behavior
when matching. We expect the API breakage to be negligible.
Is this based on metrics you have in front of you, or something
else? Also, what might breakage look like in this situation?
(4) has some marginal backwards incompatibility.
“prohibit negative durations” will result in any previous
registrations now resulting in a failure rather than being
clamped to a minimum value. In the event a registration fails,
there will be no user-visible / web-visible breakage outside of
different reports being emitted than before. That being said, we
also expect API breakage here to be negligible.
Why would a negative duration be used today? It sounds weird, but
I've also seen "max-age=-1" w/ cookies to mean "like, now-now".
Are we aware of any usage of negative durations?
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
All except 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
Chrome 117
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5089526405398528
<https://chromestatus.com/feature/5089526405398528>
Links to previous Intent discussions
Previous I2S:
https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY
<https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY>
--
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
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3c8f2f73-db97-4c39-9af4-c4c05539504cn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3c8f2f73-db97-4c39-9af4-c4c05539504cn%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/5d8d1b39-95e0-4b6a-9745-c368c9d31816%40chromium.org.
