On Thu, Oct 27, 2022 at 1:43 PM Daniel Vogelheim <vogelh...@google.com> wrote:
> Thanks. The link just leads me to an info page about Github code search. > But regardless: > Ah, duh. Looks like GitHub Search is still in developer preview and not rolled out to everyone. I can't really export the result, but here are some of the affected repos (emphasis mine, this is Firebase): cypress-io/cypress sockjs/sockjs-client odoo/odoo sparrow-js/sparrow react-component/upload kindsoft/kindeditor barretlee/online-markdown RocketChat/Rocket.Chat bbc/simorgh RubyLouvre/mass-Framework *firebase/firebase-js-sdk* primus/primus AlloyTeam/JX jasonday/printThis notadd/neditor > The difficulty with this particular feature is that the "API" has two > parts: First, setting document.domain (possibly on main page and frame), > and then later making a cross-origin access that will succeed because of > this, somewhere else. The setting document.domain part has a specific > pattern, but the later usage doesn't. What we figured out the hard way is > that many sites do the first thing, but then don't do the second. Maybe as > a left-over from no longer used functionality. Or they do the second part, > but use it only for something optional on the page, so that disabling it > won't actually affect the user experience. This makes potential breakage > very hard to measure, since the measurable things - e.g. is document.domain > being modified? - don't really correspond to user-visible impact. > Yeah, makes sense. > That makes the 3.6k number difficult to interpret: In order to make sense > of this number, I'd need some indicator of the denominator (that is, 3.6k > of how many in total?), and some indicator of the "breakage ratio" (that > is, likelihood of a site failing when setting document.domain no longer > does anything?). > Unfortunately they don't tell the size of their corpus. "All of GitHub", whatever this may mean. > On Wed, Oct 26, 2022 at 3:23 PM 'Thomas Steiner' via blink-dev < > blink-dev@chromium.org> wrote: > >> Here's a RegEx power search where document.domain is being set, finding >> ~3.6k files on GitHub: >> https://cs.github.com/?scopeName=All+repos&scope=&q=%2F%5Cbdocument%5C.domain%5Cs*%3D%5B%5E%3D%5D%5Cs*%2F+%28language%3Ajavascript+OR+language%3Atypescript%29 >> >> >> On Wed, Oct 26, 2022 at 3:09 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> Thanks for doing that work, Daniel! >>> >>> 0.015% effective breakage is way better than 0.25%, but it's still ~5x >>> higher than what we're typically comfortable with. >>> I'm wondering if folks have creative ideas on the outreach front - +Andre >>> Bandarra <andre...@google.com> in particular >>> >>> Otherwise, maybe it makes sense to finch this at 50% on Beta, Dev and >>> Canary channels, to convince folks this is indeed coming? >>> >>> On Fri, Oct 21, 2022 at 1:40 PM Daniel Vogelheim <vogelh...@google.com> >>> wrote: >>> >>>> On Wed, Oct 19, 2022 at 5:23 AM Yoav Weiss <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> Thanks for the detailed report!! >>>>> >>>>> It's great that we've managed to bring the usage down, but 0.25% is >>>>> still too high for my comfort levels. >>>>> Taking a manual survey of the major users seems like the right >>>>> approach. I wonder if you could, on top of the top sites, also run a >>>>> random >>>>> survey of the bottom half of usage, to get a sense of breakage there? >>>>> >>>> >>>> The long tail is long. :) Chromestatus offers a "Sample URLs" table >>>> for each feature, so I took the top 50 sample URLs for >>>> CrossOriginAccessBasedOnDocumentDomain >>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4171> >>>> [1] and examined them manually, with & without Origin-Agent-Cluster on by >>>> default. >>>> >>>> - 47 sites worked without any obvious problems. I usually examined the >>>> main site and one page linked from the main site. >>>> - 3 sites did not. Interestingly, one of them was another country >>>> domain of the site I reported on in the "top 9" cases; and the other two >>>> were different country domains of the same site. I guess one can now argue >>>> whether I found 3 or only 2 sites that break. [2] >>>> - If I assume Chromestatus URL sampling is vaguely proportional to page >>>> views, then: 0.25% page views use the feature, 3 / 50 with visible issues >>>> => 0.015% potential of problem page views. >>>> >>>> >>>> [1] I'm not sure what their sampling method is; and in particular >>>> whether it's stable and everyone gets the same list, or whether the random >>>> sample is random every time. If it's relevant, I can provide the list of >>>> URLs I used. >>>> [2] I'm not sure if listing the sites publicly is desired, or even >>>> permissible. One is a commercial site focused on sports results; the other >>>> a non-commercial site focused on onscreen keyboards for different >>>> languages. >>>> >>>> >>>>> On Mon, Oct 17, 2022 at 4:39 PM Daniel Vogelheim <vogelh...@google.com> >>>>> wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> It's been a while and 109 is coming up. As I'm preparing the >>>>>> intent-to-ship for 109, I'd like to post an update on how the deprecation >>>>>> is going: >>>>>> >>>>>> Current usage: Since announcing the deprecation, usage of >>>>>> document.domain-enabled accesses have dropped by about 50%. >>>>>> >>>>>> - Feature stats: DocumentDomainEnabledCrossOriginAccess >>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/2544> >>>>>> >>>>>> - Note that this *includes* usage when an Origin-Agent-Cluster header >>>>>> is explicitly set, which is sustainable use that is not affected by the >>>>>> deprecation. >>>>>> >>>>>> - CrossOriginAccessBasedOnDocumentDomain >>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4171> >>>>>> is usage of document.domain enabled access, but only when based on the >>>>>> Origin-Agent-Cluster's default (which is what this intent wants to >>>>>> change.) >>>>>> This graph has the correct numbers for this intent; but makes long-term >>>>>> trends harder to see because we only introduced the use counter *during* >>>>>> the deprecation period. >>>>>> >>>>>> - So basically, usage has dropped form ~0.5% of page views ( >>>>>> DocumentDomainEnabledCrossOriginAccess >>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/2544> >>>>>> @ Nov '21) to about ~0.25% of page views ( >>>>>> CrossOriginAccessBasedOnDocumentDomain >>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4171> >>>>>> @ Sept '22) >>>>>> >>>>>> When gathering the data for this post, I double-checked on a >>>>>> particular, well-known media site that we had contacted about the >>>>>> deprecation during the past months. I was surprised to notice that >>>>>> despite >>>>>> our outreach and communication, they *still* use document.domain and >>>>>> document.domain facilitated cross-origin access. But when taking a closer >>>>>> look, an interesting find emerged: They are using document.domain setting >>>>>> to enable auto-play of their media player, which is hosted on a separate >>>>>> domain. Our advice was to use the 'autoplay' permission policy with >>>>>> permission delegation instead. They are indeed doing so, but *in >>>>>> addition* >>>>>> to document.domain setting. In other words, they opted for a conservative >>>>>> implementation strategy where they auto-play their frame with two >>>>>> different >>>>>> methods. When I load their page with document.domain setting disabled, it >>>>>> works fine. That's a fine implementation strategy, but unfortunately it >>>>>> mucks up our statistics since our use counters cannot know whether other >>>>>> code exists to compensate for a failed document.domain facilitated >>>>>> access. >>>>>> >>>>>> When discussing this finding with another engineer, he suggested that >>>>>> we're really interested in user-visible web breakage. Since I don't know >>>>>> how to measure that directly, I manually looked at all top users of >>>>>> document.domain and loaded each page with/without document.domain setting >>>>>> to see if I could spot any difference. Document.domain usage - like the >>>>>> web >>>>>> in general - is quite "top heavy": 9 sites account for about 50% of all >>>>>> remaining dd usage. >>>>>> >>>>>> - 7 sites work without any discernible difference. (Caveat: Many use >>>>>> languages I do not understand, which makes it difficult to spot subtle >>>>>> differences in content. But to me, the sites looked and used the same, >>>>>> regardless of document.domain setting. Caveat 2: One site requires a >>>>>> login, >>>>>> so I could only really test the login page rather than their core >>>>>> functionality.) >>>>>> >>>>>> - 1 site worked just the same, except for a pair of very extra fancy >>>>>> ad frames that "framed" the main content left and right. The main >>>>>> content, >>>>>> including in-page ads, seemed just fine, but the fancy ad frames were >>>>>> missing. >>>>>> >>>>>> - 1 site was clearly missing content. >>>>>> >>>>>> For both of the last two, the console showed uncaught DOM exceptions >>>>>> for a failed cross-domain access. What I suspect happens in the first >>>>>> case >>>>>> is that during construction of the fancy ad frames an exception is thrown >>>>>> and hence the frames aren't inserted in the page. In the second case >>>>>> something similar happens, but when building up the main content. Or >>>>>> maybe >>>>>> before building up the main content. Thus, that part of the main content >>>>>> is >>>>>> missing. >>>>>> >>>>>> (We don't like broken web pages, so we reached out separately to the >>>>>> owners of that last page on Friday. Their support has promised to put us >>>>>> in >>>>>> contact with one of their developers which, as of this writing, hasn't >>>>>> happened yet.) >>>>>> >>>>>> >>>>>> 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. >>>>>>> >>>>>>> -- >>> 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/CAL5BFfWK0vqSWrRsW_Fr_iW-1omFMsWSvExYwskLMd%2B1y%3DGnLw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWK0vqSWrRsW_Fr_iW-1omFMsWSvExYwskLMd%2B1y%3DGnLw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Thomas Steiner, PhD—Developer Relations Engineer ( >> https://blog.tomayac.com, https://twitter.com/tomayac) >> >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany >> Geschäftsführer: Paul Manicle, Liana Sebastian >> Registergericht und -nummer: Hamburg, HRB 86891 >> >> ----- BEGIN PGP SIGNATURE ----- >> Version: GnuPG v2.3.4 (GNU/Linux) >> >> >> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. >> hTtPs://xKcd.cOm/1181/ >> ----- END PGP SIGNATURE ----- >> >> -- >> 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/CALgRrL%3D7ipLDsJmxP8Dja_FKY5ojYkoND6uQESL1m5o8V3MbuA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrL%3D7ipLDsJmxP8Dja_FKY5ojYkoND6uQESL1m5o8V3MbuA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.com, https://twitter.com/tomayac) Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 ----- BEGIN PGP SIGNATURE ----- Version: GnuPG v2.3.4 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. hTtPs://xKcd.cOm/1181/ ----- END PGP SIGNATURE ----- -- 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/CALgRrLnZ3TT0TzDuwOT%3Dqw%3D3Sq%2Bnri_6y-ioj%2BrbXFspoD73Cw%40mail.gmail.com.
