Currently, the availability of Private Aggregation’s debug mode is tied to a caller's eligibility to set a third-party cookie (see https://chromestatus.com/feature/5148973702840320). However, an edge case was missed in this logic: if the caller can only set a third-party cookie due to a top-level site exception (i.e. the user has generally disabled third-party cookies), this could allow access to information set from other sites that are not on the exception list. To avoid this issue, we plan to start ignoring these top-level site exceptions when determining the availability of Private Aggregation’s debug mode. (It is not possible in Chrome to generally enable third-party cookies but disable them on one site, so the inverse case doesn’t need to be considered.) This does not require a spec change. Note that this new behavior can reveal to the site that the user has generally disabled third-party cookies.
enableDebugMode() will be silently ignored for callers in this particular scenario (like other cases where debug mode is not available). Note that this will not affect the page directly. So, this only affects the report(s) later sent to a .well-known address.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
This slightly reduces the scope of the debug mode. However, other debugging pages, e.g. the internals page, will accurately reflect the debug mode state.
All but WebView
Shipping on desktop | 132 |
Shipping on Android | 132 |
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
None