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

[Daniel Vogelheim‏]

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.

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.

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 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‏]

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‏]

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.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/315e3206-021c-4fc0-728b-36b0a01811d6%40gmail.com.

[Yoav Weiss‏]

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.

https://github.com/WICG/origin-agent-cluster#no-op-documentdomain-setter-instead-of-throwing suggests you're right.

Also - TIL https://developer.mozilla.org/en-US/docs/Glossary/Expando 

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?

  

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7f103c3d-96c4-1b6d-7f4f-4634be86d030%40chromium.org.

[Daniel Vogelheim‏]

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‏]

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‏]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOOVfCH42eaBeoGCn6KCKjOvoJa1ZY4wY8%3DXHooVytAiA%40mail.gmail.com.

[Mike Taylor‏]

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‏]

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‏]

> 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‏]

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‏]

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‏]

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‏]

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‏]

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‏]

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‏]

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‏]

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‏]

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‏]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bd2f5a7b-a64c-4aa5-aa65-36e6f39fd7e8n%40chromium.org.

[Chris Harrelson‏]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e5950c17-044a-45f4-b248-8246b16f9480n%40chromium.org.

[Daniel Bratell‏]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV9QYzcFoxNvV%2BaNS7p603s45F%2BqZ2z%3D6c0%3DHYPLmMeiw%40mail.gmail.com.

[Daniel Vogelheim‏]

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‏]

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‏]

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‏]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNueOvzs%2BYKy7qrN5J7jiY2sctYnuxtX-Thvnb0m5SVtQ%40mail.gmail.com.

[Daniel Vogelheim‏]

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‏]

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‏]

> 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‏]

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‏]

LGTM3

/Daniel

[Daniel Vogelheim‏]

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‏]

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‏]

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‏]

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‏]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1e6e989a-3e73-4b04-8112-c999522a6a88n%40chromium.org.

[PhistucK‏]

Just chiming in to say that Cypress apparently relies on setting document.domain for its "test across the same-site" feature.

https://docs.cypress.io/guides/references/trade-offs#Same-origin

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

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBa%2B3BAgpKuVaowua_Rz-B5nVHpQGbR-eTRt%3D1S-S29A2g%40mail.gmail.com.

[Daniel Vogelheim‏]

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.

https://docs.cypress.io/guides/references/trade-offs#Same-origin

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.

[tuvia.kaha...@gtempaccount.com‏]

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.

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.

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

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‏]

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.

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.

[Daniel Vogelheim‏]

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‏]

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‏]

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‏]

Hello Yaseen,

On Thu, Jul 14, 2022 at 8:13 AM Yaseen Khan <yase...@gmail.com> wrote:

Hi Daniel,

Thanks for your quick update. Here is the below different deprecated warning message in M100 to M102 and M103.

M100/M101/M102:

Relaxing the same-origin policy by setting "document.domain" is deprecated, and will be disabled by default in M106, around September 2022. To continue using this feature, please opt-out of origin-keyed agent clusters by sending an Origin-Agent-Cluster: ?0 header along with the HTTP response for the document and frames. 

Latest M103:

Relaxing the same-origin policy by setting document.domain is deprecated, and will be disabled by default. To continue using this feature, please opt-out of origin-keyed agent clusters by sending an Origin-Agent-Cluster: ?0 header along with the HTTP response for the document and frames. 

This is due to a general change in the issues panel in DevTools, which has occured around the same time. The target milestone should be displayed separately. In my version, M103, there's a link "Learn more: This change will go into effect with milestone 106."

Thanks to your feedback, however, I noticed that I had forgotten to update that milestone when making the other changes. I've now submitted a CL to mark the 'document.domain' issue as scheduled for M109 (rather than M106). So from the next version on - should be M105 -  this should correctly state 109.

Thanks,

Daniel

Regards,

Yaseen

[Yaseen Khan‏]

Hi Daniel,

Thanks for your quick update. Here is the below different deprecated warning message in M100 to M102 and M103.

M100/M101/M102:

Relaxing the same-origin policy by setting "document.domain" is deprecated, and will be disabled by default in M106, around September 2022. To continue using this feature, please opt-out of origin-keyed agent clusters by sending an Origin-Agent-Cluster: ?0 header along with the HTTP response for the document and frames. 

Latest M103:

Relaxing the same-origin policy by setting document.domain is deprecated, and will be disabled by default. To continue using this feature, please opt-out of origin-keyed agent clusters by sending an Origin-Agent-Cluster: ?0 header along with the HTTP response for the document and frames. 

Regards,

Yaseen

[Yaseen Khan‏]

That's great :-)

--

Warm Regards,

Yaseen
+91-9731 404 404

[Yaseen Khan‏]

Hi Daniel,

From my last conversation, I could understand that enforcing "origin-agent-cluster" feature got extended from V106 to V109. However I could still see the waring message in latest V104 - saying it is going to taking effect from V106.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

