Sorry for the delay from API owners, as discussed on chat the chromestatus entry wasn't set up properly to request API owner review (now fixed).
This is a tricky one indeed (thanks for your input Ashley!). It looks like <https://chromestatus.com/metrics/feature/timeline/popularity/4026> WebGL is used on about 20% of page loads, so 2.7% of that is ~0.5% of page loads which is very high risk according to our rules of thumb <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.mqfkui78vo5z> . Of course that's an upper-bound, how many will have a fallback? One option would be to collect some UKM data for SwiftShader usage and review a random ~50 sites to observe the user experience in practice. That could give us a better sense of what the real user impact would likely be. Or Maybe Ashley can give us some examples of some web games just to confirm they indeed go from being playable to unplayable without swiftshader on some specific devices? David, do you have a device yourself you can test with that doesn't support GPU WebGL? Regardless, unless sites have been really good about almost always falling back somehow, I suspect we'll find that there's enough end-user impact to make this a high-risk change (but I could be convinced otherwise such as via a thorough UKM analysis). In which case then we could start working through our playbook for a phased plan for risky breaking changes. Not unlike what we did for flash removal <https://www.chromium.org/flash-roadmap/>, or WebSQL <https://developer.chrome.com/blog/deprecating-web-sql> (both big security benefit but big web compat risk). For example: - Explore whether we can build swiftshader into a wasm module that sites can use as a (probably even slower) fallback themselves. This turned out to be the key to making WebSQL deprecation tractable. In general our policy <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.x5bhg5grhfeo> is that we don't take functionality away that developers can't replace with some other substitute except in pretty extreme circumstances. - Prompt the user on whether or not to enable it per-origin (like a permission) - Put 3p usage behind a permission policy so the top-level site has to opt-in to allow 3p iframes to use swiftshader - Rely on some heuristics, (perhaps crowd-sourced signals) to try to find a sweet spot in the safety vs. functionality tradeoff space. We did this for flash initially with things like blocking it for very small canvases. - Anything we can do to make WebGL work on a larger set of devices? - Probably lots of other ideas that aren't occurring to me right now, more examples in bit.ly/blink.compat. On the other side of the equation, API owners can be convinced to accept more compat risk the more significant the security benefits are. Are there more details you can share? Such as: - Are we confident that an attacker can only trigger swiftshader on somewhere around 3% of users (vs. some knob which can force it to be used on a larger fraction)? To what extent do we have reason to believe that the vulnerable population size is large enough to be a plausible target for attackers? Is there anything we can do to make the vulnerable user base more reliably contained? - How does swiftshader compare to other areas in terms of the number of vulnerabilities we've found in practice? Are there any reports of ITW exploits of it? It looks like <https://chrome-commit-tracker.arthursonzogni.com/cve/reward_per_components?start=2019-12-27&end=2025-02-25> since 2020 SwiftShader has been about 8% of Chrome's VRP spend - that seems quite significant to me, but probably not in the top 5 areas of concern. This was obviously key to the immense cost and pain of Flash removal - we kept having severe security incidents in practice. So assuming Ashley and I are right that this isn't likely to be easy, that means it's likely quite a lot of work to attempt to phase-out SwiftShader in a responsible fashion. But with luck maybe we can find a first step that is a good cost-benefit tradeoff (like putting 3P usage behind a permission prompt)? Or maybe it's just a better cost-benefit tradeoff to invest in other areas which pose a threat to a greater number users (hardening ANGLE perhaps)? But of course I will defer to the judgement of security and GPU experts like yourself on that question, I'm happy to consult and support if you want to invest in a plan that API owners can approve. Rick On Wed, Feb 19, 2025 at 2:48 PM 'David Adrian' via blink-dev < blink-dev@chromium.org> wrote: > > I wrote about this previously but I'm still concerned this is a major > breaking change for existing published WebGL content on the web. If the > figure of 2.7% comes from my previous citing of Web3DSurvey > > It does, not it comes from Chrome's metrics system. > > > Does Google have their own internal data about the usage of SwiftShader? > > It is the 2.7% number. > > > Suppose this change rolls out and we get reports that say our WebGL > content no longer works for 10% of users in a South American market. Then > what? There is nothing feasible we can do about it. These customers were > previously getting by with SwiftShader, but now they get an error message. > So I fear this risks disaster for web games in some markets. > > > I mentioned I don't think it should be used as evidence to make such a > big change as this. Maybe in some places it will affect 25% or 50% of users > - who knows? How can we be sure? > > Can you share the number for Construct about what percentage of your users > are using the SwiftShader fallback? Again, our numbers indicate that these > are primarily older Windows workstations. Notably, SwiftShader is not used > at all on mobile. > > > V8 does JIT with untrusted JavaScript code and that is generally > considered reasonably secure, is there any particular technical reason > SwiftShader is not considered as secure? > > Yes. The GPU process is shared between all sites, whereas the V8 JIT is > per-site. This means compromising the GPU process can be enough to bypass > site isolation protections with a single bug. Additionally, V8 bugs can be > reliably patched in the browser, whereas SwiftShader "bugs" can be > user-mode graphics driver bugs that are simply more exposed via SwiftShader > than they would be otherwise. In this case, the browser can't patch the bug > because it's in the driver. > > > > > On Thursday, February 13, 2025 at 12:12:07 PM UTC-5 ash...@scirra.com > wrote: > >> I wrote about this previously but I'm still concerned this is a major >> breaking change for existing published WebGL content on the web. If the >> figure of 2.7% comes from my previous citing of Web3DSurvey ( >> https://web3dsurvey.com/) then this should be seen as very much an >> underestimate, because that site uses a relatively small sample size that >> is more likely to be focused on high-end devices (samples are taken from >> developer-focused sites like the three.js website, WebGPU fundamentals >> etc). I would not be surprised if the real worldwide average was more like >> 4-5%. Then if that's a worldwide average, there will probably be some >> specific countries or markets where the figure could be more like 10%. >> >> Suppose this change rolls out and we get reports that say our WebGL >> content no longer works for 10% of users in a South American market. Then >> what? There is nothing feasible we can do about it. These customers were >> previously getting by with SwiftShader, but now they get an error message. >> So I fear this risks disaster for web games in some markets. >> >> Does Google have their own internal data about the usage of SwiftShader? >> Can more data about this be shared? I respect the work done by Web3DSurvey >> but unfortunately for the reasons I mentioned I don't think it should be >> used as evidence to make such a big change as this. Maybe in some places it >> will affect 25% or 50% of users - who knows? How can we be sure? >> >> Can there not be some other fallback implemented? V8 does JIT with >> untrusted JavaScript code and that is generally considered reasonably >> secure, is there any particular technical reason SwiftShader is not >> considered as secure? >> >> I'd also point out that any website that has a poor experience with >> SwiftShader can already opt-out using the failIfMajorPerformanceCaveat >> context flag. If there is some other mode that can be used instead, or just >> showing an error message is acceptable, then websites can already implement >> that. In our case with Construct we specifically attempt to obtain >> hardware-accelerated WebGPU, WebGL 2, or WebGL 1; only failing that do we >> resort to using SwiftShader on the basis that showing the content with >> potentially poor performance is better than not showing it at all. >> >> >> On Thu, 13 Feb 2025 at 15:46, 'David Adrian' via blink-dev < >> blin...@chromium.org> wrote: >> >>> Contact emails >>> >>> dad...@google.com, geof...@chromium.org >>> >>> Summary >>> >>> Allowing automatic fallback to WebGL backed by SwiftShader is deprecated >>> and will be removed. This has been noted in DevTools since Chrome 130. >>> >>> WebGL context creation will fail instead of falling back to SwiftShader. >>> This is for two primary reasons: >>> >>> 1. SwiftShader is a high security risk due to JIT-ed code running in >>> Chromium's GPU process. >>> >>> 2. Users have a poor experience when falling back from a >>> high-performance GPU-backed WebGL to a CPU-backed implementation. Users >>> have no control over this behavior and it is difficult to describe in bug >>> reports. >>> >>> SwiftShader is a useful tool for web developers to test their sites on >>> systems that are headless or do not have a supported GPU. This use case >>> will still be supported by opting in but is not intended for running >>> untrusted content. >>> >>> To opt-in to lower security guarantees and allow SwiftShader for WebGL, >>> run the chrome executable with the --enable-unsafe-swiftshader command-line >>> switch. >>> >>> During the deprecation period, a warning will appear in the javascript >>> console when a WebGL context is created and backed with SwiftShader. >>> Passing --enable-unsafe-swiftshader will remove this warning message. This >>> deprecation period began in Chrome 130. >>> >>> Chromium and other browsers do not guarantee WebGL availability. Please >>> test and handle WebGL context creation failure and fall back to other web >>> APIs such as Canvas2D or an appropriate message to the user. >>> >>> SwiftShader is an internal implementation detail of Chromium, not a >>> public web standard, therefore buy-in from other browsers is not required. >>> The devices covered by SwiftShader (primarily older Windows devices) are >>> likely already incompatible with WebGL in other browsers. >>> >>> SwiftShader is not used on mobile; this only applies to Desktop >>> platforms. >>> >>> Blink component >>> >>> Blink>WebGL >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebGL%22> >>> >>> Motivation >>> >>> >>> https://chromium.googlesource.com/chromium/src/+/main/docs/gpu/swiftshader.md#automatic-swiftshader-webgl-fallback-is-deprecated >>> >>> Risks >>> >>> SwiftShader is used by devices without hardware acceleration for WebGL. >>> This is approximately 2.7% of WebGL contexts. However, WebGL is considered >>> fallible and in many cases, these draws are not performant and provide an >>> effectively unusable experience for users. Many applications, such as >>> Google Maps, prefer to fail out rather than use SwiftShader. >>> >>> Debuggability >>> >>> None >>> >>> Flag name on about://flags >>> >>> --enable-unsafe-swiftshader command-line switch. >>> >>> Finch feature name >>> >>> AllowSwiftShaderFallback >>> >>> Tracking bug >>> >>> https://issues.chromium.org/40277080 >>> >>> Launch bug >>> >>> https://launch.corp.google.com/launch/4351104 >>> >>> Estimated milestonesShipping on Desktop 137 >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5166674414927872?gate=5188866041184256 >>> >>> 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+...@chromium.org. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42KV4DrSSyEgJaF4DnFOXAye-wRLrfD-LKGNkWhyWzshLA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42KV4DrSSyEgJaF4DnFOXAye-wRLrfD-LKGNkWhyWzshLA%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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c5131675-dff4-4aa0-8e84-4cdc373e3035n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c5131675-dff4-4aa0-8e84-4cdc373e3035n%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_SSKg7VjCEfoccVxhQUS5GWxDyZ%3DvPcjZft_6Wxbh_8w%40mail.gmail.com.
