Hi Team, Earliar chromium browser was displaying an error message as *document.domain* is going to deperecated in *M106*. Now I can not see this message and in some blogs postpone to *M109*. Could you confirm on this - when does this actually would enabled and in which version. It would be great if you could share dates for better planning to mitigate this very high risk in our platform.
On Monday, 23 May 2022 at 18:06:08 UTC+5:30 Daniel Vogelheim wrote: > Thanks all for the feedback. Update(s): > - The warnings are live, for about two weeks now. Usage is trending down, > but slowly. > - I'd like to postpone flipping the default to M109, as requested (here, > and offline). The existing caveats - particularly a new intent, as > requested by Yoav upthread - still apply. > > On Tue, Apr 26, 2022 at 10:13 PM 'tuvia.kaha...@gtempaccount.com' via > blink-dev <blin...@chromium.org> wrote: > >> We also have a fair amount of dependencies on domain lowering via >> document.domain, which affects millions of users. We are in the process of >> providing solutions for that, but we need more time than M106. >> >> Thanks >> >> On Tuesday, December 14, 2021 at 4:09:07 PM UTC+2 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+...@chromium.org. >> > To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a1df588f-7b03-4369-a4e8-e81534224c82n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a1df588f-7b03-4369-a4e8-e81534224c82n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- 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/ac232d65-8abd-41d3-bdcb-22c5dffeadb3n%40chromium.org.
