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? > > 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/CAFUtAY90ASnrvRWxC9nJC%3D08x1%2BT4Y1vo8XroPM5F8t-wYVqnA%40mail.gmail.com.
