from:"Alex Turner"

[blink-dev] Intent to Ship: Private Aggregation API: client-side contribution merging

2024-08-16 Thread Alex Turner

Contact emailsale...@chromium.org

Explainer
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/135

Specification
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/136

Summary

Modifies the Private Aggregation API to merge histogram contributions with
the same bucket and filtering ID before embedding in the aggregatable
report's encrypted payload. Private Aggregation imposes a limit on the
number of contributions that can be embedded in a single aggregatable
report, with any additional contributions being dropped. By merging
together contributions where possible, we can get additional utility out of
the limit. Note that, ignoring the dropping of excess contributions,
merging these sorts of contributions should not have any impact on the
final outputs (i.e. summary reports).


Blink componentBlink>PrivateAggregation


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 (We have not
requested a signal for these changes specifically.)

TAG review statusPending

Risks


Interoperability and Compatibility

None


*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/805) We have not
requested a signal for this change specifically. 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) We have not
requested a signal for this change specifically.

*Web developers*: Positive (
https://github.com/patcg-individual-drafts/private-aggregation-api/issues/81
)

*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?

None


Debuggability

No new debug capabilities beyond the existing internals page
(chrome://private-aggregation-internals) and temporary debug mode. These
capabilities will reflect the merged contributions.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?

All but WebView


Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsNone

Finch feature namePrivateAggregationApiContributionMerging

Requires code in //chrome?False

Tracking bughttps://crbug.com/349980058

Launch bughttps://launch.corp.google.com/launch/4333118

Estimated milestones
Shipping on desktop 129
Shipping on Android 129

Anticipated spec changes

None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5094168719523840?gate=5075771428438016

This intent message was generated by Chrome Platform Status
.

-- 
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%2BBiFk8hn%3DnCSBg8pf7naZGqHgd8-DpOv7v0q4YokycSMG7xA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Aggregation API: filtering IDs

2024-07-17 Thread Alex Turner

On Mon, Jul 15, 2024 at 11:03 AM Mike Taylor  wrote:

> On 7/12/24 10:44 AM, Alex Turner wrote:
>
> On Wed, Jul 10, 2024 at 11:25 AM Mike Taylor 
> wrote:
>
>> On 7/8/24 4:05 PM, Alex Turner wrote:
>>
>>
>> Interoperability and Compatibility
>>
>> The Aggregation Service (used to process the aggregatable reports)
>> typically allows its releases to be used for up to six months. To reduce
>> the compatibility impact of this change, we are waiting until all current
>> Aggregation Service releases support the new version before rolling to
>> Stable.
>>
>> Can you say more about this? How many parties are running these services,
>> and do we have any way of knowing what the uptake of new versions is, or
>> said differently - can we tell if they're still on older versions?
>>
>> Also, what happens if you send the filter ID to an older version?
>>
> The Aggregation Service in general has a six-month support schedule
> <https://github.com/privacysandbox/aggregation-service/wiki/Aggregation-Service-release-and-end%E2%80%90of%E2%80%90support-plan#release-and-end-of-support-schedules>,
> i.e. attempts to use a release more than six months after it was released
> will fail. Currently, there are three Aggregation Service releases that are
> available for use (2.3, 2.4, 2.5). All previous releases (2.2 and before)
> have already reached end-of-support and can no longer be used.
>
> I see - thanks. Just a few more questions to help me understand:
>
> There's mention of an image hash allowlist - presumably this is how you
> enforce versioning on the server side. Is that correct?
>
Yep, exactly.

> Release 2.3 does not support the new report format, but we have announced
> it will reach end-of-support on August 2nd, i.e. before M128 reaches
> Stable. (Note that we have already enabled the feature on Canary for
> testing.) Attempting to process reports with the new “1.0” report version
> on this release will result in the aggregation job failing with a
> descriptive error message. In this case, however, no budget will be
> consumed and the aggregation can be re-attempted (either on a newer release
> or after excluding the “1.0” reports).
>
> Why doesn't this count as a breaking change, per your wiki page? Or the
> idea is you don't need to rev the major version number because it will be
> unsupported before this feature is usable in Chrome stable?
>

The Aggregation Service versioning scheme applies to server-side changes
only. That is, a breaking change is one that would require an active
migration for a partner when they update their Aggregation Service release.
As the processing changes on the server are backwards compatible (more
detail below), we haven't updated the major version.

When attempting to process the new “1.0” reports, the old Aggregation
Service releases (2.3 and before) error out and the new releases (2.4+)
succeed. So, we consider that new support to be backwards compatible
*server-side*.

And when attempting to additionally specify custom filtering_ids *on the
server*, Aggregation Service release 2.4 doesn’t let you (always uses the
default, discussed below in more detail), while release 2.5 does let you.
So, that change should also count as backwards compatible.

Separately, there’s a question of whether the *browser-side* API change (to
change the report version/format) is backwards compatible. While
Aggregation Service release 2.3 is available, it is a breaking change. But,
it will be backwards compatible once all current Aggregation Service
releases support the report version (before M128 Stable).

> Release 2.4 supports the new report format, but it does not allow for
> filtering_ids to be specified for the aggregation; the default value ([0])
> is always used. On this release, existing flows that do not use the new
> feature will be unaffected by the report version change.
>
> This also feels like a breakage change to me - if I'm using a supported
> service version, but I can't use the updated report version because I will
> get unexpected/inconsistent behavior with 2.5.
>

Let me clarify the behavior of Releases 2.4 and 2.5 a bit. On the web API
after this change, you can optionally specify a filtering ID for each
histogram contribution; if you don’t, the default of 0 is used. On the
server API, you can optionally specify which filtering IDs to keep (i.e.
all histogram contributions with other filtering IDs are ignored for the
aggregation). If you don’t specify any (either because 2.4 doesn’t let you
or if you use the default in 2.5), the default of keeping just filtering ID
0 is used.

So, any existing flows that don’t care about the new filtering ID feature
will behave exactly as before – all contributions are processed as

Re: [blink-dev] Intent to Ship: Private Aggregation API: filtering IDs

2024-07-12 Thread Alex Turner

On Wed, Jul 10, 2024 at 11:25 AM Mike Taylor  wrote:

>
> On 7/8/24 4:05 PM, Alex Turner wrote:
>
> Contact emails ale...@chromium.org
>
> Explainer
> https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md
>
> Specification
> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/123
>
> Summary
>
> Modifies the Private Aggregation API to add a 'filtering ID' to the
> aggregatable reports' encrypted payloads. This ID allows histogram
> contributions with different filtering IDs to be processed separately on
> the aggregation service. A list of filtering IDs could be provided in an
> aggregation query and any contributions not matching a listed ID will be
> filtered out, not contributing to the result. To support the new feature,
> we update the report version to "1.0" (from "0.1"). By the time this is
> launched to Stable, all valid aggregation service releases will support the
> new report version, avoiding backwards compatibility concerns. (Old
> releases are deprecated on a regular schedule.)
>
>
> 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 (We have
> not requested a signal for these changes specifically.)
>
> TAG review status Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
> The Aggregation Service (used to process the aggregatable reports)
> typically allows its releases to be used for up to six months. To reduce
> the compatibility impact of this change, we are waiting until all current
> Aggregation Service releases support the new version before rolling to
> Stable.
>
> Can you say more about this? How many parties are running these services,
> and do we have any way of knowing what the uptake of new versions is, or
> said differently - can we tell if they're still on older versions?
>
> Also, what happens if you send the filter ID to an older version?
>
The Aggregation Service in general has a six-month support schedule
<https://github.com/privacysandbox/aggregation-service/wiki/Aggregation-Service-release-and-end%E2%80%90of%E2%80%90support-plan#release-and-end-of-support-schedules>,
i.e. attempts to use a release more than six months after it was released
will fail. Currently, there are three Aggregation Service releases that are
available for use (2.3, 2.4, 2.5). All previous releases (2.2 and before)
have already reached end-of-support and can no longer be used.

Release 2.3 does not support the new report format, but we have announced
it will reach end-of-support on August 2nd, i.e. before M128 reaches
Stable. (Note that we have already enabled the feature on Canary for
testing.) Attempting to process reports with the new “1.0” report version
on this release will result in the aggregation job failing with a
descriptive error message. In this case, however, no budget will be
consumed and the aggregation can be re-attempted (either on a newer release
or after excluding the “1.0” reports).

Release 2.4 supports the new report format, but it does not allow for
filtering_ids to be specified for the aggregation; the default value ([0])
is always used. On this release, existing flows that do not use the new
feature will be unaffected by the report version change.

Release 2.5 supports the new report format and allows filtering_ids to be
specified for the aggregation. Developers who want to use the new feature
should upgrade to this release.

We don't currently have metrics on usage of each Aggregation Service
release, but plan to add those. Still, we have notified partners of these
considerations through the API mailing lists
<https://groups.google.com/a/chromium.org/g/shared-storage-api-announcements/c/qlL4kpdgvP0>.
We'll also remind partners of the upcoming end-of-support.

Thanks!

>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/805) We have not
> requested a signal for this change specifically. 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) We have not
> requested a signal for this change specifically.
>
> *Web developers*: Positive signals for broad feature (
> https://github.com/patcg-individual-drafts/private-aggregation-api/issues/92
> )
>
> *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?
>
> None
>
>
> Debuggability
>
> No new debug capabili

