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?