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.
