LGTM3 On Tue, Aug 22, 2023 at 8:33 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> LGTM2 > > On Wed, Aug 9, 2023 at 6:55 PM Mike Taylor <miketa...@chromium.org> wrote: > >> 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/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/5d8d1b39-95e0-4b6a-9745-c368c9d31816%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5d8d1b39-95e0-4b6a-9745-c368c9d31816%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/CAL5BFfX%3D0JZ_4jyoQOCJssh%2BdL%2BDZsXX63XozqPMv_62hYBBzQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX%3D0JZ_4jyoQOCJssh%2BdL%2BDZsXX63XozqPMv_62hYBBzQ%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%3DoERT3VABHULoDumd1B0CeXr%3Da9uKBcJ85Vy3i0eXzA%40mail.gmail.com.