[blink-dev] Intent to Ship: Private Aggregation API: filtering IDs

2024-07-08 Thread Alex Turner

Contact emailsale...@chromium.org

Explainer
https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md

Specification
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/123

Summary

Modifies the Private Aggregation API to add a 'filtering ID' to the
aggregatable reports' encrypted payloads. This ID allows histogram
contributions with different filtering IDs to be processed separately on
the aggregation service. A list of filtering IDs could be provided in an
aggregation query and any contributions not matching a listed ID will be
filtered out, not contributing to the result. To support the new feature,
we update the report version to "1.0" (from "0.1"). By the time this is
launched to Stable, all valid aggregation service releases will support the
new report version, avoiding backwards compatibility concerns. (Old
releases are deprecated on a regular schedule.)


Blink componentBlink>PrivateAggregation


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 (We have not
requested a signal for these changes specifically.)

TAG review statusPending

Risks


Interoperability and Compatibility

The Aggregation Service (used to process the aggregatable reports)
typically allows its releases to be used for up to six months. To reduce
the compatibility impact of this change, we are waiting until all current
Aggregation Service releases support the new version before rolling to
Stable.


*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/805) We have not
requested a signal for this change specifically. 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) We have not
requested a signal for this change specifically.

*Web developers*: Positive signals for broad feature (
https://github.com/patcg-individual-drafts/private-aggregation-api/issues/92
)

*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?

None


Debuggability

