Re: [blink-dev] Fwd: Intent to Extend Experiment: Protected Audience Bidding & Auction Services

['Russ Hamilton' via blink-dev]

The draft PR describes the basic API. There are some options we've recently 
added to navigator.getInterestGroupAdAuctionData()` to provide more control 
over what gets put in the encrypted request (see the explainer pull request 
here: https://github.com/WICG/turtledove/pull/1183) which are not yet 
included in the draft spec. 

On Monday, July 1, 2024 at 10:37:56 AM UTC-4 mike...@chromium.org wrote:

> I see - thanks for the info Paul. It seems like an unintentional mixup.
>
> When I approved the previous extension I wrote: "I would like to see draft 
> specifications and progress on making this testable via WPTs"
>
> Russ thanks for linking to 
> https://pr-preview.s3.amazonaws.com/brusshamilton/turtledove/pull/1200.html 
> - based on this draft PR 
> <https://github.com/WICG/turtledove/pull/1200/files>. You wrote that it 
> describes _some_ of the changes, can you speak to what is missing (that you 
> will presumably spec ahead of an I2S)?
>
> And thanks for beginning to land WPTs 
> <https://chromium-review.googlesource.com/c/chromium/src/+/5622101>. 
> On 6/28/24 1:59 PM, Paul Jensen wrote:
>
> Mike, 
>
> It looks like we did continue the OT during M122-124 before sending the 
> first I2EE, despite initially only asking for approval for M119-121.  I 
> wonder if someone went off of the current OT policy of "An initial origin 
> trial or experiment for a feature may only run for 6 milestones" 
> <https://www.chromium.org/blink/launching-features/#widen-review:~:text=An%20initial%20origin%20trial%20or%20experiment%20for%20a%20feature%20may%20only%20run%20for%206%20milestones>
>  
> without knowing my initial ask was for just 3 milestones.  I apologize for 
> that and am going to seek updating internal processes to add a check to 
> prevent this oversight from happening again, even if the initial I2EE is 
> "fairly mechanical" as you said originally.
>
> On Wednesday, June 26, 2024 at 1:53:56 PM UTC-4 Mike Taylor wrote:
>
>> Hi Russ,
>>
>> I'm trying to refresh my memory on the history of this experiment.
>>
>> Experiment first approved on 10/19/23 for M119 to M121, 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/BzI3_qoCAwAJ
>>  
>>
>> Request on 4/4/24 to renew from M124 to M127, 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/xaJHFJ_uAAAJ
>>  
>>
>> Approved 4/12/24 (“for another 3 milestones”), 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/Pm842qm_AAAJ
>>  
>>
>> Requesting M127 to M130 on 6/20/24, 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/RigQFZilAgAJ
>>  
>>
>> Question: what happened between M122 and M124? Was the experiment not 
>> running?
>>
>>
>> On 6/20/24 2:52 PM, 'Russ Hamilton' via blink-dev wrote:
>>
>> (Now *To* blink-dev instead of just CC)
>> Contact emails 
>>
>> paulj...@chromium.org, beham...@google.com
>>
>> Explainer 
>>
>> Chrome:  
>> https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md
>>
>> Services: 
>> https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md
>>
>> Note that this explainer has a helpful onboarding section 
>> <https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md#onboarding-and-alpha-testing-guide>
>>  
>> for setting up the services.
>>
>> Specification 
>>
>> A work-in-progress pull request 
>> <https://pr-preview.s3.amazonaws.com/brusshamilton/turtledove/pull/1200.html>
>>  
>> on the Protected Audience spec <https://wicg.github.io/turtledove/> 
>> describes some of the changes to the W3C spec. We are reaching out to the 
>> IETF ART Area Directors for assistance beginning the standardization 
>> process for some of the server-side aspects of this API.
>>
>> Summary 
>>
>> We propose extending the Bidding and Auction Services origin trial 
>> currently operating on 1% stable. 
>>
>> Recent changes:
>>
>>- 
>>
>>Prompted by developer concerns about scalability, we have recently 
>>added support in M127 for limiting the size of the Bidding and Auction 
>>request payload
>>- 
>>
>>We also added controls to enable sellers to select which buyers are 
>>included in the payload when it doesn’t affect the outwardly visible size 
>>of the encrypted data.
>>- 
>>
>>Additionally the Bidding and Auc

[blink-dev] Fwd: Intent to Extend Experiment: Protected Audience Bidding & Auction Services

['Russ Hamilton' via blink-dev]

(Now *To* blink-dev instead of just CC)
Contact emails

pauljen...@chromium.org, behamil...@google.com

Explainer

Chrome:
https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md

Services:
https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md

Note that this explainer has a helpful onboarding section

for setting up the services.

Specification

A work-in-progress pull request

on the Protected Audience spec 
describes some of the changes to the W3C spec. We are reaching out to the
IETF ART Area Directors for assistance beginning the standardization
process for some of the server-side aspects of this API.

Summary

We propose extending the Bidding and Auction Services origin trial
currently operating on 1% stable.

Recent changes:

   -

   Prompted by developer concerns about scalability, we have recently added
   support in M127 for limiting the size of the Bidding and Auction request
   payload
   -

   We also added controls to enable sellers to select which buyers are
   included in the payload when it doesn’t affect the outwardly visible size
   of the encrypted data.
   -

   Additionally the Bidding and Auction server has recently added support
   for features such as buyerReportingId and bid currency.

We have decided to extend the experiment to give developers time to
experiment with the new features. We would like to request extending the
end milestone from M127 to M130.

Blink component

Blink>InterestGroups


TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723

TAG review status

Completed for Protected Audience, resolved unsatisfied.

Interoperability and CompatibilityGecko & WebKit: No signal on parent
proposal, Protected Audience.  Asked in the Mozilla forum here
, and in the
Webkit forum here 
.Edge: Microsoft has proposed their Ad Selection API (
https://github.com/WICG/privacy-preserving-ads/
) as a similar
TEE on-server auction API. That API looks like it would have an identical
Web Platform API as the Bidding and Auction Services API. We have biweekly
meetings with Microsoft, and are open to collaborating on specifying the
API.

WPT Tests

We have started to implement some tests
, but
work is still ongoing.
Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4649601971257344

Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrnSdvf7RgK2wxsmC6rWc8eRoqDZOvgwVFuEx1r2nqmAJg%40mail.gmail.com

Intent to Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I


Intent to Extend Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/xaJHFJ_uAAAJ

Thanks,

–Benjamin “Russ” Hamilton

-- 
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/CAAG-DU1Euju6f97P1kjqTfggWUBZEgEdPA43KL25ZUzHqJ_9uQ%40mail.gmail.com.

[blink-dev] Intent to Extend Experiment: Protected Audience Bidding & Auction Services

['Russ Hamilton' via blink-dev]

Contact emails

pauljen...@chromium.org, behamil...@google.com

Explainer

Chrome:
https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md

Services:
https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md

Note that this explainer has a helpful onboarding section

for setting up the services.

Specification

A work-in-progress pull request

on the Protected Audience spec 
describes some of the changes to the W3C spec. We are reaching out to the
IETF ART Area Directors for assistance beginning the standardization
process for some of the server-side aspects of this API.

Summary

We propose extending the Bidding and Auction Services origin trial
currently operating on 1% stable.

Recent changes:

   -

   Prompted by developer concerns about scalability, we have recently added
   support in M127 for limiting the size of the Bidding and Auction request
   payload
   -

   We also added controls to enable sellers to select which buyers are
   included in the payload when it doesn’t affect the outwardly visible size
   of the encrypted data.
   -

   Additionally the Bidding and Auction server has recently added support
   for features such as buyerReportingId and bid currency.

We have decided to extend the experiment to give developers time to
experiment with the new features. We would like to request extending the
end milestone from M127 to M130.

Blink component

Blink>InterestGroups


TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723

TAG review status

Completed for Protected Audience, resolved unsatisfied.

Interoperability and CompatibilityGecko & WebKit: No signal on parent
proposal, Protected Audience.  Asked in the Mozilla forum here
, and in the
Webkit forum here 
.Edge: Microsoft has proposed their Ad Selection API (
https://github.com/WICG/privacy-preserving-ads/
) as a similar
TEE on-server auction API. That API looks like it would have an identical
Web Platform API as the Bidding and Auction Services API. We have biweekly
meetings with Microsoft, and are open to collaborating on specifying the
API.

WPT Tests

We have started to implement some tests
, but
work is still ongoing.
Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4649601971257344

Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrnSdvf7RgK2wxsmC6rWc8eRoqDZOvgwVFuEx1r2nqmAJg%40mail.gmail.com

Intent to Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I


Intent to Extend Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/xaJHFJ_uAAAJ

Thanks,

–Benjamin “Russ” Hamilton

-- 
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/CAAG-DU3Ky83otUFvoD%3DnwmAWz%2Be%2BrPLjiDVnjDhKmHTOYVab7g%40mail.gmail.com.

[blink-dev] Re: PSA: Protected Audience k-Anonymity Enforcement

['Russ Hamilton' via blink-dev]

FYI:
We are currently in the process of ramping k-anonymity enforcement back up
to 1% of eligible traffic on Stable channel. As before, eligible traffic is
pre-stable and stable channels, excluding Mode A and Mode B traffic.

Best,
--Benjamin "Russ" Hamilton

On Mon, Apr 8, 2024 at 1:20 PM Russ Hamilton  wrote:

> FYI:
> We are planning to ramp k-anonymity enforcement back up to 50% of eligible
> traffic on Beta channel later today.
>
> Best,
> --Benjamin "Russ" Hamilton
>
> On Wed, Apr 3, 2024 at 1:25 PM Russ Hamilton 
> wrote:
>
>> Recently, we became aware that Chrome was mistakenly applying k-anonymity
>> enforcement on reporting to a portion of Mode A and Mode B testing
>> traffic
>> .
>> This did not affect ad selection and therefore should have had little or no
>> impact on auction dynamic or pressure.  To mitigate this issue, we briefly
>> turned off k-anonymity enforcement on all Chrome traffic. We have landed a
>> high confidence fix for this issue and have started ramping back up
>> k-anonymity enforcement on eligible traffic1 that has the fix.
>>
>>
>> The application of k-anonymity enforcement in Mode A and Mode B traffic
>> did not affect ad selection, i.e. no winning ads were removed because the
>> creative URLs were below the k-anonymity threshold and the creative URLs
>> would continue to be available in reportWin() and reportResult().  The
>> k-anonymity enforcement on reporting means that some Mode A and Mode B
>> traffic may have been inadvertently missing interestGroupName,
>> buyerReportingId, or buyerAndSellerReportingId in reportWin(), and
>> buyerAndSellerReportingId in reportResult(), in cases where the value, when
>> combined with the interest group owner, bidding script URL, and ad creative
>> URL was not jointly k-anonymous. Adtech scripts should properly handle the
>> lack of these values in reportWin() and reportResult() as they’ve always
>> been intended and specified as optional and missing when they don’t meet
>> the k-anonymity threshold. However, we understand that the current
>> implementations may not have reached this stage of development.  Here’s a
>> timeline of how k-anonymity enforcement was ramped:
>>
>>
>> Jan 24 - Feb 12
>>
>> <1%
>>
>> Feb 12 - Mar 7
>>
>> <4%
>>
>> Mar 7 - Mar 13
>>
>> <13%
>>
>> Mar 13 - Mar 22
>>
>> 1%
>>
>> Mar 22 - Apr 2
>>
>> k-anon enforcement disabled, ~0%
>>
>> Apr 2
>>
>> fix deployed, ramping back up, <1%
>>
>>
>>
>> We have started ramping  k-anonymity enforcement up on pre-stable and
>> plan to continue ramping on eligible traffic1. We apologize for the
>> inconvenience caused by this disruption.
>>
>>
>> 1 Eligible traffic is pre-stable and stable channels, excluding Mode A
>> and Mode B traffic.
>>
>>
>> Best,
>> --Benjamin "Russ" Hamilton
>>
>> On Thu, Jan 25, 2024 at 6:59 PM Russ Hamilton 
>> wrote:
>>
>>> We plan to start enabling the k-anonymity
>>> 
>>> enforcement feature for the Protected Audience API
>>>  (Intent to Ship
>>> ).
>>> K-anonymity enforcement has long been a part of the Protected Audience
>>> API’s plan for improving user privacy by limiting ads that can win
>>> Protected Audience auctions to those ads that are k-anonymous. The
>>> k-anonymity enforcement feature limits the ability of advertisers to target
>>> specific users by requiring each ad be shown to a minimum number of users.
>>> This enforcement will initially apply to up to 20% of unlabeled traffic
>>> only, meaning the groups that are part of Chrome-facilitated testing
>>> 
>>> for third-party cookie deprecation will not be enforced for k-anonymity
>>> during the testing period. After the testing period, enforcement will apply
>>> to all traffic (see timeline details at
>>> https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity
>>> ).
>>>
>>

-- 
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/CAAG-DU01vGUVjfnHQB7i1JFcfu9KawBgG80qO0UE31u0fbdrhQ%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: Protected Audience Bidding & Auction Services

['Russ Hamilton' via blink-dev]

To follow up on my previous email, I’d like to add some more details to
clarify the state and progress of the Origin Trial:

In the past 6  months the server has added support for event-level
reporting, multiple coordinators, currencies, multi-seller auctions, and
hybrid on-device/on-server Protected Audience auctions. We've made 20+
changes to Chrome in the past 6 months to support new features for Bidding
and Auction Services and address issues discovered during testing.

The discussions needed to begin the specification work represent
significant progress relative to where we were before, as now we have a
plan and work has started on implementation.

The TAG review for Protected Audience finished in February.

Although we haven't heard from Webkit
<https://github.com/WebKit/standards-positions/issues/158> or Gecko
<https://github.com/mozilla/standards-positions/issues/770>, Microsoft has
proposed their Ad Selection API (
https://github.com/WICG/privacy-preserving-ads/tree/main) as a similar TEE
on-server auction API. That API looks like it would have an identical Web
Platform API as the Bidding and Auction Services API. We have biweekly
meetings with Microsoft, and are open to collaborating on specifying the
API.

Although we don't have WPT, we have been working on integration testing
with the existing implementation. Also, there is a substantial barrier to
writing effective WPTs in our case due to the use of Hybrid Public Key
Encryption (HPKE) in sending requests and responses. That said, we are
thinking about ways to extend WPTs to make it possible to improve test
coverage.

On Fri, Apr 12, 2024 at 1:24 PM Mike Taylor  wrote:

> Russ and I had a conversation offline about the progress here - mind
> summarizing, Russ?
> On 4/9/24 4:12 PM, Russ Hamilton wrote:
>
> Specification
> We are just beginning writing the spec. We're drafting a WICG spec for the
> browser components and an IETF spec for the server interface.
>
> TAG review
>
> For Protected Audience:
> https://github.com/w3ctag/design-reviews/issues/723.
>
>
> TAG review status
>
> Completed for Protected Audience, resolved unsatisfied.
>
>
> Interoperability and Compatibility
>
>
> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked
> in the Mozilla forum here
> <https://github.com/mozilla/standards-positions/issues/770>, and in the
> Webkit forum here
> <https://github.com/WebKit/standards-positions/issues/158>.
>
>
> *WPT Tests*
>
>
> We have not started on WPT tests for this feature.
>
>
> On Mon, Apr 8, 2024 at 11:40 AM Mike Taylor 
> wrote:
>
>> Hi Russ,
>>
>> Could you summarize progress on the following, per the extension process:
>>
>> Draft spec (early draft is ok, but must be spec-like and associated with
>> the appropriate standardization venue, or WICG)
>> TAG review
>> bit.ly/blink-signals requests
>> Outreach for feedback from the spec community
>> WPT tests
>>
>> I recognize some of this is touched on in your email - but having it
>> explicitly in one spot would be helpful, thanks.
>> On 4/4/24 12:19 PM, 'Russ Hamilton' via blink-dev wrote:
>>
>> Contact emails
>>
>> pauljen...@chromium.org, behamil...@google.com
>>
>> Explainer
>>
>> Chrome:
>> https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md
>>
>> Services:
>> https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md
>>
>> Note that this explainer has a helpful onboarding section
>> <https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md#onboarding-and-alpha-testing-guide>
>> for setting up the services.
>>
>> Specification
>>
>> Influenced by Origin Trial feedback, so work has just started.  Protected
>> Audience auctions running on Bidding & Auction Services provide
>> functionality very similar to existing on-device auctions so much of the
>> existing spec <https://wicg.github.io/turtledove/> applies.
>>
>> Summary
>>
>> We propose extending the Bidding and Auction Services origin trial
>> currently operating on 1% stable. We have decided to extend the experiment
>> given developers need more time to onboard and to keep experimenting with
>> new features. We would like to request extending the end milestone from
>> M124 to M127.
>>
>> Blink component
>>
>> Blink>InterestGroups
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInterestGroups>
>>
>> TAG review
>>
>> For Protected Audience:
>> https://github.com

Re: [blink-dev] Intent to Extend Experiment: Protected Audience Bidding & Auction Services

['Russ Hamilton' via blink-dev]

Specification
We are just beginning writing the spec. We're drafting a WICG spec for the
browser components and an IETF spec for the server interface.

TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723.


TAG review status

Completed for Protected Audience, resolved unsatisfied.


Interoperability and Compatibility


Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked in
the Mozilla forum here
<https://github.com/mozilla/standards-positions/issues/770>, and in the
Webkit forum here <https://github.com/WebKit/standards-positions/issues/158>
.


*WPT Tests*


We have not started on WPT tests for this feature.


On Mon, Apr 8, 2024 at 11:40 AM Mike Taylor  wrote:

> Hi Russ,
>
> Could you summarize progress on the following, per the extension process:
>
> Draft spec (early draft is ok, but must be spec-like and associated with
> the appropriate standardization venue, or WICG)
> TAG review
> bit.ly/blink-signals requests
> Outreach for feedback from the spec community
> WPT tests
>
> I recognize some of this is touched on in your email - but having it
> explicitly in one spot would be helpful, thanks.
> On 4/4/24 12:19 PM, 'Russ Hamilton' via blink-dev wrote:
>
> Contact emails
>
> pauljen...@chromium.org, behamil...@google.com
>
> Explainer
>
> Chrome:
> https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md
>
> Services:
> https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md
>
> Note that this explainer has a helpful onboarding section
> <https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md#onboarding-and-alpha-testing-guide>
> for setting up the services.
>
> Specification
>
> Influenced by Origin Trial feedback, so work has just started.  Protected
> Audience auctions running on Bidding & Auction Services provide
> functionality very similar to existing on-device auctions so much of the
> existing spec <https://wicg.github.io/turtledove/> applies.
>
> Summary
>
> We propose extending the Bidding and Auction Services origin trial
> currently operating on 1% stable. We have decided to extend the experiment
> given developers need more time to onboard and to keep experimenting with
> new features. We would like to request extending the end milestone from
> M124 to M127.
>
> Blink component
>
> Blink>InterestGroups
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInterestGroups>
>
> TAG review
>
> For Protected Audience:
> https://github.com/w3ctag/design-reviews/issues/723
>
> TAG review status
>
> Completed for Protected Audience, resolved unsatisfied.
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/4649601971257344
>
> Links to previous Intent discussions
>
> Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrnSdvf7RgK2wxsmC6rWc8eRoqDZOvgwVFuEx1r2nqmAJg%40mail.gmail.com
>
> Intent to Experiment:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/BwMKwPP6GQAJ>
> --
> 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/CAAG-DU2FmKivx3FF%3Dn0BZge_0n10ihizanpgrZVkPaeWtzaCbA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAG-DU2FmKivx3FF%3Dn0BZge_0n10ihizanpgrZVkPaeWtzaCbA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAG-DU2nS16Me8DK_p8oaA900244DxEVNrDmbcZXEyRExMxZdw%40mail.gmail.com.

[blink-dev] Re: PSA: Protected Audience k-Anonymity Enforcement

['Russ Hamilton' via blink-dev]

FYI:
We are planning to ramp k-anonymity enforcement back up to 50% of eligible
traffic on Beta channel later today.

Best,
--Benjamin "Russ" Hamilton

On Wed, Apr 3, 2024 at 1:25 PM Russ Hamilton  wrote:

> Recently, we became aware that Chrome was mistakenly applying k-anonymity
> enforcement on reporting to a portion of Mode A and Mode B testing traffic
> .
> This did not affect ad selection and therefore should have had little or no
> impact on auction dynamic or pressure.  To mitigate this issue, we briefly
> turned off k-anonymity enforcement on all Chrome traffic. We have landed a
> high confidence fix for this issue and have started ramping back up
> k-anonymity enforcement on eligible traffic1 that has the fix.
>
>
> The application of k-anonymity enforcement in Mode A and Mode B traffic
> did not affect ad selection, i.e. no winning ads were removed because the
> creative URLs were below the k-anonymity threshold and the creative URLs
> would continue to be available in reportWin() and reportResult().  The
> k-anonymity enforcement on reporting means that some Mode A and Mode B
> traffic may have been inadvertently missing interestGroupName,
> buyerReportingId, or buyerAndSellerReportingId in reportWin(), and
> buyerAndSellerReportingId in reportResult(), in cases where the value, when
> combined with the interest group owner, bidding script URL, and ad creative
> URL was not jointly k-anonymous. Adtech scripts should properly handle the
> lack of these values in reportWin() and reportResult() as they’ve always
> been intended and specified as optional and missing when they don’t meet
> the k-anonymity threshold. However, we understand that the current
> implementations may not have reached this stage of development.  Here’s a
> timeline of how k-anonymity enforcement was ramped:
>
>
> Jan 24 - Feb 12
>
> <1%
>
> Feb 12 - Mar 7
>
> <4%
>
> Mar 7 - Mar 13
>
> <13%
>
> Mar 13 - Mar 22
>
> 1%
>
> Mar 22 - Apr 2
>
> k-anon enforcement disabled, ~0%
>
> Apr 2
>
> fix deployed, ramping back up, <1%
>
>
>
> We have started ramping  k-anonymity enforcement up on pre-stable and plan
> to continue ramping on eligible traffic1. We apologize for the
> inconvenience caused by this disruption.
>
>
> 1 Eligible traffic is pre-stable and stable channels, excluding Mode A
> and Mode B traffic.
>
>
> Best,
> --Benjamin "Russ" Hamilton
>
> On Thu, Jan 25, 2024 at 6:59 PM Russ Hamilton 
> wrote:
>
>> We plan to start enabling the k-anonymity
>> 
>> enforcement feature for the Protected Audience API
>>  (Intent to Ship
>> ).
>> K-anonymity enforcement has long been a part of the Protected Audience
>> API’s plan for improving user privacy by limiting ads that can win
>> Protected Audience auctions to those ads that are k-anonymous. The
>> k-anonymity enforcement feature limits the ability of advertisers to target
>> specific users by requiring each ad be shown to a minimum number of users.
>> This enforcement will initially apply to up to 20% of unlabeled traffic
>> only, meaning the groups that are part of Chrome-facilitated testing
>> 
>> for third-party cookie deprecation will not be enforced for k-anonymity
>> during the testing period. After the testing period, enforcement will apply
>> to all traffic (see timeline details at
>> https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity
>> ).
>>
>

-- 
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/CAAG-DU2mz-0QXAqxUdX8v%3DcxPS2RXeV0hphBmSozL2%3D0nvZLBA%40mail.gmail.com.

[blink-dev] Intent to Extend Experiment: Protected Audience Bidding & Auction Services

['Russ Hamilton' via blink-dev]

Contact emails

pauljen...@chromium.org, behamil...@google.com

Explainer

Chrome:
https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md

Services:
https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md

Note that this explainer has a helpful onboarding section

for setting up the services.

Specification

Influenced by Origin Trial feedback, so work has just started.  Protected
Audience auctions running on Bidding & Auction Services provide
functionality very similar to existing on-device auctions so much of the
existing spec  applies.

Summary

We propose extending the Bidding and Auction Services origin trial
currently operating on 1% stable. We have decided to extend the experiment
given developers need more time to onboard and to keep experimenting with
new features. We would like to request extending the end milestone from
M124 to M127.

Blink component

Blink>InterestGroups


TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723

TAG review status

Completed for Protected Audience, resolved unsatisfied.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4649601971257344

Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrnSdvf7RgK2wxsmC6rWc8eRoqDZOvgwVFuEx1r2nqmAJg%40mail.gmail.com

Intent to Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I


-- 
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/CAAG-DU2FmKivx3FF%3Dn0BZge_0n10ihizanpgrZVkPaeWtzaCbA%40mail.gmail.com.

[blink-dev] Re: PSA: Protected Audience k-Anonymity Enforcement

['Russ Hamilton' via blink-dev]

Recently, we became aware that Chrome was mistakenly applying k-anonymity
enforcement on reporting to a portion of Mode A and Mode B testing traffic
.
This did not affect ad selection and therefore should have had little or no
impact on auction dynamic or pressure.  To mitigate this issue, we briefly
turned off k-anonymity enforcement on all Chrome traffic. We have landed a
high confidence fix for this issue and have started ramping back up
k-anonymity enforcement on eligible traffic1 that has the fix.


The application of k-anonymity enforcement in Mode A and Mode B traffic did
not affect ad selection, i.e. no winning ads were removed because the
creative URLs were below the k-anonymity threshold and the creative URLs
would continue to be available in reportWin() and reportResult().  The
k-anonymity enforcement on reporting means that some Mode A and Mode B
traffic may have been inadvertently missing interestGroupName,
buyerReportingId, or buyerAndSellerReportingId in reportWin(), and
buyerAndSellerReportingId in reportResult(), in cases where the value, when
combined with the interest group owner, bidding script URL, and ad creative
URL was not jointly k-anonymous. Adtech scripts should properly handle the
lack of these values in reportWin() and reportResult() as they’ve always
been intended and specified as optional and missing when they don’t meet
the k-anonymity threshold. However, we understand that the current
implementations may not have reached this stage of development.  Here’s a
timeline of how k-anonymity enforcement was ramped:


Jan 24 - Feb 12

<1%

Feb 12 - Mar 7

<4%

Mar 7 - Mar 13

<13%

Mar 13 - Mar 22

1%

Mar 22 - Apr 2

k-anon enforcement disabled, ~0%

Apr 2

fix deployed, ramping back up, <1%



We have started ramping  k-anonymity enforcement up on pre-stable and plan
to continue ramping on eligible traffic1. We apologize for the
inconvenience caused by this disruption.


1 Eligible traffic is pre-stable and stable channels, excluding Mode A and
Mode B traffic.


Best,
--Benjamin "Russ" Hamilton

On Thu, Jan 25, 2024 at 6:59 PM Russ Hamilton  wrote:

> We plan to start enabling the k-anonymity
> 
> enforcement feature for the Protected Audience API
>  (Intent to Ship
> ).
> K-anonymity enforcement has long been a part of the Protected Audience
> API’s plan for improving user privacy by limiting ads that can win
> Protected Audience auctions to those ads that are k-anonymous. The
> k-anonymity enforcement feature limits the ability of advertisers to target
> specific users by requiring each ad be shown to a minimum number of users.
> This enforcement will initially apply to up to 20% of unlabeled traffic
> only, meaning the groups that are part of Chrome-facilitated testing
> 
> for third-party cookie deprecation will not be enforced for k-anonymity
> during the testing period. After the testing period, enforcement will apply
> to all traffic (see timeline details at
> https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity
> ).
>

-- 
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/CAAG-DU1Uy2dYc3jBd833BgSgjP-d80CcNu4ipGmyX%2Bbx8NZ-tw%40mail.gmail.com.

[blink-dev] Re: Intent to Experiment: Cookie Deprecation Labeling

['Russ Hamilton' via blink-dev]

FYI, based on feedback from testers 
(https://github.com/WICG/turtledove/issues/946) we are going to send the 
Cookie-Deprecation label headers during the trusted bidding and trusted 
scoring signals fetches for Protected Audience auctions beginning in M122. 
Note that if the user is not part of the Facilitated testing groups or has 
disabled third party cookies then this feature will not be added to the 
header.

On Wednesday, October 25, 2023 at 5:05:53 PM UTC-4 John Delaney wrote:

> *Contact emails*
> john...@chromium.org, wande...@chromium.org, lin...@chromium.org
>
> *Explainer*
>
> https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md
> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing
>
> *Specification*
> None
>
> *Summary*
> To prepare for the third-party cookie deprecation, it is important to 
> understand the full impact of Chrome’s planned transition from third-party 
> cookies to the Privacy Sandbox Ads APIs.
>
> This experiment exposes a temporary set of APIs which provide access to 
> browser-determined treatment and control groups to support opt-in server 
> side testing of the third-party cookie deprecation.
>
> *Blink component*
> A-N/A
>
> *TAG review*
> Not requesting TAG review as this API is a temporary Chrome-specific 
> experiment.
>
> *Risks*
>
> *Interoperability and Compatibility*
> This feature is only shipping in Chrome to support the third-party cookie 
> deprecation, and will not be interoperable with other vendors.
>
> *WebView application risks*
> Not available on WebView
>
>
> *Goals for experimentation*
> The goal of this experiment is to allow adtechs to evaluate the impact of 
> third party cookie phase out through opt-in server side testing. We expect 
> partners to run experiments downstream from the browser provided treatment 
> and control groups.
>
> *Experiment Behavior and Risks*
> This experiment will expose temporary APIs which allow access to browser 
> provided experiment labels. 
>
> To ensure all parties can easily get access to labels, we intend to expose 
> the APIs without a traditional origin trial. 
>
> To limit burn-in risk, the new APIs will only be available to at most ~10% 
> of users. These APIs should have very little utility to developers outside 
> of this specific temporary experiment, it seems unlikely that user-visible 
> breakage would occur as a result of the eventual removal.
>
> *Timeline*
> We intend to remove the labeling APIs when Mode B of the experiment ends, 
> which we expect to be by the end of Q2 2024 at the earliest.
>
> This experiment temporarily adds a new surface to the web that could be 
> used for active fingerprinting. This is mitigated by the fact that: 
>
>- only a subset are assigned labels, reducing the usefulness of the 
>label for fingerprinting
>- labels are not sent for users who block third-party cookies, to 
>ensure consistency with those users’ current settings
>- the labeling APIs will be removed by the time third-party cookies 
>are phased out
>- label assignment is independent of users' browsing activity
>
>
> *Ongoing technical constraints*
> None
>
> *Debuggability*
> None
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?*
> No, not supported on WebView.
>
> *Is this feature fully tested by web-platform-tests?*
> No
>
> *Flag name on chrome://flags*
> #tpc-phase-out-facilitated-testing
>
> *Requires code in //chrome?*
> False
>
> *Estimated milestones*
>   Experiment desktop first 119
>   Experiment Android first 119
>
> *Intent to Prototype*
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/8mlWTOcEzcA/m/NZJSW0weAQAJ
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5189079788683264
>

-- 
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/b14382a4-c6c1-43c6-b172-0385a27fd14an%40chromium.org.

Re: [blink-dev] PSA: Protected Audience k-Anonymity Enforcement

['Russ Hamilton' via blink-dev]

Most users should not notice a difference. The main difference is going to
be which ads are allowed to win Protected Audience auctions. Some
non-k-anonymous ads that would have previously won the Protected Audience
auction will not win and the auction will return a different, k-anonymous
ad as the winner. In the case where there are no k-anonymous bids in an
auction then that auction will return without a winner. Protected Audience
auctions already return with no winner in some cases, such as when there
are no bids, so this does not introduce a new behavior.

On Fri, Jan 26, 2024 at 4:24 AM Mike Taylor  wrote:

> Hi Russ,
>
> Can you say more about the compatibility implications for such a change?
> AFAIU, things shouldn't "break" for users or throw errors behind the
> scenes, correct?
>
> thanks,
> Mike
> On 1/26/24 12:59 AM, 'Russ Hamilton' via blink-dev wrote:
>
> We plan to start enabling the k-anonymity
> <https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonymity_server.md#what-is-k-anonymity>
> enforcement feature for the Protected Audience API
> <https://github.com/WICG/turtledove/blob/main/FLEDGE.md> (Intent to Ship
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/igFixT5n7Bs/m/ZNrDcQ2dDQAJ>).
> K-anonymity enforcement has long been a part of the Protected Audience
> API’s plan for improving user privacy by limiting ads that can win
> Protected Audience auctions to those ads that are k-anonymous. The
> k-anonymity enforcement feature limits the ability of advertisers to target
> specific users by requiring each ad be shown to a minimum number of users.
> This enforcement will initially apply to up to 20% of unlabeled traffic
> only, meaning the groups that are part of Chrome-facilitated testing
> <https://developers.google.com/privacy-sandbox/setup/web/chrome-facilitated-testing>
> for third-party cookie deprecation will not be enforced for k-anonymity
> during the testing period. After the testing period, enforcement will apply
> to all traffic (see timeline details at
> https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity
> ).
> --
> 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/CAAG-DU2%3DfH8Q5gDDVms%2BajMA4WzS%3DvQBRPQj8jaiVzJkCdCz7g%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAG-DU2%3DfH8Q5gDDVms%2BajMA4WzS%3DvQBRPQj8jaiVzJkCdCz7g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAG-DU3-YDn5Wbqs52R%3DacMG7%2B%3D_eB3%3DmCcgRFhRN44SYPk68A%40mail.gmail.com.

[blink-dev] PSA: Protected Audience k-Anonymity Enforcement

['Russ Hamilton' via blink-dev]

We plan to start enabling the k-anonymity

enforcement feature for the Protected Audience API
 (Intent to Ship
).
K-anonymity enforcement has long been a part of the Protected Audience
API’s plan for improving user privacy by limiting ads that can win
Protected Audience auctions to those ads that are k-anonymous. The
k-anonymity enforcement feature limits the ability of advertisers to target
specific users by requiring each ad be shown to a minimum number of users.
This enforcement will initially apply to up to 20% of unlabeled traffic
only, meaning the groups that are part of Chrome-facilitated testing

for third-party cookie deprecation will not be enforced for k-anonymity
during the testing period. After the testing period, enforcement will apply
to all traffic (see timeline details at
https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity
).

-- 
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/CAAG-DU2%3DfH8Q5gDDVms%2BajMA4WzS%3DvQBRPQj8jaiVzJkCdCz7g%40mail.gmail.com.