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 <[email protected]> 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 [email protected]
wrote:
On Fri, Jul 7, 2023 at 3:48 PM Alex Turner
<[email protected]> wrote:
On Thu, Jul 6, 2023 at 8:42 PM Rick Byers
<[email protected]> wrote:
On Wed, Jun 28, 2023 at 12:34 PM Alex Turner
<[email protected]> wrote:
On Wed, Jun 28, 2023 at 11:53 AM Rick Byers
<[email protected]> wrote:
On Mon, Jun 26, 2023 at 12:32 PM Yoav Weiss
<[email protected]> 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 <[email protected]> wrote:
On Tue, Jun 20, 2023 at 5:39 PM Rick
Byers <[email protected]> wrote:
On Tue, Jun 20, 2023 at 4:51 PM
Alex Turner <[email protected]>
wrote:
Contact emails
[email protected]
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?
[email protected] 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. @[email protected]) 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 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
[email protected].
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 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 [email protected].
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 [email protected].
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 [email protected].
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.
