Intent to Ship: Private Aggregation debug mode for auctionReportBuyers reporting

[Alex Turner]

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

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 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://flags

None

Finch feature name

PrivateAggregationAuctionReportBuyerDebugModeConfig

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1513013

Launch bug

https://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.

[Yoav Weiss (@Shopify)]

LGTM1

--
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+...@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.

[Mike Taylor]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BJt8bhfgO5iLVa7j3byo%2Bov8%3D_kh-Jt6hLfBEbWyJHPA%40mail.gmail.com.

[Alex Russell]

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

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[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. Also, note that trying to enable debug mode already has no effect for users who have explicitly disabled third-party cookies.)

Best,
Alex

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFkYb%3DWswXSKM%2B9ESFdgTBUdbjoDq21Q5sWJm%2BPWqqE_nw%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+...@chromium.org.

[Alex Russell]

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

[Yoav Weiss (@Shopify)]

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.

[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) 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

[Yoav Weiss (@Shopify)]

On Thu, Mar 7, 2024 at 5:03 PM Alex Turner <ale...@chromium.org> wrote:

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) 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).

That makes perfect sense! I think the benefits of tying this to an OT (better assurances that removal will be smooth) are outweighed by the friction it'd introduce for adoption, which is especially stark when considering the already shipped and much more visible enableDebugMode.

My LGTM stands.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFkLqQ6DwUqtg1z_1jFStOTjLT_mma6%3Dx_c47C_ZKOTnEA%40mail.gmail.com.

[Philip Jägenstedt]

LGTM3

I agree with Alex that we have a bad track record of "temporary" APIs on the web, but I'm comfortable with this given the particulars. A feature which is only a dictionary member is detectable (through a getter) but you have to do extra work and I don't recall ever seeing a problem from removing a no-op dictionary member. Given this, going through OT is extra work to reduce a risk that is already very low. In the very worst case we'd be left with a no-op dictionary member that generates some bindings but does nothing, so it's a small risk of a small problem.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLJkpiDk6tMmfj1d3-oiA896GLv9O5tz_XvnQuh2XPEUQ%40mail.gmail.com.