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 On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan <[email protected]> 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. > > 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/CAH%2B8MBYQnW00sQ4tMJh28JpQBTmWPshAai-VTdwMLGtbENDe9Q%40mail.gmail.com.
