LGTM1 to deprecate under the following conditions: - As discussed, a 6 months deprecation period, as well as broad-scope and targeted outreach, that would hopefully bring usage down. - A well-crafted deprecation message that indicates the timeline, and at the same time indicates that we'll be responsive to community feedback (or a link to a blog post/documentation page that indicates the same) - Sending a separate intent for the actual removal at the end of the deprecation period, once the picture is a bit clearer.
On Fri, Jan 14, 2022 at 7:07 PM Alex Russell <slightly...@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 <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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bd2f5a7b-a64c-4aa5-aa65-36e6f39fd7e8n%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/CAL5BFfV9QYzcFoxNvV%2BaNS7p603s45F%2BqZ2z%3D6c0%3DHYPLmMeiw%40mail.gmail.com.