No new debug capabilities beyond the existing internals page
(chrome://private-aggregation-internals) and temporary debug mode. These
capabilities do support the new filtering IDs.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?

All but Webview


Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsNone

Finch feature namePrivateAggregationApiFilteringIds

Requires code in //chrome?False

Tracking bughttps://crbug.com/330744610

Launch bughttps://launch.corp.google.com/launch/4302413

Estimated milestones
Shipping on desktop 128
Shipping on Android 128

Anticipated spec changes

None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4793172803977216?gate=5039125582577664

This intent message was generated by Chrome Platform Status
.

-- 
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%2BBiFk3Nz9owQQnA9XzYa43cLAoh53dXGQTEstn%2BStUuud--Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Aggregation debug mode for auctionReportBuyers reporting

2024-03-07 Thread Alex Turner

Alex and Yoav,

This particular addition is exposed only as an optional parameter on the
existing `AuctionAdConfig` dictionary passed to `navigator.runAdAuction()`.
So, I'm not aware of any web visibility from removing the new
`auctionReportBuyerDebugModeConfig` field (if it was already having no
effect). But please let me know if I'm missing something there.

Are you referring instead to the existing
`privateAggregation.enableDebugMode()` function? I agree that removing that
would be web visible and have this risk. However, that function is already
fully launched (as part of the I2S here
<https://groups.google.com/a/chromium.org/g/blink-dev/c/8cKaLstq2QQ/m/Udrbb4ifDQAJ>)
and isn't affected by this change.

As for why this shouldn't be an OT, alignment with the other way to enable
debug mode is a big reason. For other usages of Private Aggregation, debug
mode is enabled with a call to `privateAggregation.enableDebugMode()`. This
is tied to third-party cookie eligibility in the same way (with the
exception for Mode B).

The other major reason is that we intend for this API to be available to
all callers in order to facilitate testing and adoption of the API, which
seems at odds with OTs being intended to be run only on a limited subset of
Chrome traffic. As this API is primarily used by third-parties on a page,
there is also a potential barrier in the need to edit the top-level page.

Best,
Alex

On Thu, Mar 7, 2024 at 4:26 AM Yoav Weiss (@Shopify) 
wrote:

> Alex T - can you expand on the other debug modes that are already shipped?
> Are they also tied to 3P cookie eligibility?
>
> If so, I agree that having all these mechanisms activated together and
> stop working together makes sense.
>
> On Wed, Mar 6, 2024 at 11:04 PM Alex Russell 
> wrote:
>
>> Removal being guaranteed to be backwards compatible depends, at a
>> minimum, on nullability. As this API would, instead, be globally exposed
>> (but would not "work" when 3p cookie ineligible), addition and removal
>> present the usual crop of addition and deprecation issues.
>>
>> 3p cookie turndown is now into it's second or third year of delay, so
>> optimism about the window for growth of use feels hard to justify.
>>
>> Why shouldn't this be an OT?
>>
>> Best,
>>
>> Alex
>>
>> On Wed, Mar 6, 2024, 1:54 PM Alex Turner  wrote:
>>
>>> Hey Alex,
>>>
>>> Totally understand the concern given how difficult removing web APIs
>>> typically is. However, I think for this case removal should be much simpler
>>> as the functionality (and debug mode more generally) is already tied to
>>> third-party cookie eligibility*. In other words, after third-party cookie
>>> deprecation is fully launched, this new feature will (automatically) have
>>> no effect. At that point, removing the new field from the IDL definitions
>>> should also be fully backwards compatible as it would simply be ignored.
>>>
>>> We leaned away from an OT given that other uses of Private Aggregation's
>>> debug mode do not require an OT token and we wanted to keep the workflow
>>> across debug mode consistent. Other considerations were the increased
>>> difficulty for usage of the API in third-party iframes and the large number
>>> of expected pages impacted (i.e. likely much higher than 0.5%). We're
>>> definitely willing to commit to formally removing this feature shortly
>>> after third-party cookie deprecation is fully launched.
>>>
>>> I hope this addresses your concerns, but very happy to discuss further.
>>>
>>> (*I do want to acknowledge the exception for Mode B traffic softens this
>>> claim, but we have communicated the temporary nature of this exception in
>>> the developer documentation
>>> <https://developers.google.com/privacy-sandbox/relevance/private-aggregation#enabledebugmode>.
>>> Also, note that trying to enable debug mode already has no effect for users
>>> who have explicitly disabled third-party cookies.)
>>>
>>> Best,
>>> Alex
>>>
>>> On Wed, Mar 6, 2024 at 12:02 PM Alex Russell 
>>> wrote:
>>>
>>>> Hey all,
>>>>
>>>> This may be overfitting against my personal priors, but I'm *intensely
>>>> *skeptical of any web platform API addition that claims to be
>>>> "temporary". If we want a temporary mechanism, we can use OTs and set a
>>>> date-certain for removal and prevent over-use that would back us into a
>>>> corner.
>>>>
>>>> Without some sort of guardrail, I'm not o

Re: [blink-dev] Intent to Ship: Private Aggregation debug mode for auctionReportBuyers reporting

2024-03-06 Thread Alex Turner

Hey Alex,

Totally understand the concern given how difficult removing web APIs
typically is. However, I think for this case removal should be much simpler
as the functionality (and debug mode more generally) is already tied to
third-party cookie eligibility*. In other words, after third-party cookie
deprecation is fully launched, this new feature will (automatically) have
no effect. At that point, removing the new field from the IDL definitions
should also be fully backwards compatible as it would simply be ignored.

We leaned away from an OT given that other uses of Private Aggregation's
debug mode do not require an OT token and we wanted to keep the workflow
across debug mode consistent. Other considerations were the increased
difficulty for usage of the API in third-party iframes and the large number
of expected pages impacted (i.e. likely much higher than 0.5%). We're
definitely willing to commit to formally removing this feature shortly
after third-party cookie deprecation is fully launched.

I hope this addresses your concerns, but very happy to discuss further.

(*I do want to acknowledge the exception for Mode B traffic softens this
claim, but we have communicated the temporary nature of this exception in
the developer documentation
<https://developers.google.com/privacy-sandbox/relevance/private-aggregation#enabledebugmode>.
Also, note that trying to enable debug mode already has no effect for users
who have explicitly disabled third-party cookies.)

Best,
Alex

On Wed, Mar 6, 2024 at 12:02 PM Alex Russell 
wrote:

> Hey all,
>
> This may be overfitting against my personal priors, but I'm *intensely 
> *skeptical
> of any web platform API addition that claims to be "temporary". If we want
> a temporary mechanism, we can use OTs and set a date-certain for removal
> and prevent over-use that would back us into a corner.
>
> Without some sort of guardrail, I'm not optimistic that we'll be able to
> actually get rid of a useful debugging aid that is web-exposed.
>
> Can we reformulate this as an OT? Or is the team proposing this willing to
> document a more thorough plan for deprecation and removal, perhaps
> including reporting of use (via UMA histograms)?
>
> Best,
>
> Alex
>
> On Wednesday, March 6, 2024 at 7:49:16 AM UTC-8 Mike Taylor wrote:
>
>> LGTM2
>> On 3/6/24 5:39 AM, Yoav Weiss (@Shopify) wrote:
>>
>> LGTM1
>>
>> On Thu, Feb 29, 2024 at 7:29 PM Alex Turner  wrote:
>>
>>> Contact emails ale...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WICG/turtledove/blob/main/FLEDGE_extended_PA_reporting.md#temporary-debugging-mechanism
>>>
>>> Specification
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/118
>>>
>>> Summary
>>>
>>> Adds support for Private Aggregation’s debug mode for the per-buyer
>>> extended Private Aggregation reporting to Protected Audience sellers (aka
>>> auctionReportBuyers reporting). This is done with a new, optional
>>> auctionReportBuyerDebugModeConfig field passed to runAdAuction().
>>> auctionReportBuyers reporting is currently the only use of Private
>>> Aggregation reports that does not have a way to enable its debug mode (a
>>> temporary mechanism tied to third-party cookie eligibility that relaxes
>>> some of the API’s privacy constraints to allow for easier debugging and
>>> integration).
>>>
>>>
>>> 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 (We have
>>> not requested a signal for these changes specifically.)
>>>
>>> TAG review status Pending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> This feature is optional and backwards compatible.
>>>
>>>
>>> *Gecko*: No signal (
>>> https://github.com/mozilla/standards-positions/issues/805) We have not
>>> requested a signal for this change specifically.
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/189) We have not
>>> requested a signal for this change specifically.
>>>
>>> *Web developers*: Positive (
>>> https://github.com/WICG/turtledove/issues/709) This has been requested
>>> by developers.
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>&g

[blink-dev] Intent to Ship: Private Aggregation debug mode for auctionReportBuyers reporting

2024-02-29 Thread Alex Turner

Contact emailsale...@chromium.org

Explainer
https://github.com/WICG/turtledove/blob/main/FLEDGE_extended_PA_reporting.md#temporary-debugging-mechanism

Specification
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/118

Summary

Adds support for Private Aggregation’s debug mode for the per-buyer
extended Private Aggregation reporting to Protected Audience sellers (aka
auctionReportBuyers reporting). This is done with a new, optional
auctionReportBuyerDebugModeConfig field passed to runAdAuction().
auctionReportBuyers reporting is currently the only use of Private
Aggregation reports that does not have a way to enable its debug mode (a
temporary mechanism tied to third-party cookie eligibility that relaxes
some of the API’s privacy constraints to allow for easier debugging and
integration).


Blink componentBlink>PrivateAggregation


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 (We have not
requested a signal for these changes specifically.)

TAG review statusPending

Risks


Interoperability and Compatibility

This feature is optional and backwards compatible.


*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/805) We have not
requested a signal for this change specifically.

*WebKit*: No signal (
https://github.com/WebKit/standards-positions/issues/189) We have not
requested a signal for this change specifically.

*Web developers*: Positive (https://github.com/WICG/turtledove/issues/709)
This has been requested by developers.

*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?

None


Debuggability

This is primarily a debugging feature -- allowing the existing debug mode
for this kind of Private Aggregation reporting.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?

All but Webview


Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsNone

Finch feature namePrivateAggregationAuctionReportBuyerDebugModeConfig

Requires code in //chrome?False

Tracking bughttps://crbug.com/1513013

Launch bughttps://launch.corp.google.com/launch/4302460

Estimated milestones

We’re aiming to ship in M123.

Anticipated spec changes

None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5088927692357632

This intent message was generated by Chrome Platform Status
.

-- 
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%2BBiFkYb%3DWswXSKM%2B9ESFdgTBUdbjoDq21Q5sWJm%2BPWqqE_nw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Aggregation API: aggregation coordinator selection

2023-11-07 Thread Alex Turner

Thanks all! A small update -- we're now planning for this to ship in M121
(instead of M120).

On Mon, Oct 30, 2023 at 3:08 AM Yoav Weiss  wrote:

> LGTM3
>
> On Friday, October 27, 2023 at 11:35:52 PM UTC+2 Mike Taylor wrote:
>
>> LGTM2
>> On 10/27/23 5:13 PM, Chris Harrelson wrote:
>>
>> LGTM1
>>
>> On Fri, Oct 20, 2023 at 9:44 AM Alex Turner  wrote:
>>
>>> Contact emails
>>>
>>> ale...@chromium.org
>>>
>>> Explainer
>>> https://github.com/patcg-individual-drafts/private-aggregation-api#aggregation-coordinator-choice
>>> Specification
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/106
>>> Summary
>>>
>>> Modification to the Private Aggregation API to provide a mechanism for
>>> selecting which coordinator to use for payload encryption (from a
>>> vendor-specified allowlist). The choice of service is made with an
>>> additional option in Shared Storage’s run() and selectURL() calls, and in
>>> Protected Audience’s runAdAuction() and joinAdInterestGroup() calls. The
>>> broad approach largely aligns with Attribution Reporting’s approach (see
>>> https://chromestatus.com/feature/5197591256236032).
>>>
>>> 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 (We have not
>>> requested a signal for these changes specifically.)
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> This feature is optional and backwards compatible.
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/805) We have not
>>> requested a signal for these changes specifically. 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) We have not
>>> requested a signal for these changes specifically.
>>>
>>> Web developers: No signals
>>>
>>> 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?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> No new debug capabilities beyond the existing internals page (
>>> chrome://private-aggregation-internals) and temporary debug mode.
>>>
>>>
>>> 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>
>>> ?
>>>
>>> WPTs will be added when the feature is enabled.
>>>
>>> Flag name on chrome://flags
>>>
>>> None
>>>
>>> Finch feature name
>>>
>>> PrivateAggregationApiMultipleCloudProviders
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1481761
>>>
>>> Launch bug
>>>
>>> https://launch.corp.google.com/launch/4272421
>>>
>>> Estimated milestones
>>>
>>> We intend to ship in M120.
>>>
>>> Anticipated spec changes
>>>
>>> None
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5140711678935040
>>>
>>> Links to previous Intent discussions
>>>
>>> Original I2S
>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/8cKaLstq2QQ/m/Udrbb4ifDQAJ>,
>>> Follow-up enhancements I2S
>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/cNK_uuCaNMs/m/spuk_w4nAAAJ>
>>>
>>>
>>> This intent message was generated by Chrome Platform Status
>>> <https://chromestatus.com/>.
>>> --
>>> You received this message because you are subscribed to the Google
&

[blink-dev] Intent to Ship: Private Aggregation API: aggregation coordinator selection

2023-10-20 Thread Alex Turner

Contact emails

ale...@chromium.org

Explainer
https://github.com/patcg-individual-drafts/private-aggregation-api#aggregation-coordinator-choice
Specification
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/106
Summary

Modification to the Private Aggregation API to provide a mechanism for
selecting which coordinator to use for payload encryption (from a
vendor-specified allowlist). The choice of service is made with an
additional option in Shared Storage’s run() and selectURL() calls, and in
Protected Audience’s runAdAuction() and joinAdInterestGroup() calls. The
broad approach largely aligns with Attribution Reporting’s approach (see
https://chromestatus.com/feature/5197591256236032).

Blink component

Blink>PrivateAggregation


TAG review

https://github.com/w3ctag/design-reviews/issues/846 (We have not requested
a signal for these changes specifically.)

TAG review status

Pending

Risks

Interoperability and Compatibility

This feature is optional and backwards compatible.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/805)
We have not requested a signal for these changes specifically. 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)
We have not requested a signal for these changes specifically.

Web developers: No signals

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?

None


Debuggability

No new debug capabilities beyond the existing internals page
(chrome://private-aggregation-internals) and temporary debug mode.


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

?

WPTs will be added when the feature is enabled.

Flag name on chrome://flags

None

Finch feature name

PrivateAggregationApiMultipleCloudProviders

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1481761

Launch bug

https://launch.corp.google.com/launch/4272421

Estimated milestones

We intend to ship in M120.

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140711678935040

Links to previous Intent discussions

Original I2S
,
Follow-up enhancements I2S



This intent message was generated by Chrome Platform Status
.

-- 
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%2BBiFmJSK39%3D%3DRoWBmxnmZ2Y3h4krDKFBa_CUHAH%2BzjXj-T3A%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

2023-10-17 Thread Alex Turner

Thanks all! A quick update -- the chromestatus reviews are now all complete.

On Fri, Oct 6, 2023 at 10:37 AM Mike Taylor  wrote:

> LGTM3
> On 10/5/23 6:51 PM, Chris Harrelson wrote:
>
> LGTM2
>
> On Wed, Oct 4, 2023 at 10:46 PM Yoav Weiss  wrote:
>
>> LGTM1
>>
>> On Wed, Oct 4, 2023 at 7:17 PM Alex Turner  wrote:
>>
>>> Mike: thanks for the clarification, I've added a comment to the TAG
>>> review and kicked off those reviews in a new entry:
>>> https://chromestatus.com/feature/5148973702840320. I'll ping this
>>> thread when those reviews are complete.
>>>
>>> Yoav: yes, that's our understanding (although until enrollment is
>>> enforced there is a chance we don't have a complete view of the testers).
>>> We're in touch with a few partners who are using it that we will
>>> communicate to directly. We also have a mailing list to broadcast these
>>> kinds of updates more generally. Given that, we feel confident the impact
>>> will be minimal to those testing the API.
>>>
>>> Alex
>>>
>>> On Wed, Oct 4, 2023 at 6:50 AM Yoav Weiss 
>>> wrote:
>>>
>>>> Am I right to assume that the API is still only being used by a
>>>> relatively small number of partners to which y'all can communicate the new
>>>> constraints?
>>>>
>>>> On Monday, October 2, 2023 at 11:08:43 PM UTC+2 Mike Taylor wrote:
>>>>
>>>>> Hey Alex,
>>>>>
>>>>> Apologies for the delay. It would probably be good to make a new entry
>>>>> and request all the relevant review approvals (sorry for the extra work).
>>>>>
>>>>> Also, probably useful to drop a link in the TAG review to this Intent,
>>>>> so reviewers can eventually be aware of these changes.
>>>>> On 9/27/23 2:35 PM, Alex Turner wrote:
>>>>>
>>>>> I set this feature up as a "Web developer facing change to existing
>>>>> code", but I'm seeing that "New feature incubation" may have been more
>>>>> appropriate (although the guidance
>>>>> <https://www.chromium.org/blink/launching-features/#feature-types> is
>>>>> a bit uncertain). Unfortunately, that means chromestatus won't let me
>>>>> request any reviews other than API owners; would it make sense to create a
>>>>> new feature entry? (Note also that these changes have already gone through
>>>>> internal privacy and security reviews.)
>>>>>
>>>>> Thanks!
>>>>> Alex
>>>>>
>>>>> On Wed, Sep 27, 2023 at 12:02 PM Chris Harrelson <
>>>>> chris...@chromium.org> wrote:
>>>>>
>>>>>> Please also fill out the other chromestatus review categories for
>>>>>> this Intent, in particular for Privacy and Security, thanks.
>>>>>>
>>>>>> On Tue, Sep 26, 2023 at 11:14 PM Yoav Weiss 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 25, 2023 at 11:52 PM Alex Turner 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Contact emails ale...@chromium.org
>>>>>>>>
>>>>>>>> Specification
>>>>>>>>
>>>>>>>>-
>>>>>>>>
>>>>>>>>Null report fixes:
>>>>>>>>
>>>>>>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/91
>>>>>>>>-
>>>>>>>>
>>>>>>>>Debug mode eligibility changes:
>>>>>>>>
>>>>>>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/90
>>>>>>>>-
>>>>>>>>
>>>>>>>>Padding report payloads:
>>>>>>>>
>>>>>>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/98,
>>>>>>>>https://github.com/WICG/attribution-reporting-api/pull/1030
>>>>>>>>-
>>>>>>>>
>>>>>>>>Reducing delay:
>>>>>>>>
>>>>>>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/103
>&

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

2023-10-04 Thread Alex Turner

Mike: thanks for the clarification, I've added a comment to the TAG review
and kicked off those reviews in a new entry:
https://chromestatus.com/feature/5148973702840320. I'll ping this thread
when those reviews are complete.

Yoav: yes, that's our understanding (although until enrollment is enforced
there is a chance we don't have a complete view of the testers). We're in
touch with a few partners who are using it that we will communicate to
directly. We also have a mailing list to broadcast these kinds of updates
more generally. Given that, we feel confident the impact will be minimal to
those testing the API.

Alex

On Wed, Oct 4, 2023 at 6:50 AM Yoav Weiss  wrote:

> Am I right to assume that the API is still only being used by a relatively
> small number of partners to which y'all can communicate the new constraints?
>
> On Monday, October 2, 2023 at 11:08:43 PM UTC+2 Mike Taylor wrote:
>
>> Hey Alex,
>>
>> Apologies for the delay. It would probably be good to make a new entry
>> and request all the relevant review approvals (sorry for the extra work).
>>
>> Also, probably useful to drop a link in the TAG review to this Intent, so
>> reviewers can eventually be aware of these changes.
>> On 9/27/23 2:35 PM, Alex Turner wrote:
>>
>> I set this feature up as a "Web developer facing change to existing
>> code", but I'm seeing that "New feature incubation" may have been more
>> appropriate (although the guidance
>> <https://www.chromium.org/blink/launching-features/#feature-types> is a
>> bit uncertain). Unfortunately, that means chromestatus won't let me request
>> any reviews other than API owners; would it make sense to create a new
>> feature entry? (Note also that these changes have already gone through
>> internal privacy and security reviews.)
>>
>> Thanks!
>> Alex
>>
>> On Wed, Sep 27, 2023 at 12:02 PM Chris Harrelson 
>> wrote:
>>
>>> Please also fill out the other chromestatus review categories for this
>>> Intent, in particular for Privacy and Security, thanks.
>>>
>>> On Tue, Sep 26, 2023 at 11:14 PM Yoav Weiss 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Sep 25, 2023 at 11:52 PM Alex Turner 
>>>> wrote:
>>>>
>>>>> Contact emails ale...@chromium.org
>>>>>
>>>>> Specification
>>>>>
>>>>>-
>>>>>
>>>>>Null report fixes:
>>>>>
>>>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/91
>>>>>-
>>>>>
>>>>>Debug mode eligibility changes:
>>>>>
>>>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/90
>>>>>-
>>>>>
>>>>>Padding report payloads:
>>>>>
>>>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/98,
>>>>>https://github.com/WICG/attribution-reporting-api/pull/1030
>>>>>-
>>>>>
>>>>>Reducing delay:
>>>>>
>>>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/103
>>>>>
>>>>>
>>>>> Summary
>>>>>
>>>>> We're planning a few bundled changes to Private Aggregation:
>>>>>
>>>>>-
>>>>>
>>>>>Null report fixes: Currently reports with no contributions are
>>>>>inadvertently dropped. This change ensures that, when a context ID is
>>>>>specified, a null report is sent even if budget is denied. Separately, 
>>>>> it
>>>>>fixes a bug causing budget to always be denied for null reports.
>>>>>-
>>>>>
>>>>>Debug mode eligibility changes: Currently, debug mode is always
>>>>>available. This change only allows debug mode for callers that are 
>>>>> allowed
>>>>>access to third-party cookies, silently dropping the debug mode 
>>>>> otherwise.
>>>>>Note that this will allow debug mode to automatically sunset when
>>>>>third-party cookies are deprecated.
>>>>>-
>>>>>
>>>>>Padding report payloads: To avoid the payload size being dependent
>>>>>on the number of contributions, we will pad it with 'null' 
>>>>> contr

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

2023-09-27 Thread Alex Turner

I set this feature up as a "Web developer facing change to existing code",
but I'm seeing that "New feature incubation" may have been more appropriate
(although the guidance
<https://www.chromium.org/blink/launching-features/#feature-types> is a bit
uncertain). Unfortunately, that means chromestatus won't let me request any
reviews other than API owners; would it make sense to create a new feature
entry? (Note also that these changes have already gone through internal
privacy and security reviews.)

Thanks!
Alex

On Wed, Sep 27, 2023 at 12:02 PM Chris Harrelson 
wrote:

> Please also fill out the other chromestatus review categories for this
> Intent, in particular for Privacy and Security, thanks.
>
> On Tue, Sep 26, 2023 at 11:14 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Mon, Sep 25, 2023 at 11:52 PM Alex Turner  wrote:
>>
>>> Contact emailsale...@chromium.org
>>>
>>> Specification
>>>
>>>-
>>>
>>>Null report fixes:
>>>
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/91
>>>-
>>>
>>>Debug mode eligibility changes:
>>>
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/90
>>>-
>>>
>>>Padding report payloads:
>>>
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/98,
>>>https://github.com/WICG/attribution-reporting-api/pull/1030
>>>-
>>>
>>>Reducing delay:
>>>
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/103
>>>
>>>
>>> Summary
>>>
>>> We're planning a few bundled changes to Private Aggregation:
>>>
>>>-
>>>
>>>Null report fixes: Currently reports with no contributions are
>>>inadvertently dropped. This change ensures that, when a context ID is
>>>specified, a null report is sent even if budget is denied. Separately, it
>>>fixes a bug causing budget to always be denied for null reports.
>>>-
>>>
>>>Debug mode eligibility changes: Currently, debug mode is always
>>>available. This change only allows debug mode for callers that are 
>>> allowed
>>>access to third-party cookies, silently dropping the debug mode 
>>> otherwise.
>>>Note that this will allow debug mode to automatically sunset when
>>>third-party cookies are deprecated.
>>>-
>>>
>>>Padding report payloads: To avoid the payload size being dependent
>>>on the number of contributions, we will pad it with 'null' contributions 
>>> to
>>>a fixed length. **Note**: this change will also affect Attribution
>>>Reporting’s aggregatable reports.
>>>-
>>>
>>>Reducing delay: When a context ID is specified, we remove the
>>>randomized 10-60 minute delay, which is superfluous as a report is always
>>>sent in this case. Instead, we just wait until the Shared Storage 
>>> operation
>>>timeout.
>>>
>>>
>>> Blink componentBlink>PrivateAggregation
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPrivateAggregation>
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 (We have
>>> not requested a signal for these changes specifically.)
>>>
>>> TAG review statusPending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>- Null report fixes: Increases the number of reports sent to
>>>reporting endpoints, reporting endpoints using plaintext debug payloads
>>>will need to handle the null report case.
>>>
>>> Do you know if current reporting endpoints are ready to handle this
>> change?
>>
>>>
>>>- Debug mode eligibility changes: Backwards incompatible for callers
>>>using enableDebugMode() without third-party cookie eligibility.
>>>
>>> Were callers already ready to have the enableDebugMode() call fail? Does
>> it throw, or silently fails?
>>
>>>
>>>- Padding report payloads: Compatible with existing aggregation
>>>service versions. Reporting endpoints will see larger payloads and null
>>>contributions added to the plaintext debug payloads (if used).
>>>- Reducing delay: Should not require any reporting endpo

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

2023-09-27 Thread Alex Turner

On Wed, Sep 27, 2023 at 2:14 AM Yoav Weiss  wrote:

>
>
> On Mon, Sep 25, 2023 at 11:52 PM Alex Turner  wrote:
>
>> Contact emailsale...@chromium.org
>>
>> Specification
>>
>>-
>>
>>Null report fixes:
>>https://github.com/patcg-individual-drafts/private-aggregation-api/pull/91
>>-
>>
>>Debug mode eligibility changes:
>>https://github.com/patcg-individual-drafts/private-aggregation-api/pull/90
>>-
>>
>>Padding report payloads:
>>
>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/98,
>>https://github.com/WICG/attribution-reporting-api/pull/1030
>>-
>>
>>Reducing delay:
>>
>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/103
>>
>>
>> Summary
>>
>> We're planning a few bundled changes to Private Aggregation:
>>
>>-
>>
>>Null report fixes: Currently reports with no contributions are
>>inadvertently dropped. This change ensures that, when a context ID is
>>specified, a null report is sent even if budget is denied. Separately, it
>>fixes a bug causing budget to always be denied for null reports.
>>-
>>
>>Debug mode eligibility changes: Currently, debug mode is always
>>available. This change only allows debug mode for callers that are allowed
>>access to third-party cookies, silently dropping the debug mode otherwise.
>>Note that this will allow debug mode to automatically sunset when
>>third-party cookies are deprecated.
>>-
>>
>>Padding report payloads: To avoid the payload size being dependent on
>>the number of contributions, we will pad it with 'null' contributions to a
>>fixed length. **Note**: this change will also affect Attribution
>>Reporting’s aggregatable reports.
>>-
>>
>>Reducing delay: When a context ID is specified, we remove the
>>randomized 10-60 minute delay, which is superfluous as a report is always
>>sent in this case. Instead, we just wait until the Shared Storage 
>> operation
>>timeout.
>>
>>
>> Blink componentBlink>PrivateAggregation
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPrivateAggregation>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 (We have
>> not requested a signal for these changes specifically.)
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>- Null report fixes: Increases the number of reports sent to
>>reporting endpoints, reporting endpoints using plaintext debug payloads
>>will need to handle the null report case.
>>
>> Do you know if current reporting endpoints are ready to handle this
> change?
>
This should only affect endpoints that are using the debug payloads. For
them, the reports should look similar, but they will need to allow for a
contribution's value to be zero (for both this change and the padding
change). While this is already possible today, it's probably not used. I'll
plan to highlight this requirement when we send out notifications to the
developer mailing lists.

>
>>- Debug mode eligibility changes: Backwards incompatible for callers
>>using enableDebugMode() without third-party cookie eligibility.
>>
>> Were callers already ready to have the enableDebugMode() call fail? Does
> it throw, or silently fails?
>
Calling enableDebugMode() from an ineligible context will silently fail --
i.e. no error, but debug mode won't be enabled.

>
>>- Padding report payloads: Compatible with existing aggregation
>>service versions. Reporting endpoints will see larger payloads and null
>>contributions added to the plaintext debug payloads (if used).
>>- Reducing delay: Should not require any reporting endpoint changes,
>>reports will simply arrive earlier.
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/805). We have not
>> requested a signal for these changes specifically. 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). We have not
>> requested a signal for these changes specifically
>>
>> *Web developers*: Positive for reducing delay
>>
>> *Other signals*:
>>
>> WebView application risks
&

[blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

2023-09-25 Thread Alex Turner

Contact emailsale...@chromium.org

Specification

Null report fixes:
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/91
-

Debug mode eligibility changes:
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/90
-

Padding report payloads:
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/98,
https://github.com/WICG/attribution-reporting-api/pull/1030
-

Reducing delay:
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/103

Summary

We're planning a few bundled changes to Private Aggregation:

Null report fixes: Currently reports with no contributions are
inadvertently dropped. This change ensures that, when a context ID is
specified, a null report is sent even if budget is denied. Separately, it
fixes a bug causing budget to always be denied for null reports.
-

Debug mode eligibility changes: Currently, debug mode is always
available. This change only allows debug mode for callers that are allowed
access to third-party cookies, silently dropping the debug mode otherwise.
Note that this will allow debug mode to automatically sunset when
third-party cookies are deprecated.
-

Padding report payloads: To avoid the payload size being dependent on
the number of contributions, we will pad it with 'null' contributions to a
fixed length. **Note**: this change will also affect Attribution
Reporting’s aggregatable reports.
-

Reducing delay: When a context ID is specified, we remove the randomized
10-60 minute delay, which is superfluous as a report is always sent in this
case. Instead, we just wait until the Shared Storage operation timeout.

Blink componentBlink>PrivateAggregation

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 (We have not
requested a signal for these changes specifically.)

TAG review statusPending

Risks

Interoperability and Compatibility

- Null report fixes: Increases the number of reports sent to reporting
endpoints, reporting endpoints using plaintext debug payloads will need to
handle the null report case.
- Debug mode eligibility changes: Backwards incompatible for callers
using enableDebugMode() without third-party cookie eligibility.
- Padding report payloads: Compatible with existing aggregation service
versions. Reporting endpoints will see larger payloads and null
contributions added to the plaintext debug payloads (if used).
- Reducing delay: Should not require any reporting endpoint changes,
reports will simply arrive earlier.

*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/805). We have not
requested a signal for these changes specifically. 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). We have not
requested a signal for these changes specifically

