Intent to Ship: Origin Isolation By Default / Deprecate document.domain

1570 views
Skip to first unread message

Daniel Vogelheim

unread,
Dec 14, 2021, 9:09:07 AM12/14/21
to blink-dev, va...@chromium.org

Contact emails

va...@chromium.org, voge...@chromium.org


Specification

Explainer: https://github.com/mikewest/deprecating-document-domain

HTML Spec draft: 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

(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% of page views rely upon document.domain to enable some cross-origin access that wasn't otherwise possible. 0.24% 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.


G
ecko: Standards position request. (Provisionally "worth prototyping", but is open for additional comments/opinions. Mozilla representatives also participated in the TAG discussion. No concrete implementation plans were given.


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 users

M101 - 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.

 

Security

This 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?

Are in place to test the current functionality, and will be adjusted within the M101 timeframe to ensure the feature is working as intended.


Tracking bug

https://crbug.com/1139851


Launch bug

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)

Daniel Bratell

unread,
Dec 14, 2021, 11:35:57 AM12/14/21
to Daniel Vogelheim, blink-dev, va...@chromium.org

It seems more or less everyone agrees on this being a good thing, so it mainly comes down to web compatibility.

How much of the web will break, and how badly. The numbers mentioned, 0.5% of sites set document.domain, 0.05% seem to depend on document.domain, are quite high. One thing I didn't quite pick up is what happens if you try to set document.domain when it's not settable. Will it silently pretend to work, or will that also be a possible break point?

There is also the question of reverse origin trial and enterprise flags. If Origin-Agent-Cluster can be set with <meta http-equiv="....">, then I don't see any use for an origin trial since that would be activated the same way. An enterprise flag might still be needed though, since that covers installations where the client can be configured, but applications can not be changed.

/Daniel

--
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/CALG6KPOmpEUx5xST3QHRHdU9yPbA4ucMYQB4dMQcHys9KNRsrg%40mail.gmail.com.

Mike Taylor

unread,
Dec 14, 2021, 5:51:20 PM12/14/21
to Daniel Bratell, Daniel Vogelheim, blink-dev, va...@chromium.org
On 12/14/21 11:35 AM, Daniel Bratell wrote:

It seems more or less everyone agrees on this being a good thing, so it mainly comes down to web compatibility.

How much of the web will break, and how badly. The numbers mentioned, 0.5% of sites set document.domain, 0.05% seem to depend on document.domain, are quite high. One thing I didn't quite pick up is what happens if you try to set document.domain when it's not settable. Will it silently pretend to work, or will that also be a possible break point?

I would be surprised if it didn't behave the same as setting an arbitrary expando on `document` - we should be safe there.

There is also the question of reverse origin trial and enterprise flags. If Origin-Agent-Cluster can be set with <meta http-equiv="....">, then I don't see any use for an origin trial since that would be activated the same way. An enterprise flag might still be needed though, since that covers installations where the client can be configured, but applications can not be changed.

/Daniel

On 2021-12-14 15:06, Daniel Vogelheim wrote:

Contact emails

va...@chromium.org, voge...@chromium.org


Specification

Explainer: https://github.com/mikewest/deprecating-document-domain

HTML Spec draft: 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

(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. 
As Daniel mentioned, I think the compat risk should be considered to be higher, despite this being deprecated for a long time.

Current usage of the document.domain: 0.05% of page views rely upon document.domain to enable some cross-origin access that wasn't otherwise possible. 0.24% 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.
(cool site, btw)

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.
Out of curiosity, did any of them mention what couldn't be achieved via existing APIs?

Gecko: Standards position request. (Provisionally "worth prototyping", but is open for additional comments/opinions. Mozilla representatives also participated in the TAG discussion. No concrete implementation plans were given.
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 users

What's the plan if the use counters don't move? Do you have a minimum page view % in mind you would want before proceeding to the next step (even if it meant delaying the timeline)?

M101 - 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.

Would this disabled-by-default change ride the trains, or have you considered finching it out to assess compat risk?

 

Security

This 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?

Are in place to test the current functionality, and will be adjusted within the M101 timeframe to ensure the feature is working as intended.


Tracking bug

https://crbug.com/1139851


Launch bug

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/CALG6KPOmpEUx5xST3QHRHdU9yPbA4ucMYQB4dMQcHys9KNRsrg%40mail.gmail.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+...@chromium.org.

Yoav Weiss

unread,
Dec 15, 2021, 4:31:54 AM12/15/21
to Mike Taylor, Daniel Bratell, Daniel Vogelheim, blink-dev, va...@chromium.org
On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor <mike...@chromium.org> wrote:
On 12/14/21 11:35 AM, Daniel Bratell wrote:

It seems more or less everyone agrees on this being a good thing, so it mainly comes down to web compatibility.

How much of the web will break, and how badly. The numbers mentioned, 0.5% of sites set document.domain, 0.05% seem to depend on document.domain, are quite high. One thing I didn't quite pick up is what happens if you try to set document.domain when it's not settable. Will it silently pretend to work, or will that also be a possible break point?

I would be surprised if it didn't behave the same as setting an arbitrary expando on `document` - we should be safe there.

There is also the question of reverse origin trial and enterprise flags. If Origin-Agent-Cluster can be set with <meta http-equiv="....">, then I don't see any use for an origin trial since that would be activated the same way. An enterprise flag might still be needed though, since that covers installations where the client can be configured, but applications can not be changed.

I'd be surprised if meta http-equiv is supported, as IIUC, the decision on an agent cluster needs to be made before the document is committed, hence the opt-in can't be made available to markup.
I'm guessing the same would be true for a deprecation trial (as a result, there's no difference between one and the header based opt-in).
Also, what would be the (estimated) usage if those 4 top users would move away from relying on document.domain?
  

Daniel Vogelheim

unread,
Dec 15, 2021, 5:49:48 AM12/15/21
to Mike Taylor, Daniel Bratell, blink-dev, va...@chromium.org
On 12/14/21 11:35 AM, Daniel Bratell wrote:

It seems more or less everyone agrees on this being a good thing, so it mainly comes down to web compatibility.

How much of the web will break, and how badly. The numbers mentioned, 0.5% of sites set document.domain, 0.05% seem to depend on document.domain, are quite high. One thing I didn't quite pick up is what happens if you try to set document.domain when it's not settable. Will it silently pretend to work, or will that also be a possible break point?


It does nothing, silently. This matches the behaviour when Origin-Agent-Cluster is explicitly set to true. From a developer's perspective, the current default matches explicit-false and the future default is meant to match explicit-true.

Reference: Step 7 of "The domain setter steps are" of https://html.spec.whatwg.org/multipage/origin.html#dom-document-domain.

There is also the question of reverse origin trial and enterprise flags. If Origin-Agent-Cluster can be set with <meta http-equiv="....">, then I don't see any use for an origin trial since that would be activated the same way. An enterprise flag might still be needed though, since that covers installations where the client can be configured, but applications can not be changed.


An enterprise policy has been implemented
We didn't think a reverse origin trial would make sense, since any site can already opt-out by setting the Origin-Agent-Cluster header.

Daniel Vogelheim

unread,
Dec 16, 2021, 10:28:25 AM12/16/21
to Mike Taylor, Daniel Bratell, blink-dev, va...@chromium.org
On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor <mike...@chromium.org> wrote:
On 12/14/21 11:35 AM, Daniel Bratell wrote:

It seems more or less everyone agrees on this being a good thing, so it mainly comes down to web compatibility.

How much of the web will break, and how badly. The numbers mentioned, 0.5% of sites set document.domain, 0.05% seem to depend on document.domain, are quite high. One thing I didn't quite pick up is what happens if you try to set document.domain when it's not settable. Will it silently pretend to work, or will that also be a possible break point?

I would be surprised if it didn't behave the same as setting an arbitrary expando on `document` - we should be safe there.

Almost. The error handling is mostly the same. But while a foreign attribute on document would return the new value, document.domain (when in an origin-keyed agent cluster) does not.

So:
  document.foo = "bla"
  document.foo  // Returns "bla".

  document.domain = "bla"  // Throws SecurityException.

  // On a domain www.host.com, site-keyed agent cluster (current default)
  document.domain = "host.com"  // Succeeds.
  document.domain;  // returns "host.com".

  // On a domain www.host.com, origin-keyed agent cluster (future default)
  document.domain = "host.com"  // Doesn't throw. Doesn't do anything else either.
  document.domain;  // Still returns www.host.com.

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. 
As Daniel mentioned, I think the compat risk should be considered to be higher, despite this being deprecated for a long time.

Yes, agreed.

Current usage of the document.domain: 0.05% of page views rely upon document.domain to enable some cross-origin access that wasn't otherwise possible. 0.24% 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.
(cool site, btw)
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.
Out of curiosity, did any of them mention what couldn't be achieved via existing APIs?

I checked back, and nothing particular came up. It seems that migrating off of document.domain isn't blocked by a lack of options.

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 users

What's the plan if the use counters don't move? Do you have a minimum page view % in mind you would want before proceeding to the next step (even if it meant delaying the timeline)?

We don't have a dead-set plan. The primary idea is a combination of delay-ing until usage is low enough, and outreach to offending sites to educate about the problem & available alternatives.

 

M101 - 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.

Would this disabled-by-default change ride the trains, or have you considered finching it out to assess compat risk?

My original plan was to enable it by default in the 101 release, and have a Finch switch as an emergency-off. Reading the feedback here, maybe it's better to incrementally enable it via Finch. I'll be happy to follow whatever path API owners prefer.

Charlie Reis

unread,
Dec 16, 2021, 5:52:39 PM12/16/21
to Daniel Vogelheim, Mike Taylor, Daniel Bratell, blink-dev, va...@chromium.org
In my experience (caveat: I'm not an API owner), it's harder to repro and triage compatibility bugs that get filed if a feature is only enabled for a percentage of users via Finch.  It tends to be quicker to bisect reports and get attention on a compat bug if the feature is enabled on trunk instead, with an easy way to revert if needed.  (Finch is certainly better when you care about performance issues, which doesn't seem to be the case here.)

Charlie


--
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.

Mike Taylor

unread,
Dec 18, 2021, 3:38:33 PM12/18/21
to Charlie Reis, Daniel Vogelheim, Daniel Bratell, blink-dev, va...@chromium.org

Yeah, I hear you - the unpredictability is a challenge. My preferred approach would be to hold things at 100% in pre-release channels for some period of time to sniff out compat bugs - but AIUI, this isn't really a thing that Finch is designed to do, and pre-release comes with its own set of biases that may not accurately reflect release behavior. But where the risk is non-zero, only breaking some users seems better than breaking all users, even if imperfect.

Yoav Weiss

unread,
Jan 12, 2022, 12:45:44 PMJan 12
to blink-dev, Mike Taylor, Daniel Bratell, blink-dev, Lutz Vahl, Charlie Reis, Daniel Vogelheim, Brandon Heenan, Greg Whitworth, Eiji Kitamura
Hey Daniel!

While searching for this intent review, I stumbled upon https://developer.chrome.com/blog/immutable-document-domain/ 
That's a useful piece of documentation! Thanks +Eiji Kitamura!!

This intent was just discussed at the API owner meeting (where Chris, Rego, Daniel, Philip, Alex, MikeT and myself were present).
This change seems risky in terms of potential breakage when looking at our stats, and that's even before talking about enterprises, where a lot of the API owners feel the risk is even higher.

Given that, here's a few potential next steps to try and reduce that risk:
  • UKM and outreach to specific large users of the API can maybe help drive the usage down.
  • A deprecation period of 3 milestones feels a bit short here. Is the expectation that turning on the opt-out header can be done under that period?
  • A report-only mode could have allowed sites to try and enable this, without risking actual breakage for their documents/properties that use document.domain. This is doubly true for platforms that want to warn their customers about this upcoming deprecation, but without taking risks on their behalf. At the same time, it is true that they could collect deprecation reports (thanks for adding those!) instead during the deprecation period, which can be considered an on-by-default report-only mode. Can y'all add specific guidance on deprecation reports to the documentation?
  •  It'd be helpful to reach out to enterprise folks and see what their responses may be for this. +Greg Whitworth.
  • This probably requires an Enterprise Policy, to reduce the risk for managed installs. +bheenan@ for opinions on that front.
  • Is there a plan to eventually remove the opt-out option? Or is it the plan to have it in place permanently?
Cheers,
Yoav


Brandon Heenan

unread,
Jan 13, 2022, 5:32:48 PMJan 13
to Yoav Weiss, blink-dev, Mike Taylor, Daniel Bratell, Lutz Vahl, Charlie Reis, Daniel Vogelheim, Brandon Heenan, Greg Whitworth, Eiji Kitamura, Marijke Hoste
> This probably requires an Enterprise Policy, to reduce the risk for managed installs. +bheenan@ for opinions on that front.

I agree, this looks like a breaking change according to go/chrome-enterprise-friendly and therefore needs a policy. Instructions for implementing a policy are here: https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md if you haven't done it before, and the enterprise team is happy to help if anything seems confusing. Having this implemented as a "soft removal" with a temporary policy escape hatch significantly reduces enterprise risk, since even if we are surprised by a use case hiding behind many enterprises' tendency to turn off metrics, those users can break-fix themselves immediately while staying on the latest version.

Charlie Reis

unread,
Jan 13, 2022, 6:35:03 PMJan 13
to Brandon Heenan, Yoav Weiss, blink-dev, Mike Taylor, Daniel Bratell, Lutz Vahl, Daniel Vogelheim, Brandon Heenan, Greg Whitworth, Eiji Kitamura, Marijke Hoste
Note that Daniel has already landed the enterprise policy for this in https://chromium-review.googlesource.com/c/chromium/src/+/3317349 (99.0.4759.0).

Charlie

Greg Whitworth

unread,
Jan 13, 2022, 10:19:30 PMJan 13
to blink-dev, Charlie Reis, yoav...@chromium.org, blink-dev, mike...@chromium.org, Daniel Bratell, va...@chromium.org, Daniel Vogelheim, Brandon Heenan, gkwin...@gmail.com, Eiji Kitamura, Marijke Hoste, Brandon Heenan
Hey folks,

I'll be spinning up a thread with some internal folks here at Salesforce to start doing some scans of code to determine utilization. Has this been added to the reporting API for deprecation to possibly capture live hits that way as well?

I'll follow up on what I find and that will influence my opinion on removal timeline.

~Greg

Yoav Weiss

unread,
Jan 14, 2022, 12:06:17 AMJan 14
to Greg Whitworth, blink-dev, Charlie Reis, mike...@chromium.org, Daniel Bratell, va...@chromium.org, Daniel Vogelheim, Brandon Heenan, gkwin...@gmail.com, Eiji Kitamura, Marijke Hoste, Brandon Heenan
On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth <gregcwh...@gmail.com> wrote:
Hey folks,

I'll be spinning up a thread with some internal folks here at Salesforce to start doing some scans of code to determine utilization. Has this been added to the reporting API for deprecation to possibly capture live hits that way as well?

I believe the intent is asking to add those as part of the deprecation period, but that hasn't happened yet.

Daniel Vogelheim

unread,
Jan 14, 2022, 7:59:15 AMJan 14
to Yoav Weiss, blink-dev, Mike Taylor, Daniel Bratell, Lutz Vahl, Charlie Reis, Brandon Heenan, Greg Whitworth, Eiji Kitamura
Hi all,
Hi Yoav,

Thanks for the feedback. I'd like to modify the intent timeline as follows:

M99: Start showing a deprecation warning.
M99-105: Watch use counters + outreach to top-N users.
M105: Deprecate the feature by default.

Enabling/disabling will be via Finch, so we have an emergency shut-off.

An enterprise policy is already in place.

On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss <yoav...@chromium.org> wrote:
Hey Daniel!

While searching for this intent review, I stumbled upon https://developer.chrome.com/blog/immutable-document-domain/ 
That's a useful piece of documentation! Thanks +Eiji Kitamura!!

This intent was just discussed at the API owner meeting (where Chris, Rego, Daniel, Philip, Alex, MikeT and myself were present).
This change seems risky in terms of potential breakage when looking at our stats, and that's even before talking about enterprises, where a lot of the API owners feel the risk is even higher.

Given that, here's a few potential next steps to try and reduce that risk:
  • UKM and outreach to specific large users of the API can maybe help drive the usage down.

Will do. With Lutz' help I just checked the UKM we have on this, and it seems the usage is quite heavily concentrated on large sites. The top-quartile of remaining public usage is just 9 sites; top-half is ~35. We'll try to reach out to them.
 
  • A deprecation period of 3 milestones feels a bit short here. Is the expectation that turning on the opt-out header can be done under that period?
As above, we'll happily go up on this.

My reasoning why 3 milestones would be reasonable was that there is a "safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't sure, or just wants to postpone the issue, one can just add 'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different from e.g. CSP, where adding new CSP headers might require a lot of work and testing.
 
  • A report-only mode could have allowed sites to try and enable this, without risking actual breakage for their documents/properties that use document.domain. This is doubly true for platforms that want to warn their customers about this upcoming deprecation, but without taking risks on their behalf. At the same time, it is true that they could collect deprecation reports (thanks for adding those!) instead during the deprecation period, which can be considered an on-by-default report-only mode. Can y'all add specific guidance on deprecation reports to the documentation?

We see the deprecation warning - without any behavioural changes - as effectively being the report-only mode. We'll be more clear in the documentation.
 
  •  It'd be helpful to reach out to enterprise folks and see what their responses may be for this. +Greg Whitworth.
  • This probably requires an Enterprise Policy, to reduce the risk for managed installs. +bheenan@ for opinions on that front.
I agree, and an enterprise policy is already in place.
 
  • Is there a plan to eventually remove the opt-out option? Or is it the plan to have it in place permanently?

There is no plan. The current logic is relatively easy to maintain, so we have not made any plan to remove the opt-out.

Daniel Vogelheim

unread,
Jan 14, 2022, 8:02:49 AMJan 14
to Brandon Heenan, blink-dev
On Thu, Jan 13, 2022 at 11:32 PM Brandon Heenan <bhe...@google.com> wrote:
> This probably requires an Enterprise Policy, to reduce the risk for managed installs. +bheenan@ for opinions on that front.

I agree, this looks like a breaking change according to go/chrome-enterprise-friendly and therefore needs a policy. Instructions for implementing a policy are here: https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md if you haven't done it before, and the enterprise team is happy to help if anything seems confusing. Having this implemented as a "soft removal" with a temporary policy escape hatch significantly reduces enterprise risk, since even if we are surprised by a use case hiding behind many enterprises' tendency to turn off metrics, those users can break-fix themselves immediately while staying on the latest version.

I agree, and a policy is already in place. (I'll have to update it with the new milestones, though.)

Daniel Vogelheim

unread,
Jan 14, 2022, 8:17:25 AMJan 14
to Greg Whitworth, blink-dev
On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth <gregcwh...@gmail.com> wrote:
Hey folks,

I'll be spinning up a thread with some internal folks here at Salesforce to start doing some scans of code to determine utilization. Has this been added to the reporting API for deprecation to possibly capture live hits that way as well?

Not yet. That'd be the first step once this intent is approved. 

I'll follow up on what I find and that will influence my opinion on removal timeline.

Thank you, this would be very helpful.
If it helps: salesforce.com (or other Salesforce country domains) do not show up in our telemetry, so with some likelihood you're among the >99% sites that do not even use this mis-feature. :-)
(Caveat: You might use other domains as well; or maybe your customers dis-proportionally disable reporting.)

If you have a staging environment, you can simulate the deprecation by adding the "Origin-Agent-Cluster: ?1" header. This explicitly enables clustering by origin. document.domain setting will have no effect, and a console message will be printed. (In other words: This is behaviour we'd like to be the default.)
If you do find usage that you cannot easily replace, adding "Origin-Agent-Cluster: ?0" will disable this.

Alex Russell

unread,
Jan 14, 2022, 1:06:58 PMJan 14
to blink-dev, Daniel Vogelheim, blink-dev, Greg Whitworth
Daniel: 

Salesforce use is concentrated in enterprises, and the enterprise opt-in rates for metrics and crash reporting are very, very, very low. As a result, I'm not sure we should trust UKM here. 

Greg: 

Thanks so much for looking into your code. I know it might take time for your larger ecosystem to start sending y'all deprecation reports. How long after the deprecation API starts reporting do you think it'll be before we can get solid information from your service?

Thanks.

T K

unread,
Jan 18, 2022, 12:41:22 PMJan 18
to blink-dev, sligh...@chromium.org, Daniel Vogelheim, blink-dev, Greg Whitworth
Hi,
Do you know if there is  a way to get a Chrome version with those changes to see how those changes impact my site?
Thanks

Noah Lemen

unread,
Jan 20, 2022, 2:11:32 PMJan 20
to blink-dev, T K, sligh...@chromium.org, Daniel Vogelheim, blink-dev, Greg Whitworth, niem...@fb.com, Noah Lemen, jak...@fb.com
At Meta (formerly known as Facebook) we have a fair amount of dependencies on domain lowering via document.domain. We've discussed this internally, and feel that the most difficult aspect of this for us currently is identifying where we depend on domain lowering. We feel that something that may be helpful for us would be a reporting API not on document.domain, but rather on any cross-origin accesses that are only working because of domain lowering. Would a reporting API like this be possible to add to help us along the deprecation process?

Yoav Weiss

unread,
Jan 21, 2022, 3:23:15 PMJan 21
to Alex Russell, blink-dev, Daniel Vogelheim, Greg Whitworth
LGTM1 to deprecate under the following conditions:
  • As discussed, a 6 months deprecation period, as well as broad-scope and targeted outreach, that would hopefully bring usage down.
  • A well-crafted deprecation message that indicates the timeline, and at the same time indicates that we'll be responsive to community feedback (or a link to a blog post/documentation page that indicates the same)
  • Sending a separate intent for the actual removal at the end of the deprecation period, once the picture is a bit clearer.

--
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.

Chris Harrelson

unread,
Jan 21, 2022, 5:04:18 PMJan 21
to Noah Lemen, blink-dev, T K, sligh...@chromium.org, Daniel Vogelheim, Greg Whitworth, niem...@fb.com, Noah Lemen, jak...@fb.com
On Thu, Jan 20, 2022 at 11:11 AM Noah Lemen <noah....@gmail.com> wrote:
At Meta (formerly known as Facebook) we have a fair amount of dependencies on domain lowering via document.domain. We've discussed this internally, and feel that the most difficult aspect of this for us currently is identifying where we depend on domain lowering. We feel that something that may be helpful for us would be a reporting API not on document.domain, but rather on any cross-origin accesses that are only working because of domain lowering. Would a reporting API like this be possible to add to help us along the deprecation process?

This is an interesting request, and I can see how it would be quite useful. @Daniel Vogelheim do you think it's feasible?
 
--
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.

Daniel Bratell

unread,
Jan 23, 2022, 1:47:59 PMJan 23
to Yoav Weiss, Alex Russell, blink-dev, Daniel Vogelheim, Greg Whitworth

Maybe it's wrong to call it "removal" too, since it will still be available for those sites that use site-keyed clusters. It's just making site-keyed clusters opt-in instead of opt-out. It's not going away, but it will require an extra step to use.

/Daniel

Daniel Vogelheim

unread,
Jan 24, 2022, 9:34:05 AMJan 24
to Yoav Weiss, Alex Russell, blink-dev, Greg Whitworth
On Fri, Jan 21, 2022 at 9:23 PM Yoav Weiss <yoav...@chromium.org> wrote:
LGTM1 to deprecate under the following conditions:
  • As discussed, a 6 months deprecation period, as well as broad-scope and targeted outreach, that would hopefully bring usage down.
  • A well-crafted deprecation message that indicates the timeline, and at the same time indicates that we'll be responsive to community feedback (or a link to a blog post/documentation page that indicates the same)
  • Sending a separate intent for the actual removal at the end of the deprecation period, once the picture is a bit clearer.
Thanks, will do. 

Daniel Vogelheim

unread,
Jan 24, 2022, 9:40:16 AMJan 24
to Chris Harrelson, Noah Lemen, blink-dev, T K, sligh...@chromium.org, Greg Whitworth, niem...@fb.com, Noah Lemen, jak...@fb.com
On Fri, Jan 21, 2022 at 11:04 PM Chris Harrelson <chri...@google.com> wrote:
On Thu, Jan 20, 2022 at 11:11 AM Noah Lemen <noah....@gmail.com> wrote:
At Meta (formerly known as Facebook) we have a fair amount of dependencies on domain lowering via document.domain. We've discussed this internally, and feel that the most difficult aspect of this for us currently is identifying where we depend on domain lowering. We feel that something that may be helpful for us would be a reporting API not on document.domain, but rather on any cross-origin accesses that are only working because of domain lowering. Would a reporting API like this be possible to add to help us along the deprecation process?

This is an interesting request, and I can see how it would be quite useful. @Daniel Vogelheim do you think it's feasible?

Yes, that's a super sensible request, and it's very much feasible. In fact, my understanding was that the deprecation warning mechanism, which we are using, already supports this. I'll double check. If this isn't possible with the current code, I'll add it in.

One thing I've learnt here - from this request, but also TK's and Greg's - is that I have undercommunicated the options available to site owners. I'll write a seperate doc that is more clear on this, and spells these things out more clearly.

Daniel Vogelheim

unread,
Jan 24, 2022, 9:48:49 AMJan 24
to Daniel Bratell, Yoav Weiss, Alex Russell, blink-dev, Greg Whitworth
On Sun, Jan 23, 2022 at 7:47 PM Daniel Bratell <brat...@gmail.com> wrote:

Maybe it's wrong to call it "removal" too, since it will still be available for those sites that use site-keyed clusters. It's just making site-keyed clusters opt-in instead of opt-out. It's not going away, but it will require an extra step to use.


This is true, but I'm not sure where to go with this. Since we're effectively asking (affected) site owners to change something, it's arguably closer to a deprecation than to a "normal" feature which would add functionality. To that end, calling it "deprecation" does get the right people's attention. I suspect that people would have missed it if we had called it "origin cluster opt-in" or something. But of course, technically it indeed isn't a deprecation, because the functionality itself remains available. Should I change the title?

I think a more comprehensive document that spells out the options/consequences more clearly solves most of this problem. :)

Chris Harrelson

unread,
Jan 24, 2022, 11:10:46 AMJan 24
to Daniel Vogelheim, Daniel Bratell, Yoav Weiss, Alex Russell, blink-dev, Greg Whitworth
LGTM2 under  Yoav's stated conditions, plus adding the mode Noah suggested and the additional documentation. I recommend a web.dev article about the why of this change and with the ways developers can plan for it.

--
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.

Daniel Vogelheim

unread,
Jan 24, 2022, 11:23:00 AMJan 24
to Noah Lemen, blink-dev, T K, sligh...@chromium.org, Greg Whitworth, niem...@fb.com, Noah Lemen, jak...@fb.com
Hi Noah,

On Thu, Jan 20, 2022 at 8:11 PM Noah Lemen <noah....@gmail.com> wrote:
At Meta (formerly known as Facebook) we have a fair amount of dependencies on domain lowering via document.domain. We've discussed this internally, and feel that the most difficult aspect of this for us currently is identifying where we depend on domain lowering. We feel that something that may be helpful for us would be a reporting API not on document.domain, but rather on any cross-origin accesses that are only working because of domain lowering. Would a reporting API like this be possible to add to help us along the deprecation process?

This should work as-is. I just tried it out: When warnings are enabled (i.e., during the 6 milestone warning period), or when --enable-features=OriginAgentClusterDefaultWarning is used on the current tip-of-tree build, assigning to document.domain triggers the deprecation warning (if no other errors interfere). The warning is delivered through the Reporting API and can be programmatically processed using ReportingObserver, For example, the first code snippet in this article will successfully report the warning. Is this what you're looking for?

Daniel Vogelheim

unread,
Jan 24, 2022, 11:36:00 AMJan 24
to Noah Lemen, blink-dev, T K, sligh...@chromium.org, Greg Whitworth, niem...@fb.com, Noah Lemen, jak...@fb.com
Hi again,

On Mon, Jan 24, 2022 at 5:22 PM Daniel Vogelheim <voge...@google.com> wrote:
Hi Noah,

On Thu, Jan 20, 2022 at 8:11 PM Noah Lemen <noah....@gmail.com> wrote:
At Meta (formerly known as Facebook) we have a fair amount of dependencies on domain lowering via document.domain. We've discussed this internally, and feel that the most difficult aspect of this for us currently is identifying where we depend on domain lowering. We feel that something that may be helpful for us would be a reporting API not on document.domain, but rather on any cross-origin accesses that are only working because of domain lowering. Would a reporting API like this be possible to add to help us along the deprecation process?

This should work as-is. I just tried it out: When warnings are enabled (i.e., during the 6 milestone warning period), or when --enable-features=OriginAgentClusterDefaultWarning is used on the current tip-of-tree build, assigning to document.domain triggers the deprecation warning (if no other errors interfere). The warning is delivered through the Reporting API and can be programmatically processed using ReportingObserver, For example, the first code snippet in this article will successfully report the warning. Is this what you're looking for?

It's been pointed out to me that I've overlooked the "on any accesses that are only working because of domain lowering" bit. That isn't there. I'll see if I can add it. Sorry for misunderstanding.

Greg Whitworth

unread,
Jan 24, 2022, 7:05:39 PMJan 24
to blink-dev, Daniel Vogelheim, blink-dev, T K, sligh...@chromium.org, Greg Whitworth, niem...@fb.com, Noah Lemen, jak...@fb.com, Noah Lemen
> It's been pointed out to me that I've overlooked the "on any accesses that are only working because of domain lowering" bit. That isn't there. I'll see if I can add it. Sorry for misunderstanding.

This would be valuable to us as well once it's implemented. Thank you.

Greg Whitworth

unread,
Jan 24, 2022, 7:09:42 PMJan 24
to blink-dev, Daniel Vogelheim, blink-dev, T K, sligh...@chromium.org, Greg Whitworth, niem...@fb.com, Noah Lemen, jak...@fb.com, Noah Lemen
Apologies for forgetting to ask this in my last post: 

> As discussed, a 6 months deprecation period

Can we be explicit, which M release/Month will this be presuming the other conditions are met.

Thank you,
Greg

Daniel Bratell

unread,
Jan 26, 2022, 11:35:30 AMJan 26
to Daniel Vogelheim, Yoav Weiss, blink-dev, Mike Taylor, Lutz Vahl, Charlie Reis, Brandon Heenan, Greg Whitworth, Eiji Kitamura

LGTM3

/Daniel

Daniel Vogelheim

unread,
Feb 14, 2022, 12:28:18 PMFeb 14
to blink-dev
Hi all, just a brief update:

- The warning should go live on M100.
- Flipping the default is planned for M106 but there'll be a separate intent (and thus additional discussion), as requested.
- A deprecation warning for cross-domain access (based on previous document.domain setting) is in the works, and will either make it to M100 also, or will land shortly after.
- Additional info: Blog post; plus some technical notes.

Noah Lemen

unread,
Feb 25, 2022, 11:31:10 AMFeb 25
to blink-dev, Daniel Vogelheim, Noah Lemen, benny...@fb.com
Any updates on the deprecation warning for cross-domain access? We're now looking into setting up the Reporting API to capture this once available. Which milestone do you estimate it will ship?

Daniel Vogelheim

unread,
Feb 25, 2022, 12:09:24 PMFeb 25
to Noah Lemen, blink-dev, Noah Lemen, benny...@fb.com
Hi Noah,

Support for the cross-origin access warning landed this week, but unfortunately only after the M100 branch cut. So this will first appear in M101.
If you're willing to build Chromium from tip-of-tree, you should be able to try it out now.

Daniel

T K

unread,
Mar 7, 2022, 12:07:37 PMMar 7
to blink-dev, Daniel Vogelheim
Hi , 
When will the Enterprise Policy be released, and how it will look like?
For on premise customers patching the system, it is a long process that might take more than M106 (around September)  
Thanks, 
Tuvia.


Charlie Reis

unread,
Mar 7, 2022, 7:12:08 PMMar 7
to T K, blink-dev, Daniel Vogelheim
I believe you're looking for https://chromeenterprise.google/policies/#OriginAgentClusterDefaultEnabled, which appears to be supported as of version 100.

Charlie

--
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.

PhistucK

unread,
Mar 9, 2022, 6:49:19 PMMar 9
to Charlie Reis, T K, blink-dev, Daniel Vogelheim
Just chiming in to say that Cypress apparently relies on setting document.domain for its "test across the same-site" feature.
Might need either some outreach, or an alternative for them via the Chrome debugging protocol.

PhistucK


Daniel Vogelheim

unread,
Mar 10, 2022, 11:33:38 AMMar 10
to PhistucK, blink-dev
On Thu, Mar 10, 2022 at 12:49 AM PhistucK <phis...@gmail.com> wrote:
Just chiming in to say that Cypress apparently relies on setting document.domain for its "test across the same-site" feature.

Thank you. This is a different use-case from what I've seen so far, which makes it interesting. 

Might need either some outreach, or an alternative for them via the Chrome debugging protocol.

Since they speak of "injecting document.domain" my first guess is that they might be interested in also injecting the "Origin-Agent-Cluster: ?0" http header. Either way, I'll try to contact them.

Message has been deleted

tuvia.kaha...@gtempaccount.com

unread,
Apr 26, 2022, 4:13:57 PMApr 26
to blink-dev, voge...@chromium.org, va...@chromium.org

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

HTML Spec draft: 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

(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% of page views rely upon document.domain to enable some cross-origin access that wasn't otherwise possible. 0.24% 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.


G
ecko: Standards position request. (Provisionally "worth prototyping", but is open for additional comments/opinions. Mozilla representatives also participated in the TAG discussion. No concrete implementation plans were given.


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 users

M101 - 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.

 

Security

This 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?

Are in place to test the current functionality, and will be adjusted within the M101 timeframe to ensure the feature is working as intended.


Tracking bug

https://crbug.com/1139851


Launch bug

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)

Jerilyn D.

unread,
May 2, 2022, 3:08:17 PMMay 2
to blink-dev, voge...@chromium.org, va...@chromium.org
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:// ?

Daniel Vogelheim

unread,
May 23, 2022, 8:36:08 AMMay 23
to blink-dev, va...@chromium.org, tuvia.kaha...@gtempaccount.com
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.
--
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.

Daniel Vogelheim

unread,
May 23, 2022, 9:48:47 AMMay 23
to Jerilyn D., blink-dev, va...@chromium.org
On Mon, May 2, 2022 at 8:38 PM Jerilyn D. <d.je...@gmail.com> wrote:
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 ?

There is no plan for dropping the Origin-Agent-Cluster header, or the Origin-Agent-Cluster: ?0 value in particular.
 
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:// ?

That's a rather excellent question, and since the point is to preserve existing behaviour it should also work in a non-secure context. I double checked, and the current implementation correctly works for insecure contexts. Please let me know if you find a bug here.

However, I didn't find any unit tests for behaviour specifically in insecure contexts. I'll add those to ensure that the legacy behaviour will continue to work correctly.

The information that O-A-C will only be honored in secure contexts is partially true: Enabling per-origin clustering is indeed bound to a secure context. But disabling - the legacy behaviour - isn't.

Daniel Vogelheim

unread,
Jul 13, 2022, 11:51:10 AMJul 13
to Yaseen Khan, blink-dev
Hello Yaseen,

On Wed, Jul 13, 2022 at 2:47 PM Yaseen Khan <yase...@gmail.com> wrote:
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.

As written earlier in this thread, the deprecation of document.domain, aka defaulting origin-agent-cluster: to ?1, is scheduled for M109. This is slightly postponed from the original plan at M106. https://chromiumdash.appspot.com/schedule provides a schedule that maps versions to planned release dates.

The warning/"issue" in the DevTools issues panel should be active. I'm surprised the message would have disappeared. It should occur whenever document.domain is set, as well as when an access based on a modified document.domain is made. If you have any reproducible case that shows the warning isn't shown even though it should be, I'll gladly investigate.

This is scheduled for M109, but note that API owners will have the final call of whether and when to launch this.

Yaseen Khan

unread,
Jul 13, 2022, 12:29:01 PMJul 13
to blink-dev, Daniel Vogelheim, va...@chromium.org, tuvia.kaha...@gtempaccount.com
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.


Daniel Vogelheim

unread,
Jul 14, 2022, 10:18:14 AMJul 14