On Fri, Jan 21, 2022 at 9:23 PM Yoav Weiss <yoavwe...@chromium.org> wrote:
> 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. > > Thanks, will do. > 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/CALG6KPOQKyPfvX%3DSpCubkXqqP%3DUb4-59V2OyZS3hh1Y1z42y-A%40mail.gmail.com.
