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/c3101adf-da70-49ce-bc3e-31ad38b6a2a0n%40chromium.org.