*Web developers*: Positive for reducing delay

*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?

None

Debuggability

No new debug capabilities beyond the existing internals page
(chrome://private-aggregation-internals) and temporary debug mode.

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

?WPTs will be added when features are enabled.

Flag name on chrome://flagsNone

Finch feature namePadding: PrivacySandboxAggregationServiceReportPadding
All other features: PrivateAggregationApiBundledEnhancements

Requires code in //chrome?Only for settings checks

Tracking bughttps://crbug.com/1481761

Launch bughttps://launch.corp.google.com/launch/4272421

Estimated milestones

We intend to ship in M119.

Anticipated spec changes
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5205079858085888

Links to previous Intent discussions

Previous I2S

This intent message was generated by Chrome Platform Status
.

--
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%2BBiF%3DMBk5ra9sn9i4ajaNSd9aMFKE_9DpxE8pziGY6YXB9Mg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Aggregation API

2023-07-10 Thread Alex Turner

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  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  wrote:
>>
>>>
>>>
>>> On Thu, Jul 6, 2023 at 8:42 PM Rick Byers  wrote:
>>>
>>>> On Wed, Jun 28, 2023 at 12:34 PM Alex Turner 
>>>> wrote:
>>>>
>>>>>
>>>>> On Wed, Jun 28, 2023 at 11:53 AM Rick Byers 
>>>>> wrote:
>>>>>
>>>>>> On Mon, Jun 26, 2023 at 12:32 PM Yoav Weiss 
>>>>>> 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 
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 20, 2023 at 5:39 PM Rick Byers 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 20, 2023 at 4:51 PM Alex Turner 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Contact emailsale...@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 
>>>>>>>>>&

Re: [blink-dev] Intent to Ship: Private Aggregation API

2023-07-07 Thread Alex Turner

On Thu, Jul 6, 2023 at 8:42 PM Rick Byers  wrote:

> On Wed, Jun 28, 2023 at 12:34 PM Alex Turner  wrote:
>
>>
>> On Wed, Jun 28, 2023 at 11:53 AM Rick Byers  wrote:
>>
>>> On Mon, Jun 26, 2023 at 12:32 PM Yoav Weiss 
>>> 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  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 20, 2023 at 5:39 PM Rick Byers 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Tue, Jun 20, 2023 at 4:51 PM Alex Turner 
>>>>>> wrote:
>>>>>>
>>>>>>> Contact emailsale...@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 componentBlink>PrivateAggregation
>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPrivateAggregation>
>>>>>>>
>>>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846
>>>>>>>
>>>>>>> TAG review statusPending
>>>>>>>
>>>>>>> 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
>>>>>>

Re: [blink-dev] Intent to Ship: Private Aggregation API

2023-06-28 Thread Alex Turner

On Wed, Jun 28, 2023 at 11:53 AM Rick Byers  wrote:

> On Mon, Jun 26, 2023 at 12:32 PM Yoav Weiss 
> 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  wrote:
>>
>>>
>>>
>>> On Tue, Jun 20, 2023 at 5:39 PM Rick Byers  wrote:
>>>
>>>>
>>>> On Tue, Jun 20, 2023 at 4:51 PM Alex Turner 
>>>> wrote:
>>>>
>>>>> Contact emailsale...@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 componentBlink>PrivateAggregation
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPrivateAggregation>
>>>>>
>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846
>>>>>
>>>>> TAG review statusPending
>>>>>
>>>>> 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
>>>>>
>>

Re: [blink-dev] Intent to Ship: Private Aggregation API

2023-06-21 Thread Alex Turner

On Tue, Jun 20, 2023 at 5:39 PM Rick Byers  wrote:

>
> On Tue, Jun 20, 2023 at 4:51 PM Alex Turner  wrote:
>
>> Contact emailsale...@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 componentBlink>PrivateAggregation
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPrivateAggregation>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846
>>
>> TAG review statusPending
>>
>> 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?
> +math...@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!


>
> Flag nameprivacy-sandbox-ads-apis
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1316659
>>
>> Launch bughttps://crbug.com/1292756
>>
>> Estimated milestonesWe intend to start an incremental ramp towards 100%
>> in Stable starting with M115.
>>
>> Anticipated spec changes
>>
>> A few changes to current behavior are expected inc

[blink-dev] Intent to Ship: Private Aggregation API

2023-06-20 Thread Alex Turner

Contact emailsale...@chromium.org

Explainerhttps://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 componentBlink>PrivateAggregation

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846

TAG review statusPending

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?

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

Reports sent through the API are subject to large delays and require
overriding a public key endpoint. Some end-to-end tests

are currently internal web tests. Where possible, tests are external

and we are proposing new WebDriver APIs

to support testing via web-platform-tests. Tests for the integration with
Protected Audience are in-progress and should
land soon.

Flag nameprivacy-sandbox-ads-apis

Requires code in //chrome?False

Tracking bughttps://crbug.com/1316659

Launch bughttps://crbug.com/1292756

Estimated milestonesWe 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
)
and padding the encrypted payload (issue
).
Extensions to the API to support multiple aggregation services, enable
Protected Audience report verification
,
and allow arrays of contributions (issue
)
are also expected and are purely additive. The JS interface for all of
these changes will be backwards compatible with the current API.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5743412790689792

