Are there any future plans on eventually not honoring the Origin-Agent-Cluster: ?0 to allow setting document.domain ? Or will this header always be honored ? I read on another site that this Origin-Agent-Cluster: ?0 will only be honored in secure context (example: https://) Is this true ? Will it also work in http:// ?
On Tuesday, December 14, 2021 at 6:09:07 AM UTC-8 voge...@chromium.org wrote: > Contact emails > > > *va...@chromium.org, voge...@chromium.org*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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c4e31ee4-03bc-4ede-8d4b-dbc6f43f15c2n%40chromium.org.
