Since the SwiftShader choice needs to be made so early in browser startup, it looks like we don't always have the server-side configs ready on first usage of a profile, I believe this is expected. After 144 the server side config will not be needed.
About the Chrome Test browser: Did WebGL work before? If yes, please file a bug. Seeing "hardware" is expected in this case, the command line flags forcefully bypass a bunch of blocklists for software drivers. Geoff On Thu, Jan 8, 2026 at 5:08 PM Ray LI <[email protected]> wrote: > Hi Geoff, > > Happy New Year and thank you for the detailed answer! They all make sense > to us, and we are really happy to hear that software rendering on Windows > and Linux will be/considered to be supported! > > I just have a quick follow-up clarification question on the first bullet > about “100% shipped to all users on Chrome v141+ since ~Nov 19.” I tested > this on a Debian machine and found that each time I did a fresh install of > Chrome, it still shows SwiftShader by default even if it’s 143. However, if > I close it and then reopen it, SwiftShader is gone. I wonder if this is due > to the Chrome Variations mechanism, since Chrome can only make a request to > the server each time we start Chrome or use it for 30 minutes? Also, I > found that Chromium and MS Edge V143 still show SwiftShader as the renderer > even if I close and reopen it. Is this because they maintain different > rollover servers? > > Another thing I would like to mention is that we found the Chrome Test > <https://developer.chrome.com/blog/chrome-for-testing> browser shows no > graphics renderer on Windows. Both SwiftShader and WARP are disabled by > default (see the attached screenshot). We have to use “chrome.exe > --use-gl=angle --use-angle=d3d11-warp” to enable WARP on Windows, and it > shows “Hardware” instead of "Software". I wonder if this is unexpected > behavior. I can create a bug report for it if so. > > Thanks, > Rui > > On Thursday, January 8, 2026 at 4:14:52 PM UTC-5 Geoff Lang wrote: > >> Hey, sorry I was on a fairly long vacation and didn't get to this before >> I left. >> >>> >>> 1. Is there a way we can track the rollout progress on a specific >>> platform (e.g., what percentage of users are experiencing SwiftShader >>> disabling on Linux)? we would like to know how much time we will have for >>> our backup plans. >>> >>> There is no public way to track that I know off-hand but I can tell >> you: It has 100% shipped to all users on Chrome v141+ since ~Nov 19. >> >>> >>> 1. In one of your responses above, you mentioned that “*WARP still >>> does not resolve the issue of JITing code in the weakly sandboxed GPU >>> process*.” However, WARP is currently replacing SwiftShader on >>> Windows machines. Does this mean you have already evaluated the security >>> level of WARP and determined that it is safer than SwiftShader? Could it >>> be >>> possible that we will also need to disable WARP in the future due to >>> JIT-related security concerns? >>> >>> We've evaluated WARP as much as we're able. The new paths are safer in a >> few ways: The D3D11 API validates much more before execution and crash >> fallback to software is disabled so it's not possible to programatically >> get a WARP based WebGL context. I can't say about the future, it's possible >> there are many unfixable security issues yet to be discovered. We have no >> plans to remove it though, supporting software WebGL on Windows remains >> important. >> >>> >>> 1. Currently, it seems that the CEF (Chromium Embedded Framework) >>> still does not have WARP enabled, even when using the flag you provided >>> above. Is this an expected behavior? >>> >>> I'm not sure how experimental flags work for CEF. I would expect it to >> be enabled after v144 though. >> >>> >>> 1. Is it safe to use llvmpipe in Chrome by applying the >>> overwrite-gpu-blocklist? >>> >>> It's currently untested so I can't comment on the safety. We'd like to >> support this path though. Just a matter of finding the time to test it >> thoroughly. >> >>> >>> 1. Are there any lightweight and easy-to-implement approaches we can >>> use to make SwiftShader more secure (e.g., disabling the JIT)? >>> 2. Will you stop maintaining SwiftShader in the future due to its >>> disabling? If yes, do you have any timelines you can share? >>> >>> SwiftShader is already (mostly) unmaintained. It has no way to disable >> the JIT as is and we would rather invest in ensuring lavapipe works well to >> support linux software rasterization. >> >> Geoff >> >> On Mon, Dec 1, 2025 at 3:50 PM Ray LI <[email protected]> wrote: >> >>> >>> Hi all, >>> >>> It’s been a while since v139 was released. We’ve noticed that some >>> Windows machines are now using WARP, and SwiftShader appears to be disabled >>> on certain Linux machines. We are currently developing some backup plans to >>> address the SwiftShader disablement. May we ask a few follow-up questions >>> we’ve encountered? >>> >>> 1. Is there a way we can track the rollout progress on a specific >>> platform (e.g., what percentage of users are experiencing SwiftShader >>> disabling on Linux)? we would like to know how much time we will have for >>> our backup plans. >>> 2. In one of your responses above, you mentioned that “*WARP still >>> does not resolve the issue of JITing code in the weakly sandboxed GPU >>> process*.” However, WARP is currently replacing SwiftShader on >>> Windows machines. Does this mean you have already evaluated the security >>> level of WARP and determined that it is safer than SwiftShader? Could it >>> be >>> possible that we will also need to disable WARP in the future due to >>> JIT-related security concerns? >>> 3. Currently, it seems that the CEF (Chromium Embedded Framework) >>> still does not have WARP enabled, even when using the flag you provided >>> above. Is this an expected behavior? >>> 4. Is it safe to use llvmpipe in Chrome by applying the >>> overwrite-gpu-blocklist? >>> 5. Are there any lightweight and easy-to-implement approaches we can >>> use to make SwiftShader more secure (e.g., disabling the JIT)? >>> 6. Will you stop maintaining SwiftShader in the future due to its >>> disabling? If yes, do you have any timelines you can share? >>> >>> Thanks! >>> Ray >>> On Monday, September 15, 2025 at 7:28:55 PM UTC-4 Matt George wrote: >>> >>>> 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/CA%2BPGBXvxsM9G58mN7_mVQcxPZi9J5_O0xTJNep3i%2B_oSTjBVHA%40mail.gmail.com.
