We also extended our feature detection API to facilitate detecting this feature: Explainer: https://github.com/WICG/turtledove/pull/1238 Spec: https://github.com/WICG/turtledove/pull/1245 On Wednesday, July 31, 2024 at 12:51:08 PM UTC-4 Paul Jensen wrote:
> Contact emails > > pauljen...@chromium.org > > > 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 > > Blink>InterestGroups > <https://issues.chromium.org/issues?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. > > > RisksPrivacy > > 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 > <https://github.com/WICG/turtledove/blob/main/PA_real_time_monitoring.md#limitations-and-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 > <https://github.com/mozilla/standards-positions/issues/770>, and in the > Webkit forum here > <https://github.com/WebKit/standards-positions/issues/158>. > > > Edge: Edge has announced plans to support the Ad Selection API > <https://github.com/WICG/privacy-preserving-ads/blob/main/README.md> > which shares much of its API surface with Protected Audience. > > > Web developers: Interest from 5 companies on GitHub issue > <https://github.com/WICG/turtledove/issues/430> and significant interest > on WICG call discussion > <https://github.com/WICG/turtledove/blob/main/meetings/2024-02-28-FLEDGE-call-minutes.md?plain=1#L120> > . > > > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > We’ve landed some > <https://github.com/web-platform-tests/wpt/blob/f118165cd650448765d2e0efd3d7ee71f1e15e4f/fledge/tentative/auction-config.https.window.js#L510> > > 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 > <https://chromestatus.com/>. > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@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.
