Contact emails
*[email protected] <[email protected]>, [email protected] <[email protected]>*Specification *Explainer: https://github.com/mikewest/deprecating-document-domain <https://github.com/mikewest/deprecating-document-domain>HTML Spec draft: https://github.com/whatwg/html/compare/main...otherdaniel:dd <https://github.com/whatwg/html/compare/main...otherdaniel:dd>*API spec *Yes*Summary *Change the default behavior of the Origin-Agent-Cluster: header / document.domain settability.Presently, pages within Chromium have site-keyed agent clusters by default, unless the Origin-Agent-Cluster: header is explicitly set to true. This accommodates pages or frames which want to access each other's state, despite being on different origins (but within a site). This is fine for any pages that wish to do so, but because a page *might* set document.domain later on, Chromium currently must use site-keyed agent clusters for *all* pages by default even though the overwhelming majority of pages do not ever make use of this (mis-)feature. In turn, this requires Chromium to use sites as the basis for renderer process isolation (via Site Isolation), which exposes origins to same-site but cross-origin attacks involving compromised renderer processes or the "Spectre" family of side-channel attacks.This proposal changes the default behaviour of Origin-Agent-Cluster. From a developer's point of view, the new default matches "Origin-Agent-Cluster: ?1". The initial implementation will use origin-keyed agent clusters for all (non-opted out) origins, without changing how many processes Chromium creates. Over time, we can then adapt Chromium's isolation strategy towards origin-keyed processes without further affecting web-visible behaviour.The developer-visible aspect of this is that for pages with origin-keyed agent clusters, document.domain is no longer settable. Thus, we have marked this intent as a deprecation.Note that this proposal is about the default. Both modes - site-keyed or origin-keyed agent clusters - remain available to any site, but origin-keyed agent clusters change from opt-in to opt-out. The current behaviour remains available by setting "Origin-Agent-Cluster: ?0".*Blink component *Blink>SecurityFeature*TAG review *https://github.com/w3ctag/design-reviews/issues/564 <https://github.com/w3ctag/design-reviews/issues/564>(The thread is a bit unwieldy, but there do not seem to be open issues.)*Risks: Interoperability and Compatibility *No interoperability risks.* Compatibility risk exists, but is fairly small as document.domain is an already deprecated feature. We’ve detailed UKM metrics in place and are planning to reach out to top users as soon as we’ve LGTMs for the plan. Current usage of the document.domain: 0.05% <https://chromestatus.com/metrics/feature/timeline/popularity/2544> of page views rely upon document.domain to enable some cross-origin access that wasn't otherwise possible. 0.24% <https://chromestatus.com/metrics/feature/timeline/popularity/2543> of page views block same-origin access because only one side sets document.domain. Both counters can be found on https://deprecate.it/#document-domain, too. We’ve reached out in advance to 4 of the top current users - TL;DR Most of their use cases could be achieved already by different APIs e.g. Audio/video autoplay in iframes by adding the ‘autoplay’ attribute, support chat deployed across subdomains. Gecko: Standards position request <https://github.com/mozilla/standards-positions/issues/601>. (Provisionally "worth prototyping", but is open for additional comments/opinions. Mozilla representatives also participated in the TAG discussion. No concrete implementation plans were given. WebKit: https://lists.webkit.org/pipermail/webkit-dev/2021-December/032067.html (No signals.) Web developers: No signals. Activation - Deprecation plan M98 - Add the devtools issue and warning incl. a web.dev blog post to guide adoption *M98-M100 - Monitor use counters and reach out to current usersM101 - Deprecate the feature by default. No reverse-origin trial is planned as the ‘Origin-Agent-Cluster’ http header can be used to gain access to the feature. SecurityThis change should be security-positive, since setting the document.domain will not have any impact on the origin of the document any more.* Debuggability *A deprecation warning will be added to DevTools console and to the issues panel in M98, which will support current users to adopt. This warning will file a deprecation report as well using the Reporting API, if so configured.*Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? *Yes*Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ? *Are in place to test the current functionality <https://wpt.live/html/browsers/origin/origin-keyed-agent-clusters/>, and will be adjusted within the M101 timeframe to ensure the feature is working as intended.*Tracking bug *https://crbug.com/1139851 <https://crbug.com/1139851>*Launch bug *https://crbug.com/1246823 <https://crbug.com/1246823>*Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5428079583297536 (document.domain setter deprecation) https://chromestatus.com/features/5683766104162304 (Origin-keyed agent clusters) -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOmpEUx5xST3QHRHdU9yPbA4ucMYQB4dMQcHys9KNRsrg%40mail.gmail.com.