Links to previous Intent discussionsIntent 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
.

Re: [blink-dev] Re: FYI Privacy Sandbox Ads APIs origin trial

2023-01-11 Thread Alex Turner

Hi all,

The Private Aggregation API 
 origin 
trial population has now increased to include 50% of Chrome Beta users.

Best,
Alex
On Friday, November 4, 2022 at 12:33:51 PM UTC-4 Josh Karlin wrote:

> We are continuing to increase the Privacy Sandbox Relevance and 
> Measurement origin trial population:
>
>- Attribution Reporting and Topics API's availability has increased to 
>5% of Chrome Stable users.
>- FLEDGE and Fenced Frames are on schedule to increase to 5% starting 
>on the 9th of November.
>- Shared Storage’s selectURL API will also begin ramping up to 1% of 
>Chrome Stable users on the 9th of November.
>
> We will continue to post updates as we progress and, as always, you can 
> find overall developer guidance on 
> https://developer.chrome.com/docs/privacy-sandbox/unified-origin-trial/. 
> You can sign up to the origin trial on 
> https://developer.chrome.com/origintrials/#/view_trial/771241436187197441.
>
> Josh
>
> On Mon, Oct 24, 2022 at 12:08 PM Josh Karlin  wrote:
>
>> This week, no sooner than October 26, we will begin increasing the 
>> Privacy Sandbox Relevance and Measurement origin trial population towards 
>> 5% of Chrome Stable users for Attribution Reporting and Topics APIs. You 
>> can expect to see traffic levels increase over a period of a few days. 
>> Pre-stable channels, Canary and Beta, will continue as is with a 50/50 
>> split for origin trial eligibility.
>>
>> FLEDGE and Fenced Frames will increase to 5% starting on the 9th of 
>> November.
>>
>> We will continue updating this thread as we proceed with these changes 
>> and there will be a matching blog post live shortly. You can also find more 
>> information on managing your participation in the origin trial in our 
>> developer documentation.
>>
>> Josh
>>
>> https://developer.chrome.com/docs/privacy-sandbox/unified-origin-trial/
>> https://developer.chrome.com/blog/
>>
>>
>> On Tue, Oct 18, 2022 at 4:19 PM Josh Karlin  wrote:
>>
>>> Correction, the Private Aggregation API is available in canary/dev. 
>>>
>>> Josh
>>>
>>> On Tue, Oct 18, 2022 at 4:15 PM Josh Karlin  
>>> wrote:
>>>
 Hey folks. The Private Aggregation API 
  
 is 
 now available within Shared Storage and FLEDGE worklets on canary/dev/beta 
 at 50%. 

 Best,

 Josh

 On Wed, Sep 21, 2022 at 11:59 AM Paul Jensen  
 wrote:

