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/CAH%2B8MBZxK5Qjbgz0MM19tq33ek5-ghDdY_xq77p9aqfsA6kM1A%40mail.gmail.com.
