To clarify, rejecting the header *is* interpreting it properly. It's not that duplicates aren't allowed, it's that there is no such thing as a duplicate header in HTTP. Specifying two headers with the same name is *not* a no-op. Rather, sending two headers with the same name is simply another syntax for sending one header with the contents concatenated by comma. (With the exception of the Set-Cookie header, which is processed a bit strangely.) This is a holdover from the days when people cared about text protocols being typable via netcat.
So, by sending: Origin-Agent-Cluster: ?0 Origin-Agent-Cluster: ?0 You are really sending: Origin-Agent-Cluster: ?0, ?0 "?0, ?0" is not a valid Origin-Agent-Cluster, thus it is rejected. A DevTools warning for headers we could not parse would indeed be good, but rejecting it is correct. On Sun, Oct 29, 2023 at 12:39 PM Madanagopal Damodharan < dmadanago...@gmail.com> wrote: > Thanks all. https://crbug.com/1478065 is exactly the issue some of our > customers encountered. But unfortunately it didn't give any clue to debug > why chrome did not obey the header even if its indeed present though more > than once. Hence, it will be helpful to add some warnings or something to > indicate on DevTools console why chrome could not interpret the header > properly. > > On Thu, Oct 12, 2023 at 10:39 PM W. James MacLean <wjmacl...@google.com> > wrote: > >> Thanks creis@ ... I learned something new today! >> >> [image: GoogleAnimated.gif] >> >> ⭘ W. James MacLean >> >> ⭘ Software Engineer >> >> ⭘ Google Waterloo >> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, >> Canada >> >> >> >> On Thu, 12 Oct 2023 at 12:51, Charlie Reis <cr...@google.com> wrote: >> >>> Actually, I think that's not quite true-- there was a recent report >>> about duplicate headers in https://crbug.com/1478065, and it turns out >>> to be required by spec to not allow duplicates. (See comment 13 >>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1478065#c13> on >>> that bug.) I think it will be necessary to only return one copy of the >>> header, and there's a bug filed <https://crbug.com/1484583> to have >>> DevTools display a warning in that case. >>> >>> Charlie >>> >>> >>> On Thu, Oct 12, 2023 at 9:30 AM 'W. James MacLean' via blink-dev < >>> blink-dev@chromium.org> wrote: >>> >>>> While it would obviously be better for the header to only be sent once >>>> (less bytes transmitted), I don't think sending it twice should cause a >>>> problem so long as both headers are the same, e.g. they both specify "?0". >>>> If you're seeing the problem with two headers but not with one, then that's >>>> a bug. In that case filing a bug report at crbug.com, including as >>>> much information as possible, would be appreciated. >>>> >>>> I tried this with a simple test case on my own server, and it seems to >>>> work fine. >>>> >>>> [image: GoogleAnimated.gif] >>>> >>>> ⭘ W. James MacLean >>>> >>>> ⭘ Software Engineer >>>> >>>> ⭘ Google Waterloo >>>> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, >>>> Canada >>>> >>>> >>>> >>>> On Fri, 6 Oct 2023 at 01:41, Madanagopal Damodharan < >>>> dmadanago...@gmail.com> wrote: >>>> >>>>> Thanks James. We are able to add the header from our server's servlet >>>>> filter code. It now appends the header for each response including static >>>>> html files. It seems to be working fine so far. There are instances where >>>>> it still gets blocked when a link is opened on new window. I believe we >>>>> need to make sure the new window response contains the header as well, >>>>> right? Also, if the header gets duplicated i.e. if the response contains >>>>> the same header twice, it does not work. It looks as if the header is not >>>>> sent at all. Is this how it is supposed to behave? >>>>> >>>>> On Monday, 25 September 2023 at 20:23:51 UTC+5:30 W. James MacLean >>>>> wrote: >>>>> >>>>>> No, I think you need to get the server to send the header. Once you >>>>>> get as far as the meta tags, the origin's isolation state has already >>>>>> been >>>>>> decided. I'm not an expert on servers, but my experience in specifying >>>>>> headers to be sent with static pages is to edit the .htaccess file in the >>>>>> directory with the content, and include >>>>>> >>>>>> HEADER add Origin-Agent-Cluster: ?0 >>>>>> >>>>>> But the exact details will depend on your setup. >>>>>> >>>>>> For Apache: https://httpd.apache.org/docs/2.4/howto/htaccess.html >>>>>> >>>>>> [image: GoogleAnimated.gif] >>>>>> >>>>>> ⭘ W. James MacLean >>>>>> >>>>>> ⭘ Software Engineer >>>>>> >>>>>> ⭘ Google Waterloo >>>>>> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, >>>>>> Canada >>>>>> >>>>>> On Tue, 19 Sept 2023 at 23:40, Madanagopal Damodharan < >>>>>> dmadan...@gmail.com> wrote: >>>>>> >>>>>>> This helped us identify the response that did not have the header. >>>>>>> We noticed that we have a static html called signon.html as our first >>>>>>> entry >>>>>>> into the application. Since this is a static html, our servlet changes >>>>>>> to >>>>>>> add response header does not hit when users invoke this signon.html. I >>>>>>> think Chrome puts this origin into Origin-keyed cluster at this point >>>>>>> and >>>>>>> hence when users login and encounter document.domain, they get the error >>>>>>> blocked frame error. >>>>>>> >>>>>>> meta tags with http-equiv does not recognize this custom response >>>>>>> header Origin-Agent-Cluster. Is there a way to add response headers in a >>>>>>> static html page response? >>>>>>> >>>>>>> On Wednesday, 13 September 2023 at 22:49:00 UTC+5:30 W. James >>>>>>> MacLean wrote: >>>>>>> >>>>>>>> Perhaps try this: >>>>>>>> 1) open a new tab page (or about:blank if you prefer) >>>>>>>> 2) right-click and select "Inspect" at the bottom of the popup menu >>>>>>>> 3) in the DevTools menu at the top, click "Network" >>>>>>>> 4) then check the "Preserve Logs" checkbox in the row under that >>>>>>>> menu >>>>>>>> 5) finally, manually type the url for your app/site in the url bar >>>>>>>> >>>>>>>> As your content loads, the DevTools window will populate with an >>>>>>>> (in order) list of all the network transactions. You can click on each >>>>>>>> element in the list and see the response headers for each request. This >>>>>>>> should help you determine which request is missing the >>>>>>>> Origin-Agent-Cluster:?0 header and causing the origin keying to be >>>>>>>> applied >>>>>>>> for the tab. >>>>>>>> >>>>>>>> Let me know if that helps. >>>>>>>> >>>>>>>> >>>>>>>> [image: GoogleAnimated.gif] >>>>>>>> >>>>>>>> ⭘ W. James MacLean >>>>>>>> >>>>>>>> ⭘ Software Engineer >>>>>>>> >>>>>>>> ⭘ Google Waterloo >>>>>>>> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, >>>>>>>> Canada >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, 13 Sept 2023 at 12:44, Madanagopal Damodharan < >>>>>>>> dmadan...@gmail.com> wrote: >>>>>>>> >>>>>>>>> An update on the issue I am facing: We have a static html in web >>>>>>>>> server called signon.html. Users access this static html page first >>>>>>>>> which >>>>>>>>> has a refresh directive with content=1. As soon as the user invokes >>>>>>>>> this >>>>>>>>> html page first time from the origin, this redirects to a login form >>>>>>>>> page. >>>>>>>>> This response contains the header too. But still chrome console says >>>>>>>>> the >>>>>>>>> origin was in origin-keyed cluster. If I change the refresh directive >>>>>>>>> content=5, it takes 5 sec to redirect from signon.html to login form, >>>>>>>>> this >>>>>>>>> time I don't get the console warning. Now I can login and dont see any >>>>>>>>> errors. I am not sure why the refresh directive 5 works but not 1. Is >>>>>>>>> it >>>>>>>>> because Chrome could not capture request and place the origin in >>>>>>>>> appropriate cluster within its 1 second? >>>>>>>>> >>>>>>>>> Modified the CONTENT=5 from CONTENT=1 in the below line to get it >>>>>>>>> working - <meta HTTP-EQUIV='Refresh' CONTENT='5; >>>>>>>>> URL=../psp/ps/?cmd=login'> >>>>>>>>> >>>>>>>>> Any thoughts? >>>>>>>>> >>>>>>>>> On Sunday, 10 September 2023 at 20:53:42 UTC+5:30 Madanagopal >>>>>>>>> Damodharan wrote: >>>>>>>>> >>>>>>>>> Thanks for response. In my case, I am getting the error when a new >>>>>>>>> tab is opened from an existing tab. My existing tab did not throw this >>>>>>>>> error whereas the new tab shows the error on the first request >>>>>>>>> itself. So >>>>>>>>> based on what you mentioned, my parent tab should have been part of >>>>>>>>> Origin-Keyed cluster, right? I am seeing console warning as follows >>>>>>>>> on my >>>>>>>>> new tab that was opened from an existing tab: >>>>>>>>> >>>>>>>>> "The page did not request an Origin-Keyed agent cluster but was >>>>>>>>> put in one anyway because the origin had previously been placed in an >>>>>>>>> origin-keyed agent cluster. Update your headers to uniformly request >>>>>>>>> origin-keying for all pages on the origin" >>>>>>>>> >>>>>>>>> I am currently trying to figure out which server response did not >>>>>>>>> have the header ""Origin-Agent-Cluster: ?0" that led my pages to get >>>>>>>>> in >>>>>>>>> origin-keyed cluster. Is there a way (debug tool etc) I can check >>>>>>>>> which >>>>>>>>> response decided Origin-Keying? I think this will be crucial for >>>>>>>>> applications to debug the issues. >>>>>>>>> >>>>>>>>> One other question: My parent tab has a wss (web socket) request >>>>>>>>> that does not have its response with this OAC header. Do we need the >>>>>>>>> header >>>>>>>>> in wss response as well? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thursday, 7 September 2023 at 23:00:32 UTC+5:30 W. James >>>>>>>>> MacLean wrote: >>>>>>>>> >>>>>>>>> If the application is getting loaded inside a tab that has >>>>>>>>> previously loaded other pages from the same origin (i.e. pages not >>>>>>>>> part of >>>>>>>>> the app) that do not have the header, then for consistency the new >>>>>>>>> loads >>>>>>>>> will get OAC isolation even if the header is present. Essentially, the >>>>>>>>> first time the tab loads anything from a particular origin, that >>>>>>>>> determines >>>>>>>>> how it will treat the origin for the remainder of the tab's lifetime. >>>>>>>>> This >>>>>>>>> consistency will also extend to other tabs opened by the tab (as they >>>>>>>>> live >>>>>>>>> in the same "BrowsingInstance"). >>>>>>>>> >>>>>>>>> Also, there may be issues where pages can be loaded from cache >>>>>>>>> without the ?0 version of the header, so two useful steps would be >>>>>>>>> >>>>>>>>> 1) Clear the cache, and >>>>>>>>> 2) open the app directly in a newly opened tab. >>>>>>>>> >>>>>>>>> I don't think the header needs to be sent on script/css/image >>>>>>>>> requests, as they're used within the context of the .html resource >>>>>>>>> that >>>>>>>>> should have the header. >>>>>>>>> >>>>>>>>> [image: GoogleAnimated.gif] >>>>>>>>> >>>>>>>>> ⭘ W. James MacLean >>>>>>>>> >>>>>>>>> ⭘ Software Engineer >>>>>>>>> >>>>>>>>> ⭘ Google Waterloo >>>>>>>>> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, >>>>>>>>> Canada >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, 7 Sept 2023 at 11:27, Madanagopal Damodharan < >>>>>>>>> dmadan...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Is the feature launched in Chrome 115 as updated in >>>>>>>>> https://developer.chrome.com/blog/document-domain-setter-deprecation? >>>>>>>>> I have some of the customers reporting inconsistent behavior. Our >>>>>>>>> application sends "Origin-Agent-Cluster: ?0" in response headers >>>>>>>>> to opt-out of Origin Agent clusters since we rely on document.domain. >>>>>>>>> Is >>>>>>>>> this header needed only on document requests or even for script, >>>>>>>>> image, css >>>>>>>>> requests? For some customer, their pages get inside origin-keyed >>>>>>>>> cluster >>>>>>>>> even though the responses contain the header "Origin-Agent-Cluster: >>>>>>>>> ?0". Is there a bug in the chrome behavior that puts pages in specific >>>>>>>>> cluster? How do we debug what caused the pages to get inside >>>>>>>>> origin-keyed >>>>>>>>> cluster? >>>>>>>>> >>>>>>>>> On Friday, 26 May 2023 at 20:55:52 UTC+5:30 Eiji Kitamura wrote: >>>>>>>>> >>>>>>>>> @Maud Nalpas is taking over the DevRel work. >>>>>>>>> >>>>>>>>> On Sat, May 27, 2023 at 12:21 AM Rick Byers <rby...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Thanks for the update Daniel. Still LGTM. Good luck! >>>>>>>>> >>>>>>>>> On Fri, May 26, 2023 at 10:25 AM Daniel Vogelheim < >>>>>>>>> voge...@google.com> wrote: >>>>>>>>> >>>>>>>>> Hello all, it's been a while... The bug reports should now be >>>>>>>>> resolved, and we'd like to have another go at this in the M115 >>>>>>>>> milestone. >>>>>>>>> That is: Remain at 50% on beta; starting with 115 ramp up on stable >>>>>>>>> to 1% / >>>>>>>>> 10% / 50% / 100%, every 14d. Let's hope it sticks this time. >>>>>>>>> >>>>>>>>> Daniel >>>>>>>>> >>>>>>>>> On Fri, Mar 31, 2023 at 3:54 PM Daniel Vogelheim < >>>>>>>>> voge...@google.com> wrote: >>>>>>>>> >>>>>>>>> Hello all, I'm afraid I have to delay this a bit more. :( >>>>>>>>> >>>>>>>>> We have a bug report (tracked in crbug.com/1429587) that breaks >>>>>>>>> existing apps. The important thing here is that it does not break >>>>>>>>> document.domain setting and subsequent cross-origin access, but that >>>>>>>>> instead -- if the conditions are just right; or arguably just wrong >>>>>>>>> -- the >>>>>>>>> app can get into a state where same-origin accesses are mistakenly >>>>>>>>> blocked. >>>>>>>>> Apparently an app can get into a state where frames within the same >>>>>>>>> page >>>>>>>>> are inconsistently assigned to agent clusters (i.e., frames in the >>>>>>>>> same >>>>>>>>> origin end up in different processes), and thus subsequent accesses >>>>>>>>> within >>>>>>>>> that origin may fail. >>>>>>>>> >>>>>>>>> My plan right now is to leave this on at 50% beta, but to not >>>>>>>>> proceed to any stable releases at any percentage. I'll update this >>>>>>>>> thread >>>>>>>>> when I have a better handle on the bug and can suggest a good way to >>>>>>>>> proceed. >>>>>>>>> >>>>>>>>> On Fri, Jan 20, 2023 at 5:12 PM Eiji Kitamura <age...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> FYI, the enterprise bit has been added to the article. >>>>>>>>> https://developer.chrome.com/blog/immutable-document-domain/ >>>>>>>>> >>>>>>>>> On Tue, Jan 17, 2023 at 1:21 AM Brandon Heenan <bhe...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> We'll make the update in the enterprise release notes too. Thanks >>>>>>>>> for keeping us in the loop >>>>>>>>> >>>>>>>>> On Mon, Jan 16, 2023 at 9:46 AM Rick Byers <rby...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Thanks so much Eiji! >>>>>>>>> >>>>>>>>> On Mon, Jan 16, 2023 at 3:06 AM Eiji Kitamura <age...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I've updated the blog post >>>>>>>>> <https://developer.chrome.com/blog/immutable-document-domain/> stating >>>>>>>>> Chrome 111 is where we ship the feature, but looks like it's rolling >>>>>>>>> out >>>>>>>>> through 111 and 112? >>>>>>>>> I'll update the blog post to mention >>>>>>>>> `OriginAgentClusterDefaultEnabled` enterprise policy. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Jan 14, 2023 at 1:37 AM Rick Byers <rby...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Thanks for the update Daniel, good luck! >>>>>>>>> >>>>>>>>> In case others, like me, have missed or forgotten the long history >>>>>>>>> of this difficult deprecation and what it means for web developers, >>>>>>>>> this blog >>>>>>>>> post is a good summary >>>>>>>>> <https://developer.chrome.com/blog/immutable-document-domain/>. >>>>>>>>> One critical thing it doesn't mention, but probably should, is that >>>>>>>>> the OriginAgentClusterDefaultEnabled >>>>>>>>> enterprise policy >>>>>>>>> <https://chromeenterprise.google/policies/#OriginAgentClusterDefaultEnabled> >>>>>>>>> can also be used to revert the default on managed devices (though it >>>>>>>>> looks >>>>>>>>> like the launching milestone needs to be updated there too). >>>>>>>>> >>>>>>>>> Rick >>>>>>>>> >>>>>>>>> On Fri, Jan 13, 2023 at 9:53 AM 'Daniel Vogelheim' via blink-dev < >>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>> >>>>>>>>> Hello all, >>>>>>>>> >>>>>>>>> We've now handled the bugs we've discovered, and I would like to >>>>>>>>> make another attempt at launching. I'll follow the plan that was >>>>>>>>> approved >>>>>>>>> here, but two milestones later: Launch to 50% beta in M111 (or late >>>>>>>>> M110, >>>>>>>>> if I can still catch a bit of that release cycle), and then ramp on >>>>>>>>> stable >>>>>>>>> once M112 is out. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Dec 14, 2022 at 6:36 PM Daniel Vogelheim < >>>>>>>>> voge...@google.com> wrote: >>>>>>>>> >>>>>>>>> Hello all, >>>>>>>>> >>>>>>>>> An update: Unfortunately we have discovered a bug with this >>>>>>>>> feature, just as I was getting ready to enable it. The bug also >>>>>>>>> affects >>>>>>>>> pages that have not even set document.domain. Since I have now missed >>>>>>>>> a >>>>>>>>> substantial portion of the 109 beta cycle I'd like to delay the roll >>>>>>>>> out >>>>>>>>> once more, and shift it by one milestone (or two; depending on when >>>>>>>>> everything is fixed). >>>>>>>>> >>>>>>>>> On the positive side: Recently the last of the previously >>>>>>>>> identified big document.domain users, that together accounted for >>>>>>>>> about 50% >>>>>>>>> of remaining usage, has dropped their usage. So current usage is >>>>>>>>> lower than >>>>>>>>> previously reported. See the usage dip around late November at >>>>>>>>> deprecate.it (1st graph). >>>>>>>>> >>>>>>>>> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor <mike...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> LGTM3 >>>>>>>>> >>>>>>>>> On 11/10/22 11:18 AM, Chris Harrelson wrote: >>>>>>>>> >>>>>>>>> LGTM2 >>>>>>>>> >>>>>>>>> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss <yoav...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 >>>>>>>>> or M109, and carefully roll this out for M110, once it hits stable. >>>>>>>>> >>>>>>>>> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim < >>>>>>>>> voge...@google.com> wrote: >>>>>>>>> >>>>>>>>> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor <mike...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote: >>>>>>>>> >>>>>>>>> Hello all, >>>>>>>>> >>>>>>>>> The approval for the Intent To Ship for Origin Isolation By >>>>>>>>> Default / Deprecate document.domain >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/> >>>>>>>>> asks for a separate intent for the actual default change >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/m/Ybgtf3JfAQAJ>. >>>>>>>>> This is that separate intent. >>>>>>>>> >>>>>>>>> A summary of what happened so far: >>>>>>>>> >>>>>>>>> - Shipping Origin Isolation by Default (and thereby deprecating >>>>>>>>> document.domain) has security benefits, but compatibility risk. >>>>>>>>> >>>>>>>>> - We added warnings to the developer console and issues panel, >>>>>>>>> published a blog post, and engaged in direct outreach. This has >>>>>>>>> resulted in >>>>>>>>> substantial, measurable reduction of usage. Some sites keep using >>>>>>>>> document.domain, but have mitigated the deprecation with other means. >>>>>>>>> This >>>>>>>>> makes the risk difficult to measure. >>>>>>>>> >>>>>>>>> - Sampling of sites with document.domain usage and manual >>>>>>>>> inspection yields a potential breakage estimate at ~0.015% of page >>>>>>>>> views. >>>>>>>>> >>>>>>>>> What we're asking for here is: >>>>>>>>> >>>>>>>>> - Enable the feature at 50% for beta (+ dev + canary) during M109, >>>>>>>>> as a "last call" for web site authors. >>>>>>>>> >>>>>>>>> This sounds like a good idea. Is there any reason we couldn't go >>>>>>>>> to 50% in M108 as well (or are you trying to avoid breakage over the >>>>>>>>> winter >>>>>>>>> holidays)? >>>>>>>>> >>>>>>>>> No reason. I'd be happy to go to beta as soon as I receive the >>>>>>>>> lgtms. I had conservatively budgeted that to be 109. :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> Another question: do we have enterprise policies available for >>>>>>>>> this change? >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes; the policy is here: OriginAgentClusterDefaultEnabled >>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/policy/resources/templates/policy_definitions/Miscellaneous/OriginAgentClusterDefaultEnabled.yaml> >>>>>>>>> >>>>>>>>> >>>>>>>>> - Launch on stable on M110. (~ Feb '23, so >12 weeks out from >>>>>>>>> today) >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------ >>>>>>>>> >>>>>>>>> Contact emails va...@chromium.org, voge...@chromium.org >>>>>>>>> Specification Explainer: >>>>>>>>> https://github.com/mikewest/deprecating-document-domain HTML Spec >>>>>>>>> draft: >>>>>>>>> https://github.com/whatwg/html/compare/main...otherdaniel:dd >>>>>>>>> API spec Yes >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> This is a follow-on to the Intent to Ship: Origin Isolation By >>>>>>>>> Default / Deprecate document.domain >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/>. >>>>>>>>> We'd >>>>>>>>> like to ship this in M110, stable. >>>>>>>>> >>>>>>>>> Summary (of the underlying change) 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 >>>>>>>>> Risks: Interoperability and Compatibility >>>>>>>>> >>>>>>>>> There are compatibility risks, which we have reduced with outreach >>>>>>>>> and warnings, and we want to mitigate further by launching at 50% of >>>>>>>>> beta >>>>>>>>> first. An extended discussion of the risk (including attempts at >>>>>>>>> quantitative assessment) can be found in the original intent to >>>>>>>>> ship >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/> >>>>>>>>> . >>>>>>>>> >>>>>>>>> Gecko: Standards position request >>>>>>>>> <https://github.com/mozilla/standards-positions/issues/601>. >>>>>>>>> ("Worth prototyping") >>>>>>>>> >>>>>>>>> WebKit: >>>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-December/032067.html >>>>>>>>> (No signals.) >>>>>>>>> >>>>>>>>> Web developers: No signals. >>>>>>>>> >>>>>>>>> Activation - Deprecation plan >>>>>>>>> M109: Enable "Origin Agent Cluster by Default" for 50% of page >>>>>>>>> loads on beta, dev, and canary. >>>>>>>>> >>>>>>>>> M110: Enable "Origin Agent Cluster by Default" on stable. >>>>>>>>> Security This change should be security-positive, since setting >>>>>>>>> document.domain will not have any impact on the origin of the >>>>>>>>> document any >>>>>>>>> more. >>>>>>>>> Debuggability A deprecation warning has been added to DevTools >>>>>>>>> console and to the issues panel in M98. 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> >>>>>>>>> ? This is covered by Origin-keyed Agent Cluster tests >>>>>>>>> <https://wpt.live/html/browsers/origin/origin-keyed-agent-clusters/> >>>>>>>>> . >>>>>>>>> Tracking bug https://crbug.com/1139851 >>>>>>>>> Launch bug 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 blink-dev+...@chromium.org. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNEMgvrOehp5%2Bf48yQ62pY3xqXqATPNxWZ6aYQ%2BXeHHAg%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNEMgvrOehp5%2Bf48yQ62pY3xqXqATPNxWZ6aYQ%2BXeHHAg%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+...@chromium.org. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW0vt%2BzXxGf_f7YBF2Lq1K1y5F_VJMtK6whuSiQX9_t3g%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW0vt%2BzXxGf_f7YBF2Lq1K1y5F_VJMtK6whuSiQX9_t3g%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+...@chromium.org. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPFMpseckt22K5bd%2BRsctwWihiwCdSA9vvCTZw_tOtT5A%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPFMpseckt22K5bd%2BRsctwWihiwCdSA9vvCTZw_tOtT5A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Eiji Kitamura / えーじ | Developer Advocate | @agektmr >>>>>>>>> <https://twitter.com/agektmr> | Office Location: Tokyo Shibuya >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Eiji Kitamura / えーじ | Developer Advocate | @agektmr >>>>>>>>> <https://twitter.com/agektmr> | Office Location: Tokyo Shibuya >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Eiji Kitamura / えーじ | Developer Advocate | @agektmr >>>>>>>>> <https://twitter.com/agektmr> | Office Location: Tokyo Shibuya >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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+...@chromium.org. >>>>>>>>> >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0aa8ac1f-6b52-425f-8e25-f09f55c9e0fdn%40chromium.org >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0aa8ac1f-6b52-425f-8e25-f09f55c9e0fdn%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/CADAYvoc24scGp3XHZrC%3Dpg7zaUU5OeRLaM9NbS-hbvLRJ06XHQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAYvoc24scGp3XHZrC%3Dpg7zaUU5OeRLaM9NbS-hbvLRJ06XHQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> > > -- > D.Madanagopal > > -- > 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/CAHxeoW%2BtSDHv9vNkAWa5Sfd-QAabvJJzDg%2BFtmK2z%2BfdE7XvAQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHxeoW%2BtSDHv9vNkAWa5Sfd-QAabvJJzDg%2BFtmK2z%2BfdE7XvAQ%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/CAF8qwaAPX_kQqY625sAdB_-Hf_DVJvyhCnV06S5BYwaW1uYGWQ%40mail.gmail.com.