> Hi folks. In regards to the FLEDGE bug and subsequent ramp down of 
> FLEDGE for Chrome Stable, I wanted to bring your attention to a post 
> from the FLEDGE API Announce list yesterday 
> 
>  that 
> impacts experimenters:
>
> "We fixed the bug and are ramping the origin trial back up on desktop 
> and Android, to make FLEDGE available for 1% of Stable users, on pages 
> that 
> provide a valid trial token, as the Topics and Attribution Reporting APIs 
> are now."
>
> Paul
>
> On Friday, September 9, 2022 at 3:01:55 PM UTC-4 Josh Karlin wrote:
>
>> Topics, Fenced Frames, and Attribution Reporting are now ramping up 
>> to 1% on Android stable. 
>>
>> Josh
>>
>> On Thu, Sep 1, 2022 at 2:01 PM Josh Karlin  
>> wrote:
>>
>>> Hi folks. I wanted to bring your attention to a post from FLEDGE 
>>> API Announce 
>>> 
>>>  
>>> list today that impacts experimenters:
>>>
>>> "We've discovered a bug in FLEDGE, so we are ramping down FLEDGE for 
>>> Chrome Stable in the Privacy Sandbox Relevance and Measurement 
>>> origin trial 
>>> .
>>>  
>>> Other APIs in the trial are unaffected.
>>>
>>> We've identified a fix for the bug and are working to validate it 
>>> and re-enable the origin trial for FLEDGE with the fix soon (roughly 
>>> two 
>>> weeks from now if all goes well)."
>>>
>>> Best,
>>>
>>> Josh
>>>
>>> On Wed, Aug 24, 2022 at 8:29 AM Josh Karlin  
>>> wrote:
>>>
 Hey folks. Shared Storage's 
  
 selectURL() 
 operation will begin to ramp up on canary/dev/beta in the next 24 
 hours at 
 50%. Aggregate reporting is forthcoming.

 Best,

 Josh

 On Thu, Aug 11, 2022 at 11:39 AM Josh Karlin  
 wrote:

