LGTM1 On 7/10/23 2:04 PM, Alex Turner wrote:
As a quick update, the WebDriver extension PR has now landed. (Thanks Mathias for the review!) So, it should be safe to include that change as part of this I2S.On Mon, Jul 10, 2023 at 4:00 AM Mathias Bynens <m...@google.com> wrote: Thank you for including a WebDriver extension <https://github.com/patcg-individual-drafts/private-aggregation-api/pull/64> for this; I’ve left some review feedback on the PR. Overall, I wanted to voice my support for pursuing the Web Platform feature (and this Intent) separately from the WebDriver extension, as long as you’re confident in the testing strategy — no need to block on it. On Friday, July 7, 2023 at 4:28:39 PM UTC+2 yoav...@chromium.org wrote: On Fri, Jul 7, 2023 at 3:48 PM Alex Turner <ale...@chromium.org> wrote: On Thu, Jul 6, 2023 at 8:42 PM Rick Byers <rby...@chromium.org> wrote: On Wed, Jun 28, 2023 at 12:34 PM Alex Turner <ale...@chromium.org> wrote: On Wed, Jun 28, 2023 at 11:53 AM Rick Byers <rby...@chromium.org> wrote: On Mon, Jun 26, 2023 at 12:32 PM Yoav Weiss <yoav...@chromium.org> wrote: I wanted to comment on this intent with my spec mentor hat on. I reviewed this specification and provided feedback to its authors. My main point of feedback was around its layering and how it relates to the other 2 specifications (Shared Storage and Protected Audience) that use the infrastructure that it defines. My feedback was properly addressed, and the specification was re-written such that it's unaware of its users, and its users are calling its algorithms, rather than the other way around. There's still work to be done to move the user algorithms from monkeypatch sections in this spec to their respective specifications, but I wouldn't consider that a blocker and I trust the team to do that soon. Beyond that, feedback around naming <https://github.com/patcg-individual-drafts/private-aggregation-api/issues/44> was addressed and I believe that ergonomics feedback <https://github.com/patcg-individual-drafts/private-aggregation-api/issues/70> can be addressed in a backwards compatible manner. As is, I believe the specification is in good shape to be implemented interoperably. I also believe the team is committed to improve it further on the (non-blocking) points that are still outstanding. Thanks Yoav for the spec mentorship summary. On Wed, Jun 21, 2023 at 5:33 PM Alex Turner <ale...@chromium.org> wrote: On Tue, Jun 20, 2023 at 5:39 PM Rick Byers <rby...@chromium.org> wrote: On Tue, Jun 20, 2023 at 4:51 PM Alex Turner <ale...@chromium.org> wrote: Contact emails ale...@chromium.org Explainer https://github.com/patcg-individual-drafts/private-aggregation-api Specification https://patcg-individual-drafts.github.io/private-aggregation-api Summary A generic mechanism for measuring aggregate, cross-site data in a privacy preserving manner. The potentially identifying cross-site data is encapsulated into "aggregatable reports". To prevent leakage, this data is encrypted, ensuring it can only be processed by the aggregation service. During processing, this service will add noise and impose limits on how many queries can be performed. Blink component Blink>PrivateAggregation <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPrivateAggregation> TAG review https://github.com/w3ctag/design-reviews/issues/846 TAG review status Pending Risks Interoperability and Compatibility /Gecko/: No signal specific to Private Aggregation (https://github.com/mozilla/standards-positions/issues/805). However the Gecko position on Shared Storage (one of the ways Private Aggregation is exposed) is negative. /WebKit/: No signal (https://github.com/WebKit/standards-positions/issues/189) /Web developers/: Developers have shown interest in the API both for cross-site use cases through Shared Storage and for Protected Audience aggregate reporting and have engaged on GitHub[1]. For Shared Storage, multiple testers have publicly flagged their interest via the public Shared Storage Testers List [2]. [1] https://github.com/patcg-individual-drafts/private-aggregation-api/issues [2] https://github.com/WICG/shared-storage/blob/main/shared-storage-tester-list.md /Other signals/: 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 a temporary debugging mechanism to facilitate testing and integration. An internals page (chrome://private-aggregation-internals) is also available to view the status of pending and sent reports. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? All but WebView 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 require overriding a public key endpoint. Some end-to-end tests <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/private-aggregation/shared-storage-sends-report.https.html>are currently internal web tests. Where possible, tests are external <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/private-aggregation/>and we are proposing new WebDriver APIs <https://github.com/patcg-individual-drafts/private-aggregation-api/pull/64>to support testing via web-platform-tests. Tests for the integration with Protected Audience are in-progress <http://crbug.com/1456401>and should land soon. Thanks for working to enable more automation here, and putting what you can in WPT today. I think it's reasonable to pursue this in parallel. Are you looking for approval for the WebDriver API addition now too (still a PR), or happy to send a separate I2S for that when you're ready to ship it? +mat...@chromium.org and team can advise on extending webdriver. Yeah, I think it makes sense to consolidate these together unless there are concerns with that approach. Thanks! Ok. Just discussed in the API owners meeting. Can you please get someone with webdriver spec experience (eg. @mat...@chromium.org) to review the PR? If the PR lands with such a review, then we can include it here. But if that ends up taking too long, then we suggest splitting it out for a follow-up - it doesn't need to block this feature overall. Sounds good to me! I'll start that process now. FWIW Mathias was on vacation this week but is back next week (but I'm out). Hopefully you two can connect and agree on the path here. Having automation support for testing usage of this feature makes sense to me generally, so hopefully the question is just around the details of the mechanics. I'll follow up with him on Monday, but I don't expect any major changes. Note also that we've aligned the Private Aggregation spec change <https://github.com/patcg-individual-drafts/private-aggregation-api/pull/64> with Attribution Reporting's section <https://wicg.github.io/attribution-reporting-api/#automation>. Flag name privacy-sandbox-ads-apis Requires code in //chrome? False Tracking bug https://crbug.com/1316659 Launch bug https://crbug.com/1292756 Estimated milestones We intend to start an incremental ramp towards 100% in Stable starting with M115. Anticipated spec changes A few changes to current behavior are expected including tying debug mode to third-party cookie eligibility (issue <https://github.com/patcg-individual-drafts/private-aggregation-api/issues/57>) and padding the encrypted payload (issue <https://github.com/patcg-individual-drafts/private-aggregation-api/issues/56>). Extensions to the API to support multiple aggregation services, enable Protected Audience report verification <https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/report_verification.md>, and allow arrays of contributions (issue <https://github.com/patcg-individual-drafts/private-aggregation-api/issues/44>) are also expected and are purely additive. The JS interface for all of these changes will be backwards compatible with the current API. Thanks. Skimming the open issues I see at least one <https://github.com/patcg-individual-drafts/private-aggregation-api/issues/44> which sounds like it would be a non-trivial breaking change. Are there others? Do you want to drive such issues to resolution (one way or the other) prior to shipping or make the case for why a breaking change will be doable (eg. a practical v2 migration strategy)? Can you do a quick pass over open issues looking for any others with future compat risk (i.e. potential future breaking changes) and label them as such? Just did a pass and added labels. I've also added a brief comment to each issue marked "compat" with some detail on the risk/possible mitigations. Thanks! I reviewed the current state of all these and it looks pretty low-risk to me. Alex / Yoav, any decisions there you think this I2S should still be blocked on? I agree -- I think all the remaining decisions there are low enough risk to not be blocking. Yoav, does that seem right to you? I agree that any potential future changes resulting from the open issues would be backwards compatible, so shouldn't block this intent. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5743412790689792 Links to previous Intent discussions Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFkKSt4YBNUn2h42G3z%2BqjwxjFAo%3DsPnrbvvOoNaDa_aAQ%40mail.gmail.com Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiF%3DKQYXEVn%3DB4rMabH14UdYyA%2BF8qQkWyUVPB0rypS1N0Q%40mail.gmail.com This intent message was generated by Chrome Platform Status <https://chromestatus.com/>.-- You received this messagebecause 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/CAA%2BBiFk4cb%2Bi69Symy-KCjHbtquGSQCn5scXy_YMSSWGut2vJw%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFk4cb%2Bi69Symy-KCjHbtquGSQCn5scXy_YMSSWGut2vJw%40mail.gmail.com?utm_medium=email&utm_source=footer>.-- You received this message because youare 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/CAA%2BBiF%3DAHzyktAiGjp_gbpj6aEiHdukRr%3DUfS5JGqzv3q8T%2Bcw%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiF%3DAHzyktAiGjp_gbpj6aEiHdukRr%3DUfS5JGqzv3q8T%2Bcw%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/CAA%2BBiFnqCQwMRYXyg844shcZ1XgFCnubyNm%2Bf4NFGJTmro0sJg%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFnqCQwMRYXyg844shcZ1XgFCnubyNm%2Bf4NFGJTmro0sJg%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/7cbbe10d-5d1b-8e81-6d3a-9958ddc40460%40chromium.org.
