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/CAOWKMF4WWpwouFYgGA-ph%3DnM-FtQLQLALHC5XbgpmJmwr-fpqg%40mail.gmail.com.
