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 <gregcwhitwo...@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/bd2f5a7b-a64c-4aa5-aa65-36e6f39fd7e8n%40chromium.org.
