Got it! That clears it all up for me. Thanks! On Fri, Aug 22, 2025 at 2:06 PM Geoff Lang <geoffl...@google.com> wrote:
> The experiment is currently rolled out to 1% of users. > > Geoff > > On Fri, Aug 22, 2025 at 4:40 PM Fred Potter <fpot...@gmail.com> wrote: > >> Thanks, Geoff. Those args do help me test the WARP path, and it seems to >> be working great. And, glad to hear SwiftShader is always replaced with >> WARP, and there's no case where a Windows user loses SwiftShader and >> doesn't get opted into WARP. >> >> I'm confused about why I have not organically ended up in the >> SwiftShaderDeprecation experiment yet. >> >> Is this line saying that the experiment is rolled out to 98% in STABLE? >> >> https://gist.github.com/fpotter/48395681a0ec900a27e019be9e41b323#file-gistfile1-txt-L192 >> >> On Windows, I tried disabling the Intel graphics driver to force >> "Microsoft Basic Renderer Driver". Then I tried blowing away my >> \Users\me\AppData\Local\Google directory to force experiment state to >> reset. But, I still end up with GL_RENDERER showing SwiftShader. >> >> On Friday, August 22, 2025 at 6:52:53 AM UTC-7 Geoff Lang wrote: >> >>> I'm not sure exactly how to read this file but it looks right to me: >>> disable "AllowSoftwareGLFallbackDueToCrashes" >>> disable "AllowSwiftShaderFallback" >>> enable "AllowD3D11WarpFallback" >>> >>> How are you testing? You can use >>> "--enable-features=AllowD3D11WarpFallback >>> --disable-features=AllowSoftwareGLFallbackDueToCrashes,AllowSwiftShaderFallback". >>> Other command line arguments can interfere too, things like >>> "--use-angle=swiftshader" would force it back on. >>> >>> Geoff >>> >>> On Fri, Aug 22, 2025 at 12:33 AM Fred Potter <fpo...@gmail.com> wrote: >>> >>>> Hi Folks, >>>> >>>> I tried to pull the experiment setup for SwiftShaderDeprecation, and >>>> wanted to confirm the behavior with you all to make sure I'm parsing it >>>> right -- >>>> https://gist.github.com/fpotter/48395681a0ec900a27e019be9e41b323 >>>> >>>> By my read, it looks like when SwiftShader is disabled for a Windows >>>> user, they'll always be opted into the WARP fallback at the same time. Is >>>> that right? >>>> >>>> I've been trying to test myself on v139 on Windows (in Stable, Beta, >>>> and Canary), but so far I've been unlucky and continue to get SwiftShader >>>> according to chrome://gpu. >>>> >>>> Thanks! >>>> Fred >>>> >>>> >>>> >>>> >>>> On Thursday, August 14, 2025 at 7:22:59 AM UTC-7 Geoff Lang wrote: >>>> >>>>> No plans, unfortunately. Chromium isn't set up to easily share >>>>> resources between different GL drivers right now. >>>>> >>>>> On Tue, Jul 29, 2025 at 2:00 PM PhistucK <phis...@gmail.com> wrote: >>>>> >>>>>> I am just curious... Are there any plans to add WebGL 2 software >>>>>> rendering support/fallback? My machine can use fewer and fewer >>>>>> WebGL-based >>>>>> websites because they use WebGL 2... >>>>>> >>>>>> >>>>>> ☆*PhistucK* >>>>>> >>>>>> >>>>>> On Wed, Jul 9, 2025 at 4:35 PM 'David Adrian' via blink-dev < >>>>>> blin...@chromium.org> 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+...@chromium.org. >>>>>>> To view this discussion visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2cfb0848-03a1-4cd6-9c09-7ad8026a9f3dn%40chromium.org >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2cfb0848-03a1-4cd6-9c09-7ad8026a9f3dn%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/CAFL%3DhZKC0ksdazadm377dC3yDOyOo0fKUyJH76uoUUX4B94RSg%40mail.gmail.com.
