LGTM3. -mike
On Fri, Apr 21, 2023 at 7:42 PM 'Jun Kokatsu' via blink-dev < blink-dev@chromium.org> wrote: > Hi Brandon! > > I'll make sure to do that! I'll ping you next week when I start to work > on it! > > Thanks, > > Jun > > > On Fri, Apr 21, 2023 at 7:55 AM Brandon Heenan <bhee...@google.com> wrote: > >> One addition please: work with me and the enterprise team to also add a >> paragraph to the enterprise release notes before the deprecation warning is >> switched to on-by-default >> >> On Fri, Apr 21, 2023 at 3:13 AM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> LGTM2 for the above plan. Good luck!! >>> >>> On Thu, Apr 20, 2023 at 11:37 PM Rick Byers <rby...@chromium.org> wrote: >>> >>>> Jun and I have been talking about this offline and I think we've got a >>>> reasonable plan to attempt to proceed with this breaking change: >>>> >>>> - Add Enterprise policy knob >>>> <https://www.chromium.org/developers/enterprise-changes/> >>>> - Disable in WebView by default (or add targetSdk quirk) - in >>>> discussion with WebView team >>>> - Publish a blog post explaining the change and how to adapt to it, >>>> linked from chromestatus entry >>>> - Add deprecation warning (console + deprecation report) linking to >>>> chromestatus entry >>>> - Try flipping the flag on with Finch in canary and dev builds, >>>> maybe beta 50%, watch for reports of bugs and engage on any to see if >>>> they're similarly easy to get sites fixed >>>> - Once 3 milestones have passed with the deprecation warning and >>>> there's aren't major known issues, flip the flag on by default (with >>>> killswitch in place) >>>> - As the change makes its way to stable, keep an eye on any >>>> reports. Be prepared to hit the killswitch and iterate if there is >>>> significant breakage that can't be immediately addressed. >>>> >>>> With this plan, I'm LGTM1 to give this a shot. >>>> >>>> On Tue, Jan 24, 2023 at 10:22 AM Rick Byers <rby...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> On Mon, Jan 23, 2023 at 3:00 PM Jun Kokatsu <jkoka...@google.com> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I wanted to provide some updates on outreach I've done last week. >>>>>> >>>>>> I manually went through a list of sample sites in the use counter >>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4356>, >>>>>> and contacted ~10 sites which will be impacted. Among those sites, 3 >>>>>> sites >>>>>> responded so far. >>>>>> >>>>>> 1. onsetapp.com has successfully migrated away from data: URLs in >>>>>> SVGUseElement. >>>>>> - Reason for the usage: >>>>>> >>>>>> >>>>>> *"We used them to import elements from SVG sprites, basically an SVG >>>>>> file containing every icons loaded once at page load as an attempt >>>>>> to >>>>>> improve performance of the app."* >>>>>> 2. jobs.nzz.ch are testing the fix in the development pipeline, >>>>>> and hope to migrate away from data: URLs in SVGUseElement soon. >>>>>> - Reason for the usage is unsure as it was done a long time ago. >>>>>> 3. We've reached out to Salesforce contact (thanks Rick!) for >>>>>> appexchange.salesforce.com. They are trying to find a responsible >>>>>> team for that subdomain to understand why it was used, and if it can >>>>>> be >>>>>> migrated away. >>>>>> >>>>>> Thanks Jun, that's some good anecdotal evidence that adapting to this >>>>> breaking change likely isn't too hard for most folks. Despite it being >>>>> only >>>>> a couple anecdotes, this increases my confidence. >>>>> >>>>> >>>>>> I've also identified faucet.okp4.network as a false positive, >>>>>> because they use svgxuse <https://github.com/Keyamoon/svgxuse> as a >>>>>> fallback >>>>>> mechanism <https://github.com/okp4/ui/pull/433>. >>>>>> >>>>> >>>>> Fascinating. >>>>> >>>>> I will wait for sometime so that UKM will reach Beta or Stable, to >>>>>> further identify impacted origins with high volume of access. >>>>>> >>>>> >>>>> Yeah I think this is the most important next step. With luck we'll >>>>> find that there's not too much of a long tail and we can succeed in >>>>> getting >>>>> a significant drop in usage through outreach. >>>>> >>>>> BTW, thank you Daniel for creating a page >>>>>> <https://dbratell.github.io/svg-use-icons/> with easy to read >>>>>> alternatives! This was very helpful in the outreach process! >>>>>> >>>>> >>>>> Thanks Daniel! If we proceed with deprecation then perhaps this page >>>>> should form the basis of a chromium.org blog post on the topic that >>>>> we can link to from the chromestatus entry that will be referenced in the >>>>> deprecation warning message. >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jun >>>>>> >>>>>> >>>>>> On Thu, Jan 19, 2023 at 3:23 PM Jun Kokatsu <jkoka...@google.com> >>>>>> wrote: >>>>>> >>>>>>> On Thu, Jan 19, 2023 at 2:14 PM Rick Byers <rby...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> On Thu, Jan 19, 2023 at 1:17 PM Jun Kokatsu <jkoka...@google.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> So if we find it's too breaking to disallow this pattern >>>>>>>> completely, could we instead just disable script execution from within >>>>>>>> the >>>>>>>> context of documents resulting from data: URLs in SVGUseAttributes? >>>>>>>> >>>>>>> >>>>>>> Is that solution for Trusted Types or XSS through SVGUseElement in >>>>>>> general? >>>>>>> >>>>>> >>>>> I was thinking for SVGUseElement in general. >>>>> >>>>> >>>>>> If it is for Trusted Types, it does solve the issue in Chromium for >>>>>>> short term, but we want other rendering engines to implement Trusted >>>>>>> Types >>>>>>> as well. Does that mean we spec this in Trusted Types that inline event >>>>>>> handlers from SVGUseElement will be disallowed when enforcing Trusted >>>>>>> Types? >>>>>>> One thing I'm not sure about this approach is that each rendering >>>>>>> engine has differences in supported features inside SVGUseElement. >>>>>>> >>>>>> >>>>> Oh yeah I certainly wouldn't suggest we do anything chromium-specific >>>>> here. Just that if we decide the web compat challenge of deprecating all >>>>> data urls is too high, then we could probably get other vendors on board >>>>> with something more modest and get that fully spec'd and tested. >>>>> >>>>> For example, if the <foreignObject> >>>>>>> <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/foreignObject> >>>>>>> is supported, then iframes inside foreignObject can have srcdoc, and it >>>>>>> can >>>>>>> contain script tags which are considered "stored" XSS (because the >>>>>>> payload >>>>>>> never goes through DOM APIs), and therefore Trusted Types could be >>>>>>> bypassed >>>>>>> (i.e. script tags are not inline event handlers). But maybe the current >>>>>>> script element restriction >>>>>>> <https://www.w3.org/TR/SVG2/struct.html#UseShadowTree:~:text=Within%20a%20use%2Delement%20shadow%20tree%2C%20%E2%80%98script%E2%80%99%20elements%20are%20inert%20(do%20not%20execute)%3B> >>>>>>> on the use element is enough to apply in child frames too? >>>>>>> >>>>>>> If it is for XSS, then as I mentioned, SVG link >>>>>>> <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/a> with >>>>>>> Javascript: URL can still trigger XSS (because the script execution is a >>>>>>> result of navigation, which can happen in the top frame or iframes by >>>>>>> target attribute). >>>>>>> >>>>>>> Long story short, we did consider disabling scripts, but people's >>>>>>> consensus (1 >>>>>>> <https://github.com/mozilla/standards-positions/issues/718>, 2 >>>>>>> <https://github.com/WebKit/standards-positions/issues/108>, 3 >>>>>>> <https://github.com/w3c/trusted-types/issues/357#issuecomment-1049761361> >>>>>>> , 4 >>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1300195#c10> >>>>>>> , 5 >>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1300195#c11>) >>>>>>> has been that it's just better to deprecate data: URLs in SVGUseElement. >>>>>>> >>>>>> >>>>> Thanks for those links, I hadn't appreciated how much discussion >>>>> had gone into the tradeoffs already. I agree that if we can convince >>>>> ourselves it's not too breaking that this is the best solution. But I see >>>>> from the discussion that the consensus was based on the assumption that we >>>>> had already decided the web compat risk was sufficiently low. I'd >>>>> certainly >>>>> prefer not to re-open the standards discussion as this solution seems the >>>>> safest, simplest and most coherent for the platform, but it's good to know >>>>> what our fallback options are so that we can keep the cost/benefit >>>>> tradeoffs in mind as we learn more. >>>>> >>>>>> 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/CAOWKMF4pXiQd2OvaSfB0ZLFZ-0Ej9ghW%2BDbhrCVMUzy9Zhk4Zw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF4pXiQd2OvaSfB0ZLFZ-0Ej9ghW%2BDbhrCVMUzy9Zhk4Zw%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/CAKXHy%3DedsKwN1gm%2B-nv6azFs21BBo%2Bo8C44UNuVaGwOLNVCvZQ%40mail.gmail.com.
