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 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.
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. > > 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 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! > > >>>> 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/CAFKd2qV9_a84_F%3Dnn4PLfv1FQj5Xx2qvn2U1R6aMj5-6tZcuTA%40mail.gmail.com.