1. Deprecated Feature Used

   1. Relaxing the same-origin policy by setting document.domain is deprecated, and will be disabled by default. To continue using this feature, please opt-out of origin-keyed agent clusters by sending an Origin-Agent-Cluster: ?0 header along with the HTTP response for the document and frames. See https://developer.chrome.com/blog/immutable-document-domain/ for more details.

Learn more: This change will go into effect with milestone 106.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Does this something missing to update warning message or planning to enfore this feature starting from V106?. Could you please clarify on this?

[Daniel Vogelheim‏]

Hello all,

It's been a while and 109 is coming up. As I'm preparing the intent-to-ship for 109, I'd like to post an update on how the deprecation is going:

Current usage: Since announcing the deprecation, usage of document.domain-enabled accesses have dropped by about 50%.

- Feature stats: DocumentDomainEnabledCrossOriginAccess

- Note that this *includes* usage when an Origin-Agent-Cluster header is explicitly set, which is sustainable use that is not affected by the deprecation.

- CrossOriginAccessBasedOnDocumentDomain is usage of document.domain enabled access, but only when based on the Origin-Agent-Cluster's default (which is what this intent wants to change.) This graph has the correct numbers for this intent; but makes long-term trends harder to see because we only introduced the use counter *during* the deprecation period.

- So basically, usage has dropped form ~0.5% of page views (DocumentDomainEnabledCrossOriginAccess @ Nov '21) to about ~0.25% of page views (CrossOriginAccessBasedOnDocumentDomain @ Sept '22)

When gathering the data for this post, I double-checked on a particular, well-known media site that we had contacted about the deprecation during the past months. I was surprised to notice that despite our outreach and communication, they *still* use document.domain and document.domain facilitated cross-origin access. But when taking a closer look, an interesting find emerged: They are using document.domain setting to enable auto-play of their media player, which is hosted on a separate domain. Our advice was to use the 'autoplay' permission policy with permission delegation instead. They are indeed doing so, but *in addition* to document.domain setting. In other words, they opted for a conservative implementation strategy where they auto-play their frame with two different methods. When I load their page with document.domain setting disabled, it works fine. That's a fine implementation strategy, but unfortunately it mucks up our statistics since our use counters cannot know whether other code exists to compensate for a failed document.domain facilitated access.

When discussing this finding with another engineer, he suggested that we're really interested in user-visible web breakage. Since I don't know how to measure that directly, I manually looked at all top users of document.domain and loaded each page with/without document.domain setting to see if I could spot any difference. Document.domain usage - like the web in general - is quite "top heavy": 9 sites account for about 50% of all remaining dd usage.

- 7 sites work without any discernible difference. (Caveat: Many use languages I do not understand, which makes it difficult to spot subtle differences in content. But to me, the sites looked and used the same, regardless of document.domain setting. Caveat 2: One site requires a login, so I could only really test the login page rather than their core functionality.)

- 1 site worked just the same, except for a pair of very extra fancy ad frames that "framed" the main content left and right. The main content, including in-page ads, seemed just fine, but the fancy ad frames were missing.

- 1 site was clearly missing content.

For both of the last two, the console showed uncaught DOM exceptions for a failed cross-domain access. What I suspect happens in the first case is that during construction of the fancy ad frames an exception is thrown and hence the frames aren't inserted in the page. In the second case something similar happens, but when building up the main content. Or maybe before building up the main content. Thus, that part of the main content is missing.

(We don't like broken web pages, so we reached out separately to the owners of that last page on Friday. Their support has promised to put us in contact with one of their developers which, as of this writing, hasn't happened yet.)

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.

[Yoav Weiss‏]

Thanks for the detailed report!!

It's great that we've managed to bring the usage down, but 0.25% is still too high for my comfort levels.

Taking a manual survey of the major users seems like the right approach. I wonder if you could, on top of the top sites, also run a random survey of the bottom half of usage, to get a sense of breakage there?

[Daniel Vogelheim‏]

On Wed, Oct 19, 2022 at 5:23 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for the detailed report!!

It's great that we've managed to bring the usage down, but 0.25% is still too high for my comfort levels.

Taking a manual survey of the major users seems like the right approach. I wonder if you could, on top of the top sites, also run a random survey of the bottom half of usage, to get a sense of breakage there?

The long tail is long. :)  Chromestatus offers a "Sample URLs" table for each feature, so I took the top 50 sample URLs for CrossOriginAccessBasedOnDocumentDomain [1] and examined them manually, with & without Origin-Agent-Cluster on by default.

- 47 sites worked without any obvious problems. I usually examined the main site and one page linked from the main site.

- 3 sites did not. Interestingly, one of them was another country domain of the site I reported on in the "top 9" cases; and the other two were different country domains of the same site. I guess one can now argue whether I found 3 or only 2 sites that break. [2]

- If I assume Chromestatus URL sampling is vaguely proportional to page views, then: 0.25% page views use the feature, 3 / 50 with visible issues => 0.015% potential of problem page views.

