Sure -- just opened https://issues.chromium.org/issues/445215592.
Matt On Wednesday, September 10, 2025 at 8:52:21 AM UTC-7 Geoff Lang wrote: > Hey, sorry for the slow reply. > > Could you file a bug at crbug.com about this and link it to me? It will > be easier to continue specific discussions there. Looks like WARP fallback > is working but WebGL is blocklisted for some other reason when it shouldn't > be. > > Geoff > > On Thu, Sep 4, 2025 at 2:02 AM Fred Potter <[email protected]> wrote: > >> Matt, I'm seeing similar. >> >> Repro steps: >> >> 1/ Uninstall graphics driver for integrated Intel graphics using Device >> Manager. Reboot. On reboot, observe Device Manager reports graphics now >> as "Microsoft Basic Display Adapter". >> >> 2/ Run "c:\Program Files\Google\Chrome\Application\chrome.exe" >> --enable-features=AllowD3D11WarpFallback >> --disable-features=AllowSoftwareGLFallbackDueToCrashes,AllowSwiftShaderFallback >> >> 3/ Open chrome://gpu >> >> Observe WebGL shows as Unavailable. "Display type" shows as ANGLE_D3D11 >> rather than ANGLE_D3D11_WARP. >> >> Interestingly, if I open chrome://settings/system, and switch "Use >> graphics acceleration when available" to disabled and relaunch, WARP will >> activate. chrome://gpu will report WebGL as "Software only" and "Display >> type" will show as ANGLE_D3D11_WARP. >> >> Is it expected that WARP will only activate if "Use graphics acceleration >> when available" is disabled? I worry a lot of our customers will have this >> defaulted to enabled even with missing GPU drivers, and possibly may not >> have access to toggle if the machine is sufficiently locked down. >> >> The old / current behavior is that SwiftShader will activate under >> "Microsoft Basic Display Adapter" even if "Use graphics acceleration when >> available" is enabled. >> >> On Wednesday, September 3, 2025 at 1:01:25 PM UTC-7 RUI LI wrote: >> >>> Hi Geoff, >>> >>> Got it! Thank you so much for the detailed explanation. Things are much >>> clearer to us now! >>> >>> Thanks, >>> Rui >>> >>> On Tuesday, September 2, 2025 at 1:42:23 PM UTC-4 Geoff Lang wrote: >>> >>>> Hey, >>>> >>>> Chrome can roll out features with server-side configurations to do A/B >>>> comparisons or fix breakages without re-releasing, that's what's happening >>>> here. Starting in 139, some users are opted into the deprecation. More >>>> will >>>> be opted in over time until 100%. >>>> >>>> We're considering unblocking llvmpipe but it needs a lot more testing. >>>> It has a lot of version variance compared to WARP and is more difficult to >>>> test. It will also need some small architectural changes to use it for >>>> WebGL only while the rest of the browser uses software rasterization. >>>> >>>> If WARP is unavailable on Windows, there will be no software WebGL >>>> fallback. I have never seen this happen but it may be possible if the user >>>> has found a way to explicitly disable WARP. >>>> >>>> No software rendering alternatives are planned except continuing to >>>> investigate the mesa software renderers. >>>> >>>> No plans to remove SwiftShader, it will remain available by command >>>> line flag. The timeline of disabling SwiftShader fallback on Windows is >>>> the >>>> same as the other OSs except it's replaced by WARP there. >>>> >>>> Geoff >>>> >>>> On Wed, Aug 27, 2025 at 10:29 PM RUI LI <[email protected]> wrote: >>>> >>>>> Hi Geoff, thank you so much for your responses! To provide more >>>>> context, I work at a company where tens of thousands of our users >>>>> currently >>>>> fall back to SwiftShader based on our analytics. This deprecation/removal >>>>> would pose a huge impact to us, so we want to be fully prepared and >>>>> ensure >>>>> a smooth transition strategy. I have a few follow-up questions below and >>>>> would appreciate any further clarification: >>>>> >>>>> - Regarding your comment, “*the rollout is happening slowly within >>>>> the 139 release,*” could you please elaborate on what “*the >>>>> rollout is happening slowly*” means? >>>>> >>>>> >>>>> - On the topic of Linux software alternatives, you mentioned: “*It’s >>>>> unlikely that Chrome can ship with its own packaged lavapipe, but I >>>>> want to >>>>> make sure it’s used if it’s installed already.”* Should we expect >>>>> that on Linux, once SwiftShader is disabled, Chrome may fallback to >>>>> lavapipe (Vulkan-based) if it’s available? I am also curious if there >>>>> are >>>>> specific reasons why llvmpipe (OpenGL-based) is blocked via the >>>>> software_rendering_list.json (unlike Firefox, which allows it) — is >>>>> this >>>>> due to security or stability issues? >>>>> >>>>> >>>>> - David mentioned that you are currently “*Replacing SwiftShader >>>>> with WARP on Windows.*” If I’m understanding correctly, >>>>> SwiftShader will only be disabled on Windows when the WARP replacement >>>>> is >>>>> ready, so there will be no gap in software rendering support. Is that >>>>> accurate? >>>>> >>>>> >>>>> - We would also like to know if there are any other software >>>>> rendering alternatives currently planned. We ask this because we would >>>>> like >>>>> to evaluate/test these renderers to ensure our WebGL programs will >>>>> still >>>>> work. >>>>> >>>>> >>>>> - Lastly, I know this may be unplanned, but I just wanted to >>>>> check: do you have any timeline for when (and in which version) >>>>> SwiftShader >>>>> might be disabled on Windows? And when SwiftShader will be removed >>>>> entirely? >>>>> >>>>> Thanks! >>>>> On Wednesday, August 27, 2025 at 10:04:18 AM UTC-4 Geoff Lang wrote: >>>>> >>>>>> It is the expected behaviour. The rollout is happening slowly within >>>>>> the 139 release. >>>>>> >>>>>> There are no plans for a default software fallback on Linux right now >>>>>> but we're thinking about the issue. I think it's unlikely that Chrome >>>>>> can >>>>>> ship with its own packaged lavapipe but I want to make sure it's used if >>>>>> it's installed already. You can also bypass the deprecation using >>>>>> command >>>>>> line flags, this is an important path to maintain for web developers and >>>>>> automated testing. >>>>>> >>>>>> Geoff >>>>>> >>>>>> On Mon, Aug 25, 2025 at 8:11 PM RUI LI <[email protected]> wrote: >>>>>> >>>>>>> Hi David and other folks, >>>>>>> >>>>>>> I am testing SwiftShader on a Debian 12 machine without hardware >>>>>>> acceleration. It seems that SwiftShader is still enabled (I saw >>>>>>> swiftshader >>>>>>> in Chrome://gpu) in Chrome 139. Is this the expected behavior? >>>>>>> >>>>>>> Also, I am curious about software rendering alternatives on Linux >>>>>>> machines. Similar to WARP, do you have any plans to replace SwiftShader >>>>>>> with MESA llvmpipe on Linux? I know there are also some Linux VM users >>>>>>> who >>>>>>> might also be affected by this removal. >>>>>>> >>>>>>> Thanks! >>>>>>> Rui >>>>>>> >>>>>>> On Wednesday, July 9, 2025 at 11:35:32 AM UTC-4 David Adrian wrote: >>>>>>> >>>>>>>> An update: We added an enterprise policy >>>>>>>> <https://chromeenterprise.google/policies/#EnableUnsafeSwiftShader> >>>>>>>> that allows users to re-enable Swiftshader. This should help with the >>>>>>>> managed VM / remote desktop use-case. >>>>>>>> >>>>>>>> In Chrome 139, we will start experimenting (via Finch/partial >>>>>>>> deployments) with: >>>>>>>> >>>>>>>> - Removing Swiftshader support on MacOS and Linux >>>>>>>> - Replacing Swiftshader with WARP on Windows >>>>>>>> - Removing the OOM fallback to Swiftshader/WARP, so that it is >>>>>>>> not attacker-triggerable on arbitrary devices >>>>>>>> >>>>>>>> >>>>>>>> On Thursday, April 24, 2025 at 9:55:58 AM UTC-4 David Adrian wrote: >>>>>>>> >>>>>>>>> As it stands now, we are hopeful we can swap out to WARP on >>>>>>>>> Windows without any drop in coverage for software rendering (i.e. >>>>>>>>> simultaneously with removing SwiftShader). Experimental support and >>>>>>>>> testing >>>>>>>>> for this will begin in Chrome 137. >>>>>>>>> >>>>>>>>> On Thursday, April 10, 2025 at 12:47:33 PM UTC-4 Julie Powell >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> WebGL emulation is critical for many US entities that are running >>>>>>>>>> thin client machines which don’t have access to a GPU. So far, the >>>>>>>>>> organizations we’ve spoken to are on Windows so simultaneously >>>>>>>>>> putting an >>>>>>>>>> automatic fallback to WARP in place once the fallback to SwiftShader >>>>>>>>>> is >>>>>>>>>> removed – avoiding a period of time when a command line override >>>>>>>>>> would be >>>>>>>>>> required – will allow them to continue operating. We have verified >>>>>>>>>> that the >>>>>>>>>> following organizations are dependent on this capability (note that >>>>>>>>>> there >>>>>>>>>> are many more outside of this list, both in the private and public >>>>>>>>>> sector): >>>>>>>>>> Department of the Interior Bureau of Land Management, Office of >>>>>>>>>> Wildland >>>>>>>>>> Fire, National Park Service, U.S. Geologic Survey, U.S. Fish and >>>>>>>>>> Wildlife >>>>>>>>>> Service, Bureau of Indian Affairs, Air Force DCGS, Army Tactical >>>>>>>>>> Edge Node, >>>>>>>>>> DCGS-Army, DCGS-USMC, USMC, USAF, USDA, NGA, DIA, Census, DHS, CISA, >>>>>>>>>> FirstNet/NTIA (Commerce), NCIS, DTRA, STRATCOM, EUCOM, Idaho >>>>>>>>>> National >>>>>>>>>> Guard, some universities, K-12 schools, National Geographic, and >>>>>>>>>> more. >>>>>>>>>> >>>>>>>>>> I am working with colleagues and international distributors to >>>>>>>>>> gauge the usage of VMs running Linux which are doing web mapping and >>>>>>>>>> don’t >>>>>>>>>> have access to GPU resources. I will come back with an update when I >>>>>>>>>> have >>>>>>>>>> one. >>>>>>>>>> >>>>>>>>>> On Monday, March 24, 2025 at 12:56:08 PM UTC-7 Matt George wrote: >>>>>>>>>> >>>>>>>>>>> Hi Rick, AFAIK it's only Windows, but currently reaching out to >>>>>>>>>>> see if it's different for our distributors in Europe. >>>>>>>>>>> >>>>>>>>>>> Matt >>>>>>>>>>> On Monday, March 24, 2025 at 10:38:19 AM UTC-7 Rick Byers wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks for chiming in Matt. Is the scenario you described >>>>>>>>>>>> Windows-only (in which case we should be good with WARP), or also >>>>>>>>>>>> Linux? >>>>>>>>>>>> >>>>>>>>>>>> Rick >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 24, 2025 at 1:22 PM Matt George <[email protected]> >>>>>>>>>>>> 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 <[email protected]> >>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>>>>>>>>>> *Sent:* Monday, March 3, 2025 10:39 AM >>>>>>>>>>>>>>>>> *To:* Ashley Gullen <[email protected]> >>>>>>>>>>>>>>>>> *Cc:* Geoff Lang <[email protected]>; Erik Anderson < >>>>>>>>>>>>>>>>> [email protected]>; Rick Byers <[email protected]>; >>>>>>>>>>>>>>>>> David Adrian <[email protected]>; blink-dev < >>>>>>>>>>>>>>>>> [email protected]>; [email protected] < >>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>> *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 <[email protected]> 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 < >>>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>> *Sent:* Thursday, February 27, 2025 4:14 AM >>>>>>>>>>>>>>>>> *To:* Rick Byers <[email protected]> >>>>>>>>>>>>>>>>> *Cc:* David Adrian <[email protected]>; blink-dev < >>>>>>>>>>>>>>>>> [email protected]>; [email protected] < >>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>> *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 < >>>>>>>>>>>>>>>>> [email protected]> 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 <[email protected]> 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 >>>>>>>>>>>>>>>>> [email protected] 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 >>>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [email protected], [email protected] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>>>>>>> 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0ce220e3-f2e8-4e2b-9b53-ec854320783an%40chromium.org.
