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 On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote: > On 12/16/21 5:52 PM, Charlie Reis wrote: > > > > On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev < > blink-dev@chromium.org> wrote: > >> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor <miketa...@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% >>> <https://chromestatus.com/metrics/feature/timeline/popularity/2544> of >>> page views rely upon document.domain to enable some cross-origin access >>> that wasn't otherwise possible. 0.24% >>> <https://chromestatus.com/metrics/feature/timeline/popularity/2543> of >>> page views block same-origin access because only one side sets >>> document.domain. Both counters can be found on >>> https://deprecate.it/#document-domain, too. >>> >>> (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. >> > > 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.) > > 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. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/399c45e6-989a-41e8-a1a3-4cd002a18977n%40chromium.org.
