> 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. On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss <[email protected]> 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. > - 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 < >> [email protected]> wrote: >> >>> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor <[email protected]> >>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFKd2qXjZWrGgCAPzV0ck74SLPM5vLNb0y-mx772OdQ%2B-zGEaA%40mail.gmail.com.