> We've been asked if canary/dev/beta will continue to hold at 50% 
> while stable is at 1%. Yes, the pre-stable channels will continue at 
> 50%.
>
> On

[blink-dev] Intent to Experiment: Private Aggregation API

2022-10-05 Thread Alex Turner

Contact emails


*ale...@chromium.org , johni...@chromium.org
*Explainer


*https://github.com/patcg-individual-drafts/private-aggregation-api
*
Specification


*TBD*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 componentBlink>PrivateAggregation

TAG review


*Will be requested shortly*TAG review status


*Not yet requested*Risks

Interoperability and Compatibility





*Gecko: No signalWebKit: No signalWeb developers: Some interest for using
in Shared Storage worklets for fraud and abuse
,
and frequency capping model calibration

use cases. Strong interest for use in FLEDGE worklets for a wide range of
use cases, especially in the long term where event-level reporting is no
longer available
.Other
signals:*WebView application risks



*N/A*Goals for experimentation


*The goal for the experiment is to seek feedback on the utility of the
aggregated measurement available through the API and whether it satisfies
the expected use cases for reporting from FLEDGE and Shared Storage
worklets .*Experiment
Configuration


*As this API is (currently) only available from within FLEDGE and Shared
Storage worklets, this API will join the unified Privacy Sandbox Ads APIs
origin trial (OT)
.
No additional OT configuration will be necessary for FLEDGE and Shared
Storage experimenters. Initially, the Private Aggregation API will only be
enabled for OT participants on Canary/Dev channels. As we gain confidence
that the API is working properly, we will enable the API for all OT
participants on the beta channel and eventually the stable channel.*Ongoing
technical constraints


*None*Debuggability


*The proposal includes a temporary debugging mechanism

to facilitate testing and integration.*Will this feature be supported on
all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and
Android WebView)?


*Not supported on Android WebView*Is this feature fully tested by
web-platform-tests

?


*No, but will be before shipping*Flag name


*The API can be enabled using chrome://flags/#privacy-sandbox-ads-apis*Requires
code in //chrome?


*None other than the Privacy Sandbox Settings UI*Launch bug


*https://crbug.com/1292756 *Estimated milestones


*We hope to start the experiment during M107 beta. After being fully ramped
up, the experiment timeline will be shared with the other Privacy Sandbox
Ads APIs in the unified origin trial
;
see also the recent Intent to Extend Experiment
.*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


-- 
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%2BBiF%3DKQYXEVn%3DB4rMabH14UdYyA%2BF8qQkWyUVPB0rypS1N0Q%40mail.gmail.com.

[blink-dev] Intent to Prototype: Private Aggregation API

2022-05-06 Thread Alex Turner

Contact emails

ale...@chromium.org

Explainer

https://github.com/alexmturner/private-aggregation-api

Specification

None yet

Summary

Blink component

Blink>PrivateAggregation

Motivation

Relative to cross-site data from each user, aggregate, noisy data can leak
less information about individual users, and yet would be sufficient for a
wide range of use cases that rely on third-party cookies today. An aggregation
service

has been proposed to allow reporting noisy, aggregated cross-site data.
This service was originally proposed for use by the Attribution Reporting
API
,
but allowing more general aggregation would support additional use cases.

Initial public proposal

TAG review

TAG review status

Not yet filed

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Debuggability

Is this feature fully tested by web-platform-tests

Not yet, but will be.

Flag name

PrivacySandboxPrivateAggregation

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5743412790689792

--
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%2BBiFkKSt4YBNUn2h42G3z%2BqjwxjFAo%3DsPnrbvvOoNaDa_aAQ%40mail.gmail.com.

[blink-dev] Intent to Ship: Private Aggregation API: client-side contribution merging

Re: [blink-dev] Intent to Ship: Private Aggregation API: filtering IDs

Re: [blink-dev] Intent to Ship: Private Aggregation API: filtering IDs

[blink-dev] Intent to Ship: Private Aggregation API: filtering IDs

Re: [blink-dev] Intent to Ship: Private Aggregation debug mode for auctionReportBuyers reporting

Re: [blink-dev] Intent to Ship: Private Aggregation debug mode for auctionReportBuyers reporting

[blink-dev] Intent to Ship: Private Aggregation debug mode for auctionReportBuyers reporting

Re: [blink-dev] Intent to Ship: Private Aggregation API: aggregation coordinator selection

[blink-dev] Intent to Ship: Private Aggregation API: aggregation coordinator selection

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

[blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

Re: [blink-dev] Intent to Ship: Private Aggregation API

Re: [blink-dev] Intent to Ship: Private Aggregation API

Re: [blink-dev] Intent to Ship: Private Aggregation API

Re: [blink-dev] Intent to Ship: Private Aggregation API

[blink-dev] Intent to Ship: Private Aggregation API

Re: [blink-dev] Re: FYI Privacy Sandbox Ads APIs origin trial

[blink-dev] Intent to Experiment: Private Aggregation API

[blink-dev] Intent to Prototype: Private Aggregation API

22 matches

Site Navigation

Mail list logo

Footer information