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/05634721-54e6-44a5-b5be-9d4f5c95e362n%40chromium.org.
