Intent to Ship: Protected Audience: Real Time Monitoring API
Paul Jensen
Contact emails
Explainer
https://github.com/WICG/turtledove/blob/main/PA_real_time_monitoring.md
Specification
https://github.com/WICG/turtledove/pull/1212
Summary
The goal of real-time monitoring is to get Protected Audience API auction monitoring data to the buyer and seller as quickly as possible (e.g. < 5 mins). The primary use-case we are trying to capture with this reporting surface, the Protected Audience Real Time Monitoring (RTM) API, is rapid error detection i.e. detecting quickly whether there are major problems with unexpected behavior in generateBid(), scoreAd(), or loading of bidding or scoring scripts or trusted signals. To offer reduced latency over other reporting mechanisms like the Private Aggregation API, the RTM API uses the local differentially private RAPPOR algorithm with an epsilon of one. The reduced latency is traded off for a limited number of histogram buckets and significant noise.
Blink component
TAG review
For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723
TAG review status
Completed for Protected Audience, resolved unsatisfied.
Risks
Privacy
At the epsilon we are proposing (𝜖 = 1), the information leaked is limited to approximately 0.18 bits per auction. This makes it very difficult for a bad actor to gain any meaningful user identifying information from an auction using this API.
While the tight privacy parameters provide strong protections, there are two privacy considerations of note:
It reveals a small amount of information from scoreAd and generateBid to sellers and bidders, respectively. These contents are protected by the locally differentially private RAPPOR algorithm. The scope of this risk can be measured with the privacy loss epsilon parameter. This risk could be magnified by a bad actor running many auctions solely for the purpose of collecting more information from a publisher page. We mitigate this risk by bounding the number of contributions that this API will send to an adtech from a page in a given period of time for each browser.
It reveals to the ad tech the fact that it had an interest group present on the device. This is mitigated by the fact that the reports are sent to a fixed path and include only heavily noised signals. We also considered sending reports to all eligible auction participants for a given auction (i.e. all those present in interestGroupBuyers, even if they do not have interest groups), but this will result in an overwhelming number of reports sent.
We plan to address both these considerations in future work.
Interoperability and Compatibility
This feature represents optional new behavior that shouldn’t break existing usage.
Gecko & WebKit: No signal on parent proposal, Protected Audience. Asked in the Mozilla forum here, and in the Webkit forum here.
Edge: Edge has announced plans to support the Ad Selection API which shares much of its API surface with Protected Audience.
Web developers: Interest from 5 companies on GitHub issue and significant interest on WICG call discussion.
Debuggability
RTM API network requests will show up in the Chrome Developer Tools network panel. Calls to the RTM API from Protected Audience bidding and scoring scripts should also be debuggable with Chrome Developer Tools.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
It will be supported on all platforms that support Protected Audience, so all but WebView.
Is this feature fully tested by web-platform-tests?
We’ve landed some but plan to land more web-platform-tests shortly.
Flag name on chrome://flags
None
Finch feature name
RealTimeReporting
Requires code in //chrome?
False
Estimated milestones
Shipping on desktop and Android in M128.
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5200293940428800
This intent message was generated by Chrome Platform Status.
Paul Jensen
Explainer: https://github.com/WICG/turtledove/pull/1238
Chris Harrelson
--
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/d93f9942-00b9-42d0-bb11-5d0f530e8bebn%40chromium.org.
Paul Jensen
Yoav Weiss (@Shopify)
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Mike Taylor
LGTM2
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/b3aadf7d-ef56-47f8-b2ff-607e26846323n%40chromium.org.
Chris Harrelson
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/d93f9942-00b9-42d0-bb11-5d0f530e8bebn%40chromium.org.
--
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/b3aadf7d-ef56-47f8-b2ff-607e26846323n%40chromium.org.
--
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/77aaaee5-ee7e-47fb-9b5e-47fc8b3f1646%40chromium.org.