Great, thank you Matt! Rick
On Mon, Mar 24, 2025 at 2:25 PM Matt George <mattmg...@gmail.com> 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/CAFUtAY8880ooYC4xPUF7iFZGyMppruDVk_o6gDgRCCF%3DnwpiWQ%40mail.gmail.com.