[1] I'm not sure what their sampling method is; and in particular whether it's stable and everyone gets the same list, or whether the random sample is random every time. If it's relevant, I can provide the list of URLs I used.

[2] I'm not sure if listing the sites publicly is desired, or even permissible. One is a commercial site focused on sports results; the other a non-commercial site focused on onscreen keyboards for different languages.

[Yoav Weiss‏]

Thanks for doing that work, Daniel!

0.015% effective breakage is way better than 0.25%, but it's still ~5x higher than what we're typically comfortable with.

I'm wondering if folks have creative ideas on the outreach front - +Andre Bandarra in particular

Otherwise, maybe it makes sense to finch this at 50% on Beta, Dev and Canary channels, to convince folks this is indeed coming?

[Thomas Steiner‏]

Here's a RegEx power search where document.domain is being set, finding ~3.6k files on GitHub: https://cs.github.com/?scopeName=All+repos&scope=&q=%2F%5Cbdocument%5C.domain%5Cs*%3D%5B%5E%3D%5D%5Cs*%2F+%28language%3Ajavascript+OR+language%3Atypescript%29 

--

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/CAL5BFfWK0vqSWrRsW_Fr_iW-1omFMsWSvExYwskLMd%2B1y%3DGnLw%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.com, https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.3.4 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/

----- END PGP SIGNATURE -----

[Daniel Vogelheim‏]

On Wed, Oct 26, 2022 at 3:09 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for doing that work, Daniel!

0.015% effective breakage is way better than 0.25%, but it's still ~5x higher than what we're typically comfortable with.

I'm wondering if folks have creative ideas on the outreach front - +Andre Bandarra in particular

Otherwise, maybe it makes sense to finch this at 50% on Beta, Dev and Canary channels, to convince folks this is indeed coming?

I think that makes sense. I'll send a separate intent - as requested earlier - so that it has due visibility.

[Daniel Vogelheim‏]

Thanks. The link just leads me to an info page about Github code search. But regardless:

The difficulty with this particular feature is that the "API" has two parts: First, setting document.domain (possibly on main page and frame), and then later making a cross-origin access that will succeed because of this, somewhere else. The setting document.domain part has a specific pattern, but the later usage doesn't. What we figured out the hard way is that many sites do the first thing, but then don't do the second. Maybe as a left-over from no longer used functionality. Or they do the second part, but use it only for something optional on the page, so that disabling it won't actually affect the user experience. This makes potential breakage very hard to measure, since the measurable things - e.g. is document.domain being modified? - don't really correspond to user-visible impact.

That makes the 3.6k number difficult to interpret: In order to make sense of this number, I'd need some indicator of the denominator (that is, 3.6k of how many in total?), and some indicator of the "breakage ratio" (that is, likelihood of a site failing when setting document.domain no longer does anything?).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrL%3D7ipLDsJmxP8Dja_FKY5ojYkoND6uQESL1m5o8V3MbuA%40mail.gmail.com.

[Thomas Steiner‏]

On Thu, Oct 27, 2022 at 1:43 PM Daniel Vogelheim <voge...@google.com> wrote:

Thanks. The link just leads me to an info page about Github code search. But regardless:

Ah, duh. Looks like GitHub Search is still in developer preview and not rolled out to everyone. I can't really export the result, but here are some of the affected repos (emphasis mine, this is Firebase):

‎cypress-io/cypress‎

‎sockjs/sockjs-client‎

‎odoo/odoo‎

‎sparrow-js/sparrow‎

‎react-component/upload‎

‎kindsoft/kindeditor‎

‎barretlee/online-markdown‎

‎RocketChat/Rocket.Chat‎

‎bbc/simorgh‎

‎RubyLouvre/mass-Framework‎

‎firebase/firebase-js-sdk‎

‎primus/primus‎

‎AlloyTeam/JX‎

‎jasonday/printThis‎

‎notadd/neditor

 

The difficulty with this particular feature is that the "API" has two parts: First, setting document.domain (possibly on main page and frame), and then later making a cross-origin access that will succeed because of this, somewhere else. The setting document.domain part has a specific pattern, but the later usage doesn't. What we figured out the hard way is that many sites do the first thing, but then don't do the second. Maybe as a left-over from no longer used functionality. Or they do the second part, but use it only for something optional on the page, so that disabling it won't actually affect the user experience. This makes potential breakage very hard to measure, since the measurable things - e.g. is document.domain being modified? - don't really correspond to user-visible impact.

Yeah, makes sense. 

 

That makes the 3.6k number difficult to interpret: In order to make sense of this number, I'd need some indicator of the denominator (that is, 3.6k of how many in total?), and some indicator of the "breakage ratio" (that is, likelihood of a site failing when setting document.domain no longer does anything?).

Unfortunately they don't tell the size of their corpus. "All of GitHub", whatever this may mean.