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? > I believe the intent is asking to add those as part of the deprecation period, but that hasn't happened yet. > > I'll follow up on what I find and that will influence my opinion on > removal timeline. > > ~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/CAL5BFfWMo0OE91hFj9EpaEwyGcfu7uCXYE9MToRiWnN-HGRpMQ%40mail.gmail.com.
