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/CA%2BPGBXuNUkzoceK7kS%2BP72SFfCB%3D41qm-rz2iMWN08h_dkHFHw%40mail.gmail.com.
