Hi David and other folks, I am testing SwiftShader on a Debian 12 machine without hardware acceleration. It seems that SwiftShader is still enabled (I saw swiftshader in Chrome://gpu) in Chrome 139. Is this the expected behavior?
Also, I am curious about software rendering alternatives on Linux machines. Similar to WARP, do you have any plans to replace SwiftShader with MESA llvmpipe on Linux? I know there are also some Linux VM users who might also be affected by this removal. Thanks! Rui On Wednesday, July 9, 2025 at 11:35:32 AM UTC-4 David Adrian wrote: > An update: We added an enterprise policy > <https://chromeenterprise.google/policies/#EnableUnsafeSwiftShader> that > allows users to re-enable Swiftshader. This should help with the managed VM > / remote desktop use-case. > > In Chrome 139, we will start experimenting (via Finch/partial deployments) > with: > > - Removing Swiftshader support on MacOS and Linux > - Replacing Swiftshader with WARP on Windows > - Removing the OOM fallback to Swiftshader/WARP, so that it is not > attacker-triggerable on arbitrary devices > > > On Thursday, April 24, 2025 at 9:55:58 AM UTC-4 David Adrian wrote: > >> As it stands now, we are hopeful we can swap out to WARP on Windows >> without any drop in coverage for software rendering (i.e. simultaneously >> with removing SwiftShader). Experimental support and testing for this will >> begin in Chrome 137. >> >> On Thursday, April 10, 2025 at 12:47:33 PM UTC-4 Julie Powell wrote: >> >>> WebGL emulation is critical for many US entities that are running thin >>> client machines which don’t have access to a GPU. So far, the organizations >>> we’ve spoken to are on Windows so simultaneously putting an automatic >>> fallback to WARP in place once the fallback to SwiftShader is removed – >>> avoiding a period of time when a command line override would be required – >>> will allow them to continue operating. We have verified that the following >>> organizations are dependent on this capability (note that there are many >>> more outside of this list, both in the private and public sector): >>> Department of the Interior Bureau of Land Management, Office of Wildland >>> Fire, National Park Service, U.S. Geologic Survey, U.S. Fish and Wildlife >>> Service, Bureau of Indian Affairs, Air Force DCGS, Army Tactical Edge Node, >>> DCGS-Army, DCGS-USMC, USMC, USAF, USDA, NGA, DIA, Census, DHS, CISA, >>> FirstNet/NTIA (Commerce), NCIS, DTRA, STRATCOM, EUCOM, Idaho National >>> Guard, some universities, K-12 schools, National Geographic, and more. >>> >>> I am working with colleagues and international distributors to gauge the >>> usage of VMs running Linux which are doing web mapping and don’t have >>> access to GPU resources. I will come back with an update when I have one. >>> >>> On Monday, March 24, 2025 at 12:56:08 PM UTC-7 Matt George wrote: >>> >>>> Hi Rick, AFAIK it's only Windows, but currently reaching out to see if >>>> it's different for our distributors in Europe. >>>> >>>> Matt >>>> On Monday, March 24, 2025 at 10:38:19 AM UTC-7 Rick Byers wrote: >>>> >>>>> Thanks for chiming in Matt. Is the scenario you described Windows-only >>>>> (in which case we should be good with WARP), or also Linux? >>>>> >>>>> Rick >>>>> >>>>> On Mon, Mar 24, 2025 at 1:22 PM Matt George <matt...@gmail.com> wrote: >>>>> >>>>>> Very happy to hear about exploring the use of WARP on windows. >>>>>> >>>>>> Just wanted to chime in that from the Esri perspective, we also have >>>>>> a large number of users accessing our maps SDK from VMs without a GPU. >>>>>> This >>>>>> is done for security reasons, & not uncommon for public sector clients. >>>>>> We >>>>>> have a special codepath where when we detect software emulation is being >>>>>> used, we only render every X frames & then use css transforms >>>>>> in-between. >>>>>> This is fairly usable, though of course it's a much worse experience >>>>>> than >>>>>> having a GPU. >>>>>> >>>>> On Tuesday, March 11, 2025 at 1:11:42 AM UTC-7 Ashley Gullen wrote: >>>>>> >>>>>>> Thanks for the update David - that sounds like a much less >>>>>>> disruptive approach than removing it completely. >>>>>>> >>>>>>> >>>>>>> On Mon, 10 Mar 2025 at 19:26, David Adrian <dad...@google.com> >>>>>>> wrote: >>>>>>> >>>>>>>> To cover the testing use case, we have provided a CLI flag to >>>>>>>> enable SwiftShader. This has been in the release notes since November. >>>>>>>> If >>>>>>>> this is insufficient, we could add an enterprise policy. >>>>>>>> >>>>>>>> However, rather than attempt a straight removal, we are going to >>>>>>>> take a multi-pronged approach to attempt to simultaneously reduce the >>>>>>>> situations where SwiftShader is available, while maintaining >>>>>>>> compatibility with devices that require it due to the GPU blocklist. >>>>>>>> >>>>>>>> - SwiftShader is already unused on many Mac clients, since it >>>>>>>> does not support ARM. We will run an experiment where we fully >>>>>>>> remove it on >>>>>>>> Mac, where usage is much smaller. We expect this will be ~fine. >>>>>>>> - Similarly, we will try the same on Linux, although this may >>>>>>>> not go as well, as there are not a large number of ARM Linux >>>>>>>> clients. >>>>>>>> - We will experiment with removing the automatic fallback to >>>>>>>> SwiftShader after 3 OOMs, limiting it to just the devices without a >>>>>>>> GPU or >>>>>>>> on the GPU blocklist. This should reduce the attack surface across >>>>>>>> the >>>>>>>> board, as attackers would be unable to arbitrarily cause >>>>>>>> SwiftShader to be >>>>>>>> used. In conjunction with this, we'll see if we can leverage Warp >>>>>>>> on >>>>>>>> Windows. >>>>>>>> >>>>>>>> If we can get to a state where SwiftShader is off by default on Mac >>>>>>>> and Linux, and replaced with Warp on Windows aside from the CLI flag, >>>>>>>> and >>>>>>>> the fallback is not triggerable by an attacker on systems with a >>>>>>>> "normal" >>>>>>>> GPU, we'll be in much better shape from a security standpoint. >>>>>>>> >>>>>>>> We will update this thread with the progress and results of these >>>>>>>> experiments as they roll out. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Mar 3, 2025 at 2:27 PM Rick Byers <rby...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> +1 that providing temporary enterprise policy exceptions is standard >>>>>>>>> practice <https://www.chromium.org/developers/enterprise-changes/> >>>>>>>>> for breaking changes that we predict may have enterprise impact. >>>>>>>>> >>>>>>>>> Rick >>>>>>>>> >>>>>>>>> On Mon, Mar 3, 2025 at 2:24 PM Erik Anderson < >>>>>>>>> erik.a...@microsoft.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Geoff, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> My suggestion re: a policy was not to have one that is supported >>>>>>>>>> indefinitely. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Many high-risk deprecations have had a policy lasting for, I >>>>>>>>>> believe, as little as 3 major version releases. Having such a thing >>>>>>>>>> helps >>>>>>>>>> mitigate the concern that the risk analysis was way off (which could >>>>>>>>>> then >>>>>>>>>> mean needing to do a stable respin if your risk analysis was off). >>>>>>>>>> If a >>>>>>>>>> policy is available, impacted enterprises can quickly >>>>>>>>>> self-remediate, >>>>>>>>>> report what broke once you flip over the default, and have a little >>>>>>>>>> bit >>>>>>>>>> more of a window to plan mitigations tied to the removal of the >>>>>>>>>> policy >>>>>>>>>> (since they’d now be aware of what broke and why). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Erik >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *From:* Ken Russell <k...@chromium.org> >>>>>>>>>> *Sent:* Monday, March 3, 2025 10:39 AM >>>>>>>>>> *To:* Ashley Gullen <ash...@scirra.com> >>>>>>>>>> *Cc:* Geoff Lang <geof...@google.com>; Erik Anderson < >>>>>>>>>> erik.a...@microsoft.com>; Rick Byers <rby...@chromium.org>; >>>>>>>>>> David Adrian <dad...@google.com>; blink-dev <blin...@chromium.org>; >>>>>>>>>> geof...@chromium.org <geof...@chromium.org> >>>>>>>>>> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Remove: >>>>>>>>>> SwiftShader Fallback >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It's feasible, but a significant amount of engineering work that >>>>>>>>>> our (Chrome Graphics) team would not be able to prioritize versus >>>>>>>>>> other >>>>>>>>>> current work that would impact a larger user base. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Ken >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Feb 28, 2025 at 9:45 AM 'Ashley Gullen' via blink-dev < >>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>> Is it feasible to have SwiftShader (or WARP) run in its own >>>>>>>>>> process with a stronger sandbox? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, 28 Feb 2025 at 15:25, Geoff Lang <geof...@google.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hey Erik, Ashley, Rick, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I want to be clear that I think having high WebGL availability is >>>>>>>>>> a good thing. I don't think that users with software WebGL have a >>>>>>>>>> great >>>>>>>>>> experience but it's likely better than no availability, at least for >>>>>>>>>> drawing static things. What pushes this over the line and warrants >>>>>>>>>> this >>>>>>>>>> discussion is that JITing code in the GPU process is a huge >>>>>>>>>> vulnerability >>>>>>>>>> and is a rapidly increasing attack target. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We're investigating WARP as an alternative on Windows. You are >>>>>>>>>> right that a large portion of the SwiftShader fallback is on >>>>>>>>>> machines with >>>>>>>>>> no GPUs (headless or VMs). There are just many unknowns about the >>>>>>>>>> quality >>>>>>>>>> and security of WARP, it will take a while to be confident in such a >>>>>>>>>> change >>>>>>>>>> and it still does not resolve the issue of JITing code in the weakly >>>>>>>>>> sandboxed GPU process. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regarding corporate policy, I'd much rather have these users fall >>>>>>>>>> back in the same way as everyone else and work towards lowering the >>>>>>>>>> number >>>>>>>>>> of users in this position. It would mean supporting and testing a >>>>>>>>>> feature >>>>>>>>>> only used by enterprise users when we have no visibility into >>>>>>>>>> crashes, bugs >>>>>>>>>> or vulnerabilities that they face. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We're also disabling software fallback due to a crashes in the >>>>>>>>>> GPU driver (as opposed to blocklisted GPU). Right now any user can >>>>>>>>>> fairly >>>>>>>>>> easily trigger a GPU crash and fall back to software WebGL which >>>>>>>>>> opens up >>>>>>>>>> vulnerabilities to all users instead of the 2.7%. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Geoff >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Feb 27, 2025 at 3:28 PM Erik Anderson < >>>>>>>>>> erik.a...@microsoft.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> The initial message states that SwiftShader primarily covers >>>>>>>>>> older Windows devices. Beyond those, there are a non-trivial set of >>>>>>>>>> enterprise users that use thin clients to connect to a remote >>>>>>>>>> Windows >>>>>>>>>> device which is often running in a VM without access to a physical >>>>>>>>>> GPU. >>>>>>>>>> >>>>>>>>>> For example, this applies to the Microsoft Dev Box offering ( >>>>>>>>>> https://azure.microsoft.com/en-us/products/dev-box/). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Unfortunately, enterprise clients often turn off telemetry. So, I >>>>>>>>>> would assume any UMA-derived metrics to be undercounting the >>>>>>>>>> population. >>>>>>>>>> >>>>>>>>>> It’s likely there are certain line-of-business and/or >>>>>>>>>> consumer-oriented sites that have a hard dependency on WebGL to be >>>>>>>>>> fully >>>>>>>>>> functional. >>>>>>>>>> >>>>>>>>>> Have you considered, on Windows, targeting WARP ( >>>>>>>>>> https://learn.microsoft.com/en-us/windows/win32/direct3darticles/directx-warp) >>>>>>>>>> >>>>>>>>>> instead? I don’t know if there are other viable alternatives on >>>>>>>>>> other OSes, >>>>>>>>>> but if the primary impacted clients are Windows perhaps that would >>>>>>>>>> be a >>>>>>>>>> sufficient mitigation. >>>>>>>>>> >>>>>>>>>> To help enterprise customers reason about how much this is going >>>>>>>>>> to impact them, it would be helpful to have an enterprise policy to >>>>>>>>>> control >>>>>>>>>> this. This is a common pattern for potentially high-impact changes. >>>>>>>>>> >>>>>>>>>> In its initial phase, the policy would enable motivated >>>>>>>>>> enterprises to forcibly disable SwiftShader as a scream test. And >>>>>>>>>> after you >>>>>>>>>> switch over the default, it could enable enterprises caught unaware >>>>>>>>>> to have >>>>>>>>>> some additional window of time to plan mitigations (by re-enabling >>>>>>>>>> it via >>>>>>>>>> policy) before you proceed with fully deprecating support and remove >>>>>>>>>> the >>>>>>>>>> policy. >>>>>>>>>> >>>>>>>>>> Can you comment on if you plan to add such a policy or, if not, >>>>>>>>>> why not? >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *From:* 'Ashley Gullen' via blink-dev <blin...@chromium.org> >>>>>>>>>> *Sent:* Thursday, February 27, 2025 4:14 AM >>>>>>>>>> *To:* Rick Byers <rby...@chromium.org> >>>>>>>>>> *Cc:* David Adrian <dad...@google.com>; blink-dev < >>>>>>>>>> blin...@chromium.org>; geof...@chromium.org <geof...@chromium.org >>>>>>>>>> > >>>>>>>>>> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Remove: >>>>>>>>>> SwiftShader Fallback >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks for the response Rick, I agree with much of what you've >>>>>>>>>> said and I think your views and suggested workarounds are all >>>>>>>>>> generally >>>>>>>>>> reasonable. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I just realised I previously responded to this thread but only >>>>>>>>>> replied to David - for transparency I've copied my previous response >>>>>>>>>> below. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I can confirm all content made with Construct since about 2018 >>>>>>>>>> requires WebGL to work and will show an error message if WebGL is >>>>>>>>>> unavailable. I've included a screenshot of the message Construct >>>>>>>>>> content >>>>>>>>>> published to the web will display when WebGL is not supported, >>>>>>>>>> saying >>>>>>>>>> "Software update needed", since that has usually been the best >>>>>>>>>> advice in >>>>>>>>>> that situation in the past. As my previous message says we long ago >>>>>>>>>> removed >>>>>>>>>> any other fallback and are now likely too dependent on WebGL to >>>>>>>>>> feasibly >>>>>>>>>> reimplement a canvas2d fallback. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Some other thoughts about workarounds/mitigations: >>>>>>>>>> >>>>>>>>>> - A swiftshader WASM module would at least give us a >>>>>>>>>> workaround, but if that was something like a ~10 MB+ module it >>>>>>>>>> would be a >>>>>>>>>> very high download overhead which we'd be obligated to include in >>>>>>>>>> every >>>>>>>>>> Construct export for compatibility >>>>>>>>>> - Swiftshader could be removed from insecure origins with >>>>>>>>>> little impact to us, and using a permission policy for cross-site >>>>>>>>>> iframes >>>>>>>>>> should be straightforward to work with >>>>>>>>>> - If it helps reduce the attack surface, we could live with >>>>>>>>>> SwiftShader support for WebGL 1 only (no WebGL 2) with minimum >>>>>>>>>> capabilities >>>>>>>>>> (no extensions). >>>>>>>>>> - A permission prompt to the user is not ideal but better >>>>>>>>>> than nothing, and I imagine it would be tricky to explain to a >>>>>>>>>> normal web >>>>>>>>>> user though the prompt message (and makes obtaining a WebGL >>>>>>>>>> context >>>>>>>>>> async...) >>>>>>>>>> - Regarding getting WebGL to work on more devices, as I >>>>>>>>>> mentioned in my previous message, reviewing the GPU blocklist to >>>>>>>>>> re-enable >>>>>>>>>> WebGL for older devices if drivers have been updated or >>>>>>>>>> workarounds for >>>>>>>>>> issues can be found would help reduce the number of devices >>>>>>>>>> subject to >>>>>>>>>> SwiftShader. Being able to enable at least WebGL 1 will still >>>>>>>>>> help with >>>>>>>>>> Construct content. >>>>>>>>>> - If a software fallback can be securely implemented for >>>>>>>>>> WebGPU, Construct has a WebGPU renderer too now so that would >>>>>>>>>> give us a >>>>>>>>>> workaround (and potentially for any other WebGL content - AFAIK >>>>>>>>>> many widely >>>>>>>>>> used libraries like three.js now either support WebGPU or are >>>>>>>>>> working on it) >>>>>>>>>> >>>>>>>>>> Thanks for the consideration all. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Copy of my previous message: >>>>>>>>>> >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> OK, thanks for the information. I just want to point out that >>>>>>>>>> even stopping WebGL content for only 2.7% of users is still >>>>>>>>>> potentially >>>>>>>>>> very disruptive. Consider a web game on Poki that requires WebGL and >>>>>>>>>> gets a >>>>>>>>>> million players. With this change, now 27,000 users will see a >>>>>>>>>> "WebGL not >>>>>>>>>> supported" error message. That's then potentially a huge number of >>>>>>>>>> new >>>>>>>>>> support requests to deal with. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> For the Construct editor itself, it is around 3%, so that seems >>>>>>>>>> in line. But the key point here is that Construct is middleware: it >>>>>>>>>> is a >>>>>>>>>> tool our users develop web games in and then publish independently >>>>>>>>>> of us. >>>>>>>>>> It is much more important that WebGL works for players of those >>>>>>>>>> games than >>>>>>>>>> it does for Construct itself. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Lots of people use older Windows workstations. We've had issues >>>>>>>>>> before where for example a graphics driver bug affecting WebGL 1 >>>>>>>>>> caused a >>>>>>>>>> great deal of trouble in a South American market, even though I >>>>>>>>>> suspect it >>>>>>>>>> only affected a small percentage of devices - see >>>>>>>>>> https://issues.chromium.org/issues/40941645 which was never >>>>>>>>>> resolved. There are probably places in the world where there are >>>>>>>>>> large >>>>>>>>>> numbers of people using older Windows workstations. I fear that >>>>>>>>>> pulling >>>>>>>>>> WebGL support from those devices may result in much higher numbers >>>>>>>>>> of >>>>>>>>>> unsupported users, and many more support requests, in the specific >>>>>>>>>> markets >>>>>>>>>> where such devices are common. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is there anything that can be done to mitigate this change? Given >>>>>>>>>> SwiftShader allowed WebGL to be considered ubiquitous for many >>>>>>>>>> years, >>>>>>>>>> engines like Construct long ago removed any fallback for systems >>>>>>>>>> that do >>>>>>>>>> not support WebGL; we moved forward assuming we could rely on WebGL, >>>>>>>>>> and so >>>>>>>>>> now it's probably infeasible to bring back any fallback as we have >>>>>>>>>> too many >>>>>>>>>> key features that fundamentally require WebGL. Could SwiftShader be >>>>>>>>>> adapted >>>>>>>>>> to not use JIT? Could some other fallback be found? Could the GPU >>>>>>>>>> blocklist >>>>>>>>>> be revised to enable WebGL on as many older devices as possible? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think the number of affected users should be <1% to minimise >>>>>>>>>> the impact from such a change. At web scale 2.7% is still a lot. >>>>>>>>>> Perhaps >>>>>>>>>> with revising the GPU blocklist and adding more workarounds this is >>>>>>>>>> feasible. I fear if this goes ahead without any mitigation, it will >>>>>>>>>> cause a >>>>>>>>>> great deal of trouble and is exactly the kind of thing sceptics of >>>>>>>>>> the web >>>>>>>>>> will bring up to say that web technology sucks, browsers can't be >>>>>>>>>> trusted, >>>>>>>>>> and people should just develop desktop games instead. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, 25 Feb 2025 at 22:31, Rick Byers <rby...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> 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 < >>>>>>>>>> blin...@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 milestones >>>>>>>>>> >>>>>>>>>> Shipping 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+...@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+...@chromium.org. >>>>>>>>>> To view this discussion visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73jWBkuxvj%3DDDXmEQNwLfCa_uV5OZZ5nZJRj9ZMgP9yk7Q%40mail.gmail.com >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73jWBkuxvj%3DDDXmEQNwLfCa_uV5OZZ5nZJRj9ZMgP9yk7Q%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+...@chromium.org. >>>>>>>>>> To view this discussion visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73hYs9O-2hdmfn37fQb-U-8m_-08i3Qg9dkUhKNQQvNLSg%40mail.gmail.com >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73hYs9O-2hdmfn37fQb-U-8m_-08i3Qg9dkUhKNQQvNLSg%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/2707217c-f8fe-441a-a155-beb157b08927n%40chromium.org.
