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> >> . >> > -- 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/CADAYvocjYLWM9%3DdzxkYdA6Jr30X7YYupm1vR8ExFgsRejj4B0A%40mail.gmail.com.
