> 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/EVENT.md > > Specification > > 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> > > > 1. > > 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 > > Links to previous Intent discussions > Previous I2S: > 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. > 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/2c31d7a1-f832-42cd-aa99-a845f609e8ben%40chromium.org.
