On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor <[email protected]> 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. > https://github.com/WICG/origin-agent-cluster#no-op-documentdomain-setter-instead-of-throwing suggests you're right. Also - TIL https://developer.mozilla.org/en-US/docs/Glossary/Expando > There is also the question of reverse origin trial and enterprise flags. > If Origin-Agent-Cluster can be set with <meta http-equiv="....">, then I > don't see any use for an origin trial since that would be activated the > same way. An enterprise flag might still be needed though, since that > covers installations where the client can be configured, but applications > can not be changed. > > I'd be surprised if meta http-equiv is supported, as IIUC, the decision on an agent cluster needs to be made before the document is committed, hence the opt-in can't be made available to markup. I'm guessing the same would be true for a deprecation trial (as a result, there's no difference between one and the header based opt-in). > /Daniel > On 2021-12-14 15:06, Daniel Vogelheim wrote: > > Contact emails > > > * [email protected] <[email protected]>, [email protected] > <[email protected]> * Specification > > > * Explainer: https://github.com/mikewest/deprecating-document-domain > <https://github.com/mikewest/deprecating-document-domain> HTML Spec draft: > https://github.com/whatwg/html/compare/main...otherdaniel:dd > <https://github.com/whatwg/html/compare/main...otherdaniel:dd> * API spec > > > * Yes * Summary > > > > > > > > * Change the default behavior of the Origin-Agent-Cluster: header / > document.domain settability. Presently, pages within Chromium have > site-keyed agent clusters by default, unless the Origin-Agent-Cluster: > header is explicitly set to true. This accommodates pages or frames which > want to access each other's state, despite being on different origins (but > within a site). This is fine for any pages that wish to do so, but because > a page *might* set document.domain later on, Chromium currently must use > site-keyed agent clusters for *all* pages by default even though the > overwhelming majority of pages do not ever make use of this (mis-)feature. > In turn, this requires Chromium to use sites as the basis for renderer > process isolation (via Site Isolation), which exposes origins to same-site > but cross-origin attacks involving compromised renderer processes or the > "Spectre" family of side-channel attacks. This proposal changes the default > behaviour of Origin-Agent-Cluster. From a developer's point of view, the > new default matches "Origin-Agent-Cluster: ?1". The initial implementation > will use origin-keyed agent clusters for all (non-opted out) origins, > without changing how many processes Chromium creates. Over time, we can > then adapt Chromium's isolation strategy towards origin-keyed processes > without further affecting web-visible behaviour. The developer-visible > aspect of this is that for pages with origin-keyed agent clusters, > document.domain is no longer settable. Thus, we have marked this intent as > a deprecation. Note that this proposal is about the default. Both modes - > site-keyed or origin-keyed agent clusters - remain available to any site, > but origin-keyed agent clusters change from opt-in to opt-out. The current > behaviour remains available by setting "Origin-Agent-Cluster: ?0". * Blink > component > > > * Blink>SecurityFeature * TAG review > > > * https://github.com/w3ctag/design-reviews/issues/564 > <https://github.com/w3ctag/design-reviews/issues/564> (The thread is a bit > unwieldy, but there do not seem to be open issues.) * 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. > > 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? > Also, what would be the (estimated) usage if those 4 top users would move away from relying on document.domain? > Gecko: Standards position request > <https://github.com/mozilla/standards-positions/issues/601>. > (Provisionally "worth prototyping", but is open for additional > comments/opinions. Mozilla representatives also participated in the TAG > discussion. No concrete implementation plans were given. > WebKit: > https://lists.webkit.org/pipermail/webkit-dev/2021-December/032067.html > (No signals.) > Web developers: No signals. > 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)? > > * 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? > > * Security This change should be security-positive, since setting the > document.domain will not have any impact on the origin of the document any > more. * > Debuggability > > > * A deprecation warning will be added to DevTools console and to the > issues panel in M98, which will support current users to adopt. This > warning will file a deprecation report as well using the Reporting API, if > so configured. * Will this feature be supported on all six Blink > platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? > > > * Yes * Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ? > > > * Are in place to test the current functionality > <https://wpt.live/html/browsers/origin/origin-keyed-agent-clusters/>, and > will be adjusted within the M101 timeframe to ensure the feature is working > as intended. * Tracking bug > > > * https://crbug.com/1139851 <https://crbug.com/1139851> * Launch bug > > > * https://crbug.com/1246823 <https://crbug.com/1246823> * Link to entry > on the Chrome Platform Status > > https://chromestatus.com/feature/5428079583297536 (document.domain setter > deprecation) > https://chromestatus.com/features/5683766104162304 (Origin-keyed agent > clusters) > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOmpEUx5xST3QHRHdU9yPbA4ucMYQB4dMQcHys9KNRsrg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOmpEUx5xST3QHRHdU9yPbA4ucMYQB4dMQcHys9KNRsrg%40mail.gmail.com?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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/315e3206-021c-4fc0-728b-36b0a01811d6%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/315e3206-021c-4fc0-728b-36b0a01811d6%40gmail.com?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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7f103c3d-96c4-1b6d-7f4f-4634be86d030%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7f103c3d-96c4-1b6d-7f4f-4634be86d030%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU7o4w4eQNU8%3D3smSoPAA%2BjRGV%2Bry5JzC%3DxbPbC-X%2B-hg%40mail.gmail.com.
