On Thu, Jan 20, 2022 at 11:11 AM Noah Lemen <noah.le...@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 <vogelh...@google.com> do you think it's feasible? > > On Tuesday, January 18, 2022 at 12:41:22 PM UTC-5 T K wrote: > >> 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 >> >> On Friday, January 14, 2022 at 8:06:58 PM UTC+2 sligh...@chromium.org >> wrote: >> >>> 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. >>> >>> On Friday, January 14, 2022 at 5:17:25 AM UTC-8 Daniel Vogelheim wrote: >>> >>>> 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. >>>> >>>> >>>>> ~Greg >>>>> >>>>> On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote: >>>>> >>>>>> 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 <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. >>>>>>> >>>>>>> On Wed, Jan 12, 2022 at 12: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. >>>>>>>> - 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 < >>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> 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% >>>>>>>>>>> <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/e5950c17-044a-45f4-b248-8246b16f9480n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e5950c17-044a-45f4-b248-8246b16f9480n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw_6559qqczSF1Gr2OgZSUYufZ7ZK_FKFUioRky6ov752A%40mail.gmail.com.
