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.

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.

/Daniel

On 2021-12-14 15:06, Daniel Vogelheim wrote:


        Contact emails


        *

        v...@chromium.org <mailto:v...@chromium.org>,
        vogelh...@chromium.org


        *


        Specification


        *

        Explainer:
        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 onhttps://deprecate.it/#document-domain <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?
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 <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 <http://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


        *


        Launch bug


        *

        https://crbug.com/1246823 <https://crbug.com/1246823>


        *


        Link to entry on the Chrome Platform Status


        https://chromestatus.com/feature/5428079583297536
        <https://chromestatus.com/feature/5428079583297536>(document.domain
        setter deprecation)

        https://chromestatus.com/features/5683766104162304
        <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 blink-dev+unsubscr...@chromium.org. 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 blink-dev+unsubscr...@chromium.org. 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 blink-dev+unsubscr...@chromium.org.
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.

Reply via email to