On Thu, Jan 19, 2023 at 9:29 AM Rick Byers <rby...@chromium.org> wrote:
> Thanks Daniel. I also looked at this page > <https://appexchange.salesforce.com/#:~:text=Learn%20More-,Sponsored%20Solutions,-Show%20More> > which > inlines the same 422 kB long sprite sheet 5 separate times, only to select > a tiny 422 BYTE SVG out of it each time! In that case, simply inlining the > desired SVG would save both several MB of network and a lot of parse/decode > time. Perhaps there's an opportunity for a tool at design time which > unrolls these inlined sprite sheets, like Jun's tool > <https://data-urls-in-svg-converter.glitch.me/> does? > > Rick > > On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell <bratel...@gmail.com> > wrote: > >> Without saying whether it is appropriate to block data urls, I would like >> to say that doing what the site is doing with icons in data urls is far >> from the best way to do it. Since there are better ways to accomplish the >> same output, it's not in itself a use pattern that must be preserved. It is >> better to either have the icons in a separate file, or if that is >> unsuitable, have them inline in an invisible svg. I put a quick demo at >> https://dbratell.github.io/svg-use-icons/ but in short you could have >> >> <svg style="display:none"><defs><symbol id="icon1">...</symbol><symbol >> id="icon2">...</symbol></defs></svg> >> >> And then refer to the icons in it with <svg><use >> xlink:href="#icon1"></svg> or <svg><use xlink:href="#icon2"></svg> >> That would have cut tens of KB from the cz site source. I checked with fs >> and thanks to optimizations Blink would not have created a separate svg >> document for each icon but that was also a risk. >> >> (Also curious to the answer to Alex' question) >> >> /Daniel >> >> On 2023-01-18 17:50, Alex Russell wrote: >> >> Per today's API OWNERs meeting, a dumb question: is the XSS risk here >> largely down to script execution triggered by this pattern? Or non-script >> content in the inline'd SVG? >> >> Sorry, I just noticed that I only replied to Alex yesterday 🙂 The XSS risk here is mostly about script execution triggered by this pattern. This includes (but not limited to) inline event handlers and links with Javascript URLs. > Thanks >> >> On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote: >> >>> On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan <bhee...@google.com> >>> wrote: >>> >>>> Thanks for adding me. Yes, this definitely seems like the pattern where >>>> we'd want a temporary enterprise policy to re-enable support for ~3 >>>> milestones after we remove support by default. >>>> go/chrome-enterprise-friendly >>>> <https://goto.google.com/chrome-enterprise-friendly> gets into the >>>> details of the why, >>>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md >>>> is the step-by-step, and the enterprise team is always happy to advise as >>>> well. >>>> >>> >>> Thank you for the details on enterprise policy! I'll make sure to follow >>> those steps when I plan to remove the feature by default! >>> >>>> On Tue, Jan 17, 2023 at 10:51 AM Rick Byers <rby...@chromium.org> >>>> wrote: >>>> >>>>> On Tue, Jan 17, 2023 at 4:48 AM Yoav Weiss <yoavwe...@chromium.org> >>>>> wrote: >>>>> >>>>>> Would it be possible to turn >>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=30?q=ukm%20usecounter&ss=chromium> >>>>>> the usecounter into a UKM to get a better view of the number of impacted >>>>>> origins, beyond just the homepage? >>>>>> >>>>> >>>>> Yeah that could be useful. But we've also got some leads already so >>>>> getting more leads may not be critical until we follow up on the ones we >>>>> have. Can we find a developer for one of those sites who will talk to us >>>>> about where that pattern is coming from in their toolchain and how they'd >>>>> migrate off it? Having the UKM data will also help in selecting the sites >>>>> that will have the most impact on our users (and hence our UseCounter >>>>> stats). Maybe we'll get lucky and find that, despite the long tail, 90% of >>>>> the usage is from just a few sites we can work with. >>>>> >>>> >>> Added UKM at https://crrev.com/c/4171733. >>> >>>> >>>>> I wonder if this would be a good candidate for a deprecation trial + >>>>>> enterprise policy. That would solve this injection vector for the broader >>>>>> web, while giving impacted folks some more time to move away from this >>>>>> pattern. >>>>>> >>>>> >>>>> Good idea. Impacting a large number of small sites is still >>>>> problematic for a deprecation trial. Just reaching enough to make any >>>>> change at all is the hard part. Perhaps we can make replacing the usage >>>>> easier than the overhead of getting an applying an OT token? Still a >>>>> deprecation trial would probably be useful. Enterprise policy, certainly. >>>>> +Brandon >>>>> Heenan <bhee...@google.com> can help advise on that. I'd also advise >>>>> leaving this enabled for WebView (at least to start), it feels like the >>>>> sort of chromium rendering quirk we've found Android apps to rely on >>>>> disproportionately in the past. >>>>> >>>>> On Fri, Jan 13, 2023 at 9:11 PM 'Jun Kokatsu' via blink-dev < >>>>>> blink-dev@chromium.org> wrote: >>>>>> >>>>>>> Thank you Rick for the detailed explanation! >>>>>>> >>>>>>> On Fri, Jan 13, 2023 at 10:30 AM Rick Byers <rby...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Eliminating this makes sense to me given the security benefit. >>>>>>>> Thank you for pushing it! But it does seem somewhat risky from a web >>>>>>>> compat >>>>>>>> perspective. 0.005% is above our "small but non-trivial risk >>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.mqfkui78vo5z>" >>>>>>>> rule of thumb. Here's a bit of an analysis according to our other >>>>>>>> compat >>>>>>>> principles <http://bit.ly/blink-compat>: >>>>>>>> >>>>>>>> - Severity of breakage >>>>>>>> >>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.u5ya6jvru7dl>: >>>>>>>> lower given this is likely only about some visualis, but this >>>>>>>> site <https://jobs.nzz.ch/> is a good example of non-trivial UI >>>>>>>> breakage. This pattern of putting a base64-encoded SVG into an SVG >>>>>>>> <use> >>>>>>>> element with nothing else in the <svg> is weird, isn't it? Why would >>>>>>>> someone do that rather than just put the SVG in directly, or put >>>>>>>> the data >>>>>>>> URL into an img tag? >>>>>>>> >>>>>>>> I've looked into that site. And it seems like they are reusing a >>>>>>> single SVG image (i.e. data: URL SVG image) which contains several >>>>>>> images, >>>>>>> and changing which image should be rendered by combination of symbol >>>>>>> <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/symbol> + >>>>>>> id (which is only possible in use element, and not in img tag). >>>>>>> Migration >>>>>>> can be done by hosting the same image in the same-origin endpoint, >>>>>>> converting it to blob: URL and assigning that to the <use> element, or >>>>>>> inlining each SVG image. >>>>>>> >>>>>> >>>>> Interesting. So could we write a tool which, given the source html, >>>>> transforms it to simply inline the selected SVG? That would save some >>>>> bytes >>>>> too, right? We've found in the past that when we give developers easy >>>>> tools >>>>> to trivially adapt their code, then it makes moderate-risk deprecations go >>>>> quite smoother. I.e. when we get to the point of having a deprecation >>>>> warning (and report <https://wicg.github.io/deprecation-reporting/>) >>>>> for the usage, if we can simply say "for most cases we've found you can >>>>> just run your html through this tool to adapt it automatically", then that >>>>> would help a LOT in having the comfort to make the breaking change. >>>>> Someone >>>>> from the devrel or tooling teams with experience in how developers >>>>> approach >>>>> images in practice (eg. +Addy Osmani <ad...@chromium.org>) might be >>>>> able to advise on a pragmatic and helpful path. >>>>> >>>> >>> I've created a site to convert data: URLs in SVGUseElement to inline SVG. >>> https://data-urls-in-svg-converter.glitch.me/ >>> >>>> >>>>>>>> - I don't suppose there's some creative way to allow this >>>>>>>> specific odd pattern while still getting the security benefit, is >>>>>>>> there? >>>>>>>> >>>>>>>> Unfortunately, no. While we could read the href value of <use> >>>>>>> elements and convert the data: URL to blob: URL, we won't know if the >>>>>>> data: >>>>>>> URL was set by the site owner, or a malicious attacker (through HTML >>>>>>> injection). So while we could provide such a library, it does not >>>>>>> provide >>>>>>> the security benefit that we are seeking. >>>>>>> >>>>>>>> >>>>>>>> - Unique sites impacted >>>>>>>> >>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.4k9u8ddizqrq>: >>>>>>>> Finding a variety of small sites is actually a lot worse than if we >>>>>>>> had >>>>>>>> found only a few bigger sites. It means there's probably some >>>>>>>> common tool >>>>>>>> or pattern leading different designers/developers to do this and so >>>>>>>> likely >>>>>>>> a relatively large number of individuals who would need to be >>>>>>>> involved in >>>>>>>> fixing the breakage. Of course our HTTP Archive list of sites is >>>>>>>> just a >>>>>>>> subset of who's fully impacted, so if the problem is a long-tail >>>>>>>> one as it >>>>>>>> seems, HTTP archive data shows us only the tip of that long tail. >>>>>>>> - Security >>>>>>>> >>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.iklh96dxj81w>: >>>>>>>> it's definitely worth taking some comapt risk to reduce XSS surface >>>>>>>> area. I >>>>>>>> don't fully understand the threat model though. Is this mainly a >>>>>>>> risk for >>>>>>>> sites who are programmatically putting (potentially >>>>>>>> attacker-controlled) >>>>>>>> strings into SVGUseElement hrefs? Or are you more worried about >>>>>>>> cases where >>>>>>>> the attacker controls the HTML and can take advantage of this >>>>>>>> oddity in the >>>>>>>> platform on any normal site? I'm just trying to gauge the magnitude >>>>>>>> of the >>>>>>>> security benefit here to weigh it against the comapt risk, any help >>>>>>>> is >>>>>>>> appreciated. >>>>>>>> >>>>>>>> We are worried about both (i.e. Server-side injection and DOM XSS). >>>>>>> The fact that this has led to several browser security feature bypasses >>>>>>> (e.g. Sanitizer API and Trusted Types) suggests that it's not a commonly >>>>>>> known XSS sink, and therefore we believe that it's common for security >>>>>>> mechanisms (e.g. sanitizers, linters) to miss this odd feature. >>>>>>> >>>>>>>> >>>>>>>> - Ease of adaptation >>>>>>>> >>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.x5bhg5grhfeo>: >>>>>>>> seems like it should be easy to use an alternative, at least for >>>>>>>> these >>>>>>>> image cases, but I guess it's hard to say without knowing why >>>>>>>> people are >>>>>>>> doing this. Is there perhaps some website design tool which is >>>>>>>> generating >>>>>>>> this and will need to change? >>>>>>>> >>>>>>>> I think it is easy to migrate by hosting the same image to the >>>>>>> same-origin endpoint. However, I do understand that it's just less work >>>>>>> to >>>>>>> use data: URL than using same-origin image or blob: URL. >>>>>>> >>>>>>>> >>>>>>>> - Interop >>>>>>>> >>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.4hjbxw7513sw>: >>>>>>>> The fact that this doesn't work in Safari is a vote in favor of >>>>>>>> breaking it >>>>>>>> in chromium to achieve interop. It does work in Firefox though. >>>>>>>> >>>>>>>> For the interop, it's best to use a same-origin URL or blob: URL. >>>>>>> And since both Mozilla and Webkit are supportive, I believe it's >>>>>>> positive. >>>>>>> >>>>>>>> >>>>>>>> - Standards conformance >>>>>>>> >>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.xcsa26ortrmi>: >>>>>>>> This is allowed by spec today, so breaking it requires some more >>>>>>>> diligence >>>>>>>> >>>>>>>> Note that the PR <https://github.com/w3c/svgwg/pull/901> to SVG >>>>>>> spec got merged. >>>>>>> >>>>>> >>>>> Right, yes, sorry. What I meant was we took the initiative to make a >>>>> breaking change to long established behavior - IMHO that makes the bar >>>>> higher than if Chrome had just had a bug in allowing something that was >>>>> never spec'd or allowed by other browsers. Still I think we can use this >>>>> positively in our outreach - say something like "the spec has changed to >>>>> not allow this, all the major browser engines agree that for security >>>>> reasons it should be disallowed. It already doesn't work in Safari and >>>>> other WebKit browsers, we want to help you fix your site to work in all >>>>> browsers". >>>>> >>>>>> >>>>>>>> - Enterprise >>>>>>>> >>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.axcg738lzcs9>: >>>>>>>> Being broken in Safari is an indication the risk will be higher in >>>>>>>> enterprise software which is often chromium-only. We may need to go >>>>>>>> through >>>>>>>> the enterprise breaking change process >>>>>>>> <https://www.chromium.org/developers/enterprise-changes/>. >>>>>>>> - Outreach >>>>>>>> >>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.t9ade4ywppcg>: >>>>>>>> Given the relatively high usage, if we want to proceed with this >>>>>>>> plan I >>>>>>>> think this is the main opportunity for mitigations. Can we try >>>>>>>> contacting >>>>>>>> some of these sites we've identified to understand why they're >>>>>>>> using this >>>>>>>> pattern? Is there a tool generating this pattern which we can get >>>>>>>> updated >>>>>>>> before we make the change? I think we'd need a blog post capturing >>>>>>>> what >>>>>>>> we've learned from talking with a few customers who have done this >>>>>>>> and how >>>>>>>> they fixed it for their UI design flow. >>>>>>>> >>>>>>>> Sorry it's not looking to be an easy decision, but I hope this >>>>>>>> gives you some ideas for how we might be able to reduce the risk to a >>>>>>>> point >>>>>>>> that we could proceed. WDYT? >>>>>>>> >>>>>>> >>>>>>> Yes, it sounds good to me! I will check what has to be done and do >>>>>>> those step by step 🙂 >>>>>>> >>>>>> >>>>> Ok, good luck! Sorry this isn't as straightforward as a clear recipe. >>>>> But if we can get a couple developers telling us they were easily able to >>>>> fix their issue by using a tool or straightforward instructions we can >>>>> point other to, and we see the UseCounter drop significantly (say by half >>>>> or so) without major new red flags, then I'd personally be OK approving a >>>>> removal attempt. Of course it's common to learn during beta (or, worst >>>>> case, upon stable release) that the compat issue is worse than we thought >>>>> and so the change needs to be reverted (or flagged off with finch) in a >>>>> hurry. But I think we've learned a lot over the years about how to predict >>>>> and avoid that failure mode. Let me know if I can do anything else to >>>>> help, >>>>> happy to meet to brainstorm further for example. Good luck! >>>>> >>>> >>> Thanks! I'll start outreach for a couple of sites we already know are >>> affected, and go from there! >>> >>>> >>>>> >>>>>>>> Rick >>>>>>>> >>>>>>>> On Thu, Jan 12, 2023 at 3:11 PM 'Jun Kokatsu' via blink-dev < >>>>>>>> blink-dev@chromium.org> wrote: >>>>>>>> >>>>>>>>> On Thu, Jan 12, 2023 at 10:44 AM Mike Taylor < >>>>>>>>> miketa...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> On 1/11/23 6:49 PM, 'Jun Kokatsu' via blink-dev wrote: >>>>>>>>>> >>>>>>>>>> Contact emails >>>>>>>>>> >>>>>>>>>> jkoka...@google.com >>>>>>>>>> >>>>>>>>>> Specification >>>>>>>>>> >>>>>>>>>> https://svgwg.org/svg2-draft/struct.html#UseElementHrefAttribute >>>>>>>>>> >>>>>>>>>> https://github.com/w3c/svgwg/pull/901/files >>>>>>>>>> >>>>>>>>>> Summary >>>>>>>>>> >>>>>>>>>> Assigning a data: URL in SVGUseElement can cause XSS. And this >>>>>>>>>> also led to a Trusted Types bypass. >>>>>>>>>> >>>>>>>>>> Therefore, we plan to deprecate and remove support for it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Blink component >>>>>>>>>> >>>>>>>>>> Blink>SVG >>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESVG> >>>>>>>>>> >>>>>>>>>> Motivation >>>>>>>>>> >>>>>>>>>> Assigning an attacker controlled string to SVGUseElement.href >>>>>>>>>> causes XSS and a Trusted Types bypass >>>>>>>>>> <https://github.com/w3c/trusted-types/issues/357> because of >>>>>>>>>> data: URLs. If we fix this bug by requiring TrustedScriptURL >>>>>>>>>> assignment to >>>>>>>>>> SVGUseElement.href under Trusted Types enforcement, many sites would >>>>>>>>>> need >>>>>>>>>> to refactor code (even for same-origin URL or Blob URL assignment). >>>>>>>>>> >>>>>>>>>> Since Webkit does not support data: URLs in SVGUseElement and >>>>>>>>>> both Mozilla and Webkit are supportive for the removal, we think that >>>>>>>>>> removing support for data: URLs in SVGUseElement is the right way to >>>>>>>>>> solve >>>>>>>>>> this problem. >>>>>>>>>> >>>>>>>>>> Additionally, data: URLs can only trigger script execution in >>>>>>>>>> script loaders such as HTMLScriptElement.src or dynamic import >>>>>>>>>> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import>. >>>>>>>>>> However, SVGUseElement is an exception to this, which also caused a >>>>>>>>>> bypass >>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1306450#c10> >>>>>>>>>> in the Sanitizer API. We believe that this also led to several other >>>>>>>>>> bugs >>>>>>>>>> in sanitizers and linters missing a check for this special case. >>>>>>>>>> >>>>>>>>>> The usage >>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4356> >>>>>>>>>> of data: URLs in SVGUseElement is about 0.005%. >>>>>>>>>> >>>>>>>>>> Digging into the HTTP Archive shows usages in ~50 sites. There >>>>>>>>>> are 2 major sites (slickdeals.net and hunter.104.com.tw) which >>>>>>>>>> use data: URLs in SVGUseElement. >>>>>>>>>> >>>>>>>>>> The use in slickdeals.net is invisible (i.e. used in the footer >>>>>>>>>> but doesn't appear), and hunter.104.com.tw is using it for a >>>>>>>>>> single icon in the footer (which is already broken when rendered in >>>>>>>>>> Webkit). Rest of the usages seems to be in individual small sites. >>>>>>>>>> >>>>>>>>>> I poked around the 10 sample sites at the bottom of the use >>>>>>>>>> counter: >>>>>>>>>> >>>>>>>>>> https://www.aspareanord.it/, https://www.umbria.camcom.it, >>>>>>>>>> https://www.bisenzio.it/, https://www.comune.vernio.po.it/, >>>>>>>>>> https://appaltinnovativi.gov.it/, https://www.gdf.gov.it/, >>>>>>>>>> https://www.us.schott.com/, https://shop.wavin.com/, >>>>>>>>>> https://jobs.nzz.ch/, https://www.learnapp.com/ >>>>>>>>>> >>>>>>>>>> For the 6 Italian sites (I guess the same agency made them?), the >>>>>>>>>> right arrow icon next to "Vedi" would disappear. For a site like >>>>>>>>>> https://jobs.nzz.ch - there's a number of visually significant >>>>>>>>>> design icons that would be gone towards the bottom (and yes, it >>>>>>>>>> looks sort >>>>>>>>>> of broken today in Safari). >>>>>>>>>> >>>>>>>>>> It's not the end of the world, looking at these 10 sites, but I >>>>>>>>>> wonder how a developer would know how to fix this. Have you >>>>>>>>>> considered a >>>>>>>>>> DevTools issue? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you for the suggestion! Yes, I do plan to follow Deprecation >>>>>>>>> steps >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/core/frame/deprecation/README.md> >>>>>>>>> and >>>>>>>>> add a Devtools issue 🙂 >>>>>>>>> >>>>>>>>>> Initial public proposal >>>>>>>>>> >>>>>>>>>> TAG review >>>>>>>>>> >>>>>>>>>> TAG review status >>>>>>>>>> >>>>>>>>>> Not applicable. >>>>>>>>>> >>>>>>>>>> Because this intent removes part of a feature, and it is already >>>>>>>>>> shipped in Webkit (i.e. never supported). >>>>>>>>>> >>>>>>>>>> Risks >>>>>>>>>> >>>>>>>>>> Interoperability and Compatibility >>>>>>>>>> >>>>>>>>>> Gecko: Positive >>>>>>>>>> <https://github.com/mozilla/standards-positions/issues/718> >>>>>>>>>> >>>>>>>>>> WebKit: Positive >>>>>>>>>> <https://github.com/WebKit/standards-positions/issues/108> >>>>>>>>>> >>>>>>>>>> Web developers: No signals >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Debuggability >>>>>>>>>> >>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>>> Yes <https://github.com/web-platform-tests/wpt/pull/37511> >>>>>>>>>> >>>>>>>>>> Flag name >>>>>>>>>> >>>>>>>>>> RemoveDataUrlInSvgUse >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Requires code in //chrome? >>>>>>>>>> >>>>>>>>>> False >>>>>>>>>> >>>>>>>>>> Tracking bug >>>>>>>>>> >>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1300195 >>>>>>>>>> >>>>>>>>>> Estimated milestones >>>>>>>>>> >>>>>>>>>> Deprecate for 2 milestones, then remove depending on breakages. >>>>>>>>>> >>>>>>>>>> Can you say more about what the deprecation looks like (i.e., >>>>>>>>>> blog post, deprecation reports, devtools issue, etc)? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>> >>>>>>>>>> https://chromestatus.com/feature/5128825141198848 >>>>>>>>>> >>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>> <https://chromestatus.com/>. >>>>>>>>>> -- >>>>>>>>>> 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/CAOWKMF6VXw7jmQoZM47i3ybzn%3D5Pc4mw26Khv9U9aP_UzBt-dg%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF6VXw7jmQoZM47i3ybzn%3D5Pc4mw26Khv9U9aP_UzBt-dg%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/CAOWKMF5KQOG5R8baUM41T4fR01QbGFjvvEsf629h%2BzASCn_F0Q%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF5KQOG5R8baUM41T4fR01QbGFjvvEsf629h%2BzASCn_F0Q%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/CAOWKMF65KcSCkzVupRw4n8ZG%3DKKbG5GY62HzwNSZW4Z78ZYd_w%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF65KcSCkzVupRw4n8ZG%3DKKbG5GY62HzwNSZW4Z78ZYd_w%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/d63c3823-20b6-457c-bff9-f85429421bf0n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d63c3823-20b6-457c-bff9-f85429421bf0n%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/CAOWKMF5Toxjq6B%3DjxLgUe08PqE2%3D6mPZy-cU_Ttz0qsk%3Dfp2zg%40mail.gmail.com.
