The experiment is currently rolled out to 1% of users.

Geoff

On Fri, Aug 22, 2025 at 4:40 PM Fred Potter <fpot...@gmail.com> wrote:

> Thanks, Geoff.  Those args do help me test the WARP path, and it seems to
> be working great.  And, glad to hear SwiftShader is always replaced with
> WARP, and there's no case where a Windows user loses SwiftShader and
> doesn't get opted into WARP.
>
> I'm confused about why I have not organically ended up in the
> SwiftShaderDeprecation experiment yet.
>
> Is this line saying that the experiment is rolled out to 98% in STABLE?
>
> https://gist.github.com/fpotter/48395681a0ec900a27e019be9e41b323#file-gistfile1-txt-L192
>
> On Windows, I tried disabling the Intel graphics driver to force
> "Microsoft Basic Renderer Driver".  Then I tried blowing away my
> \Users\me\AppData\Local\Google directory to force experiment state to
> reset.  But, I still end up with GL_RENDERER showing SwiftShader.
>
> On Friday, August 22, 2025 at 6:52:53 AM UTC-7 Geoff Lang wrote:
>
>> I'm not sure exactly how to read this file but it looks right to me:
>> disable "AllowSoftwareGLFallbackDueToCrashes"
>> disable "AllowSwiftShaderFallback"
>> enable "AllowD3D11WarpFallback"
>>
>> How are you testing? You can use
>> "--enable-features=AllowD3D11WarpFallback
>> --disable-features=AllowSoftwareGLFallbackDueToCrashes,AllowSwiftShaderFallback".
>> Other command line arguments can interfere too, things like
>> "--use-angle=swiftshader" would force it back on.
>>
>> Geoff
>>
>> On Fri, Aug 22, 2025 at 12:33 AM Fred Potter <fpo...@gmail.com> wrote:
>>
>>> Hi Folks,
>>>
>>> I tried to pull the experiment setup for SwiftShaderDeprecation, and
>>> wanted to confirm the behavior with you all to make sure I'm parsing it
>>> right --
>>> https://gist.github.com/fpotter/48395681a0ec900a27e019be9e41b323
>>>
>>> By my read, it looks like when SwiftShader is disabled for a Windows
>>> user, they'll always be opted into the WARP fallback at the same time.  Is
>>> that right?
>>>
>>> I've been trying to test myself on v139 on Windows (in Stable, Beta, and
>>> Canary), but so far I've been unlucky and continue to get SwiftShader
>>> according to chrome://gpu.
>>>
>>> Thanks!
>>> Fred
>>>
>>>
>>>
>>>
>>> On Thursday, August 14, 2025 at 7:22:59 AM UTC-7 Geoff Lang wrote:
>>>
>>>> No plans, unfortunately. Chromium isn't set up to easily share
>>>> resources between different GL drivers right now.
>>>>
>>>> On Tue, Jul 29, 2025 at 2:00 PM PhistucK <phis...@gmail.com> wrote:
>>>>
>>>>> I am just curious... Are there any plans to add WebGL 2 software
>>>>> rendering support/fallback? My machine can use fewer and fewer WebGL-based
>>>>> websites because they use WebGL 2...
>>>>>
>>>>>
>>>>> ☆*PhistucK*
>>>>>
>>>>>
>>>>> On Wed, Jul 9, 2025 at 4:35 PM 'David Adrian' via blink-dev <
>>>>> blin...@chromium.org> wrote:
>>>>>
>>>>>> An update: We added an enterprise policy
>>>>>> <https://chromeenterprise.google/policies/#EnableUnsafeSwiftShader>
>>>>>> that allows users to re-enable Swiftshader. This should help with the
>>>>>> managed VM / remote desktop use-case.
>>>>>>
>>>>>> In Chrome 139, we will start experimenting (via Finch/partial
>>>>>> deployments) with:
>>>>>>
>>>>>>    - Removing Swiftshader support on MacOS and Linux
>>>>>>    - Replacing Swiftshader with WARP on Windows
>>>>>>    - Removing the OOM fallback to Swiftshader/WARP, so that it is
>>>>>>    not attacker-triggerable on arbitrary devices
>>>>>>
>>>>>>
>>>>>> On Thursday, April 24, 2025 at 9:55:58 AM UTC-4 David Adrian wrote:
>>>>>>
>>>>>>> As it stands now, we are hopeful we can swap out to WARP on Windows
>>>>>>> without any drop in coverage for software rendering (i.e. simultaneously
>>>>>>> with removing SwiftShader). Experimental support and testing for this 
>>>>>>> will
>>>>>>> begin in Chrome 137.
>>>>>>>
>>>>>>> On Thursday, April 10, 2025 at 12:47:33 PM UTC-4 Julie Powell wrote:
>>>>>>>
>>>>>>>> WebGL emulation is critical for many US entities that are running
>>>>>>>> thin client machines which don’t have access to a GPU. So far, the
>>>>>>>> organizations we’ve spoken to are on Windows so simultaneously putting 
>>>>>>>> an
>>>>>>>> automatic fallback to WARP in place once the fallback to SwiftShader is
>>>>>>>> removed – avoiding a period of time when a command line override would 
>>>>>>>> be
>>>>>>>> required – will allow them to continue operating. We have verified 
>>>>>>>> that the
>>>>>>>> following organizations are dependent on this capability (note that 
>>>>>>>> there
>>>>>>>> are many more outside of this list, both in the private and public 
>>>>>>>> sector):
>>>>>>>> Department of the Interior Bureau of Land Management, Office of 
>>>>>>>> Wildland
>>>>>>>> Fire, National Park Service, U.S. Geologic Survey, U.S. Fish and 
>>>>>>>> Wildlife
>>>>>>>> Service, Bureau of Indian Affairs, Air Force DCGS, Army Tactical Edge 
>>>>>>>> Node,
>>>>>>>> DCGS-Army, DCGS-USMC, USMC, USAF, USDA, NGA, DIA, Census, DHS, CISA,
>>>>>>>> FirstNet/NTIA (Commerce), NCIS, DTRA, STRATCOM, EUCOM, Idaho National
>>>>>>>> Guard, some universities, K-12 schools, National Geographic, and more.
>>>>>>>>
>>>>>>>> I am working with colleagues and international distributors to
>>>>>>>> gauge the usage of VMs running Linux which are doing web mapping and 
>>>>>>>> don’t
>>>>>>>> have access to GPU resources. I will come back with an update when I 
>>>>>>>> have
>>>>>>>> one.
>>>>>>>>
>>>>>>>> On Monday, March 24, 2025 at 12:56:08 PM UTC-7 Matt George wrote:
>>>>>>>>
>>>>>>>>> Hi Rick, AFAIK it's only Windows, but currently reaching out to
>>>>>>>>> see if it's different for our distributors in Europe.
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>> On Monday, March 24, 2025 at 10:38:19 AM UTC-7 Rick Byers wrote:
>>>>>>>>>
>>>>>>>>>> Thanks for chiming in Matt. Is the scenario you described
>>>>>>>>>> Windows-only (in which case we should be good with WARP), or also 
>>>>>>>>>> Linux?
>>>>>>>>>>
>>>>>>>>>> Rick
>>>>>>>>>>
>>>>>>>>>> On Mon, Mar 24, 2025 at 1:22 PM Matt George <matt...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Very happy to hear about exploring the use of WARP on windows.
>>>>>>>>>>>
>>>>>>>>>>> Just wanted to chime in that from the Esri perspective, we also
>>>>>>>>>>> have a large number of users accessing our maps SDK from VMs 
>>>>>>>>>>> without a GPU.
>>>>>>>>>>> This is done for security reasons, & not uncommon for public sector
>>>>>>>>>>> clients. We have a special codepath where when we detect software 
>>>>>>>>>>> emulation
>>>>>>>>>>> is being used, we only render every X frames & then use css 
>>>>>>>>>>> transforms
>>>>>>>>>>> in-between. This is fairly usable, though of course it's a much 
>>>>>>>>>>> worse
>>>>>>>>>>> experience than having a GPU.
>>>>>>>>>>>
>>>>>>>>>> On Tuesday, March 11, 2025 at 1:11:42 AM UTC-7 Ashley Gullen
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the update David - that sounds like a much less
>>>>>>>>>>>> disruptive approach than removing it completely.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 10 Mar 2025 at 19:26, David Adrian <dad...@google.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> To cover the testing use case, we have provided a CLI flag to
>>>>>>>>>>>>> enable SwiftShader. This has been in the release notes since 
>>>>>>>>>>>>> November. If
>>>>>>>>>>>>> this is insufficient, we could add an enterprise policy.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, rather than attempt a straight removal, we are going
>>>>>>>>>>>>> to take a multi-pronged approach to attempt to simultaneously 
>>>>>>>>>>>>> reduce the
>>>>>>>>>>>>> situations where SwiftShader is available, while maintaining
>>>>>>>>>>>>> compatibility with devices that require it due to the GPU 
>>>>>>>>>>>>> blocklist.
>>>>>>>>>>>>>
>>>>>>>>>>>>>    - SwiftShader is already unused on many Mac clients, since
>>>>>>>>>>>>>    it does not support ARM. We will run an experiment where we 
>>>>>>>>>>>>> fully remove it
>>>>>>>>>>>>>    on Mac, where usage is much smaller. We expect this will be 
>>>>>>>>>>>>> ~fine.
>>>>>>>>>>>>>    - Similarly, we will try the same on Linux, although this
>>>>>>>>>>>>>    may not go as well, as there are not a large number of ARM 
>>>>>>>>>>>>> Linux clients.
>>>>>>>>>>>>>    - We will experiment with removing the automatic fallback
>>>>>>>>>>>>>    to SwiftShader after 3 OOMs, limiting it to just the devices 
>>>>>>>>>>>>> without a GPU
>>>>>>>>>>>>>    or on the GPU blocklist. This should reduce the attack surface 
>>>>>>>>>>>>> across the
>>>>>>>>>>>>>    board, as attackers would be unable to arbitrarily cause 
>>>>>>>>>>>>> SwiftShader to be
>>>>>>>>>>>>>    used. In conjunction with this, we'll see if we can leverage 
>>>>>>>>>>>>> Warp on
>>>>>>>>>>>>>    Windows.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we can get to a state where SwiftShader is off by default
>>>>>>>>>>>>> on Mac and Linux, and replaced with Warp on Windows aside from 
>>>>>>>>>>>>> the CLI
>>>>>>>>>>>>> flag, and the fallback is not triggerable by an attacker on 
>>>>>>>>>>>>> systems with a
>>>>>>>>>>>>> "normal" GPU, we'll be in much better shape from a security 
>>>>>>>>>>>>> standpoint.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We will update this thread with the progress and results of
>>>>>>>>>>>>> these experiments as they roll out.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Mar 3, 2025 at 2:27 PM Rick Byers <rby...@chromium.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> +1 that providing temporary enterprise policy exceptions is 
>>>>>>>>>>>>>> standard
>>>>>>>>>>>>>> practice
>>>>>>>>>>>>>> <https://www.chromium.org/developers/enterprise-changes/>
>>>>>>>>>>>>>> for breaking changes that we predict may have enterprise impact.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Rick
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Mar 3, 2025 at 2:24 PM Erik Anderson <
>>>>>>>>>>>>>> erik.a...@microsoft.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Geoff,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My suggestion re: a policy was not to have one that is
>>>>>>>>>>>>>>> supported indefinitely.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Many high-risk deprecations have had a policy lasting for, I
>>>>>>>>>>>>>>> believe, as little as 3 major version releases. Having such a 
>>>>>>>>>>>>>>> thing helps
>>>>>>>>>>>>>>> mitigate the concern that the risk analysis was way off (which 
>>>>>>>>>>>>>>> could then
>>>>>>>>>>>>>>> mean needing to do a stable respin if your risk analysis was 
>>>>>>>>>>>>>>> off). If a
>>>>>>>>>>>>>>> policy is available, impacted enterprises can quickly 
>>>>>>>>>>>>>>> self-remediate,
>>>>>>>>>>>>>>> report what broke once you flip over the default, and have a 
>>>>>>>>>>>>>>> little bit
>>>>>>>>>>>>>>> more of a window to plan mitigations tied to the removal of the 
>>>>>>>>>>>>>>> policy
>>>>>>>>>>>>>>> (since they’d now be aware of what broke and why).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Erik
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *From:* Ken Russell <k...@chromium.org>
>>>>>>>>>>>>>>> *Sent:* Monday, March 3, 2025 10:39 AM
>>>>>>>>>>>>>>> *To:* Ashley Gullen <ash...@scirra.com>
>>>>>>>>>>>>>>> *Cc:* Geoff Lang <geof...@google.com>; Erik Anderson <
>>>>>>>>>>>>>>> erik.a...@microsoft.com>; Rick Byers <rby...@chromium.org>;
>>>>>>>>>>>>>>> David Adrian <dad...@google.com>; blink-dev <
>>>>>>>>>>>>>>> blin...@chromium.org>; geof...@chromium.org <
>>>>>>>>>>>>>>> geof...@chromium.org>
>>>>>>>>>>>>>>> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Remove:
>>>>>>>>>>>>>>> SwiftShader Fallback
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It's feasible, but a significant amount of engineering work
>>>>>>>>>>>>>>> that our (Chrome Graphics) team would not be able to prioritize 
>>>>>>>>>>>>>>> versus
>>>>>>>>>>>>>>> other current work that would impact a larger user base.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Ken
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Feb 28, 2025 at 9:45 AM 'Ashley Gullen' via
>>>>>>>>>>>>>>> blink-dev <blin...@chromium.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is it feasible to have SwiftShader (or WARP) run in its own
>>>>>>>>>>>>>>> process with a stronger sandbox?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, 28 Feb 2025 at 15:25, Geoff Lang <geof...@google.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hey Erik, Ashley, Rick,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I want to be clear that I think having high WebGL
>>>>>>>>>>>>>>> availability is a good thing. I don't think that users with 
>>>>>>>>>>>>>>> software WebGL
>>>>>>>>>>>>>>> have a great experience but it's likely better than no 
>>>>>>>>>>>>>>> availability, at
>>>>>>>>>>>>>>> least for drawing static things. What pushes this over the line 
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> warrants this discussion is that JITing code in the GPU process 
>>>>>>>>>>>>>>> is a huge
>>>>>>>>>>>>>>> vulnerability and is a rapidly increasing attack target.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We're investigating WARP as an alternative on Windows. You
>>>>>>>>>>>>>>> are right that a large portion of the SwiftShader fallback is 
>>>>>>>>>>>>>>> on machines
>>>>>>>>>>>>>>> with no GPUs (headless or VMs). There are just many unknowns 
>>>>>>>>>>>>>>> about the
>>>>>>>>>>>>>>> quality and security of WARP, it will take a while to be 
>>>>>>>>>>>>>>> confident in such
>>>>>>>>>>>>>>> a change and it still does not resolve the issue of JITing code 
>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>> weakly sandboxed GPU process.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regarding corporate policy, I'd much rather have these users
>>>>>>>>>>>>>>> fall back in the same way as everyone else and work towards 
>>>>>>>>>>>>>>> lowering
>>>>>>>>>>>>>>> the number of users in this position.  It would mean supporting 
>>>>>>>>>>>>>>> and testing
>>>>>>>>>>>>>>> a feature only used by enterprise users when we have no 
>>>>>>>>>>>>>>> visibility into
>>>>>>>>>>>>>>> crashes, bugs or vulnerabilities that they face.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We're also disabling software fallback due to a crashes in
>>>>>>>>>>>>>>> the GPU driver (as opposed to blocklisted GPU). Right now any 
>>>>>>>>>>>>>>> user can
>>>>>>>>>>>>>>> fairly easily trigger a GPU crash and fall back to software 
>>>>>>>>>>>>>>> WebGL which
>>>>>>>>>>>>>>> opens up vulnerabilities to all users instead of the 2.7%.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Geoff
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Feb 27, 2025 at 3:28 PM Erik Anderson <
>>>>>>>>>>>>>>> erik.a...@microsoft.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The initial message states that SwiftShader primarily covers
>>>>>>>>>>>>>>> older Windows devices. Beyond those, there are a non-trivial 
>>>>>>>>>>>>>>> set of
>>>>>>>>>>>>>>> enterprise users that use thin clients to connect to a remote 
>>>>>>>>>>>>>>> Windows
>>>>>>>>>>>>>>> device which is often running in a VM without access to a 
>>>>>>>>>>>>>>> physical GPU.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For example, this applies to the Microsoft Dev Box offering (
>>>>>>>>>>>>>>> https://azure.microsoft.com/en-us/products/dev-box/).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Unfortunately, enterprise clients often turn off telemetry.
>>>>>>>>>>>>>>> So, I would assume any UMA-derived metrics to be undercounting 
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> population.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It’s likely there are certain line-of-business and/or
>>>>>>>>>>>>>>> consumer-oriented sites that have a hard dependency on WebGL to 
>>>>>>>>>>>>>>> be fully
>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Have you considered, on Windows, targeting WARP (
>>>>>>>>>>>>>>> https://learn.microsoft.com/en-us/windows/win32/direct3darticles/directx-warp)
>>>>>>>>>>>>>>> instead? I don’t know if there are other viable alternatives on 
>>>>>>>>>>>>>>> other OSes,
>>>>>>>>>>>>>>> but if the primary impacted clients are Windows perhaps that 
>>>>>>>>>>>>>>> would be a
>>>>>>>>>>>>>>> sufficient mitigation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To help enterprise customers reason about how much this is
>>>>>>>>>>>>>>> going to impact them, it would be helpful to have an enterprise 
>>>>>>>>>>>>>>> policy to
>>>>>>>>>>>>>>> control this. This is a common pattern for potentially 
>>>>>>>>>>>>>>> high-impact changes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In its initial phase, the policy would enable motivated
>>>>>>>>>>>>>>> enterprises to forcibly disable SwiftShader as a scream test. 
>>>>>>>>>>>>>>> And after you
>>>>>>>>>>>>>>> switch over the default, it could enable enterprises caught 
>>>>>>>>>>>>>>> unaware to have
>>>>>>>>>>>>>>> some additional window of time to plan mitigations (by 
>>>>>>>>>>>>>>> re-enabling it via
>>>>>>>>>>>>>>> policy) before you proceed with fully deprecating support and 
>>>>>>>>>>>>>>> remove the
>>>>>>>>>>>>>>> policy.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you comment on if you plan to add such a policy or, if
>>>>>>>>>>>>>>> not, why not?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *From:* 'Ashley Gullen' via blink-dev <blin...@chromium.org>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Sent:* Thursday, February 27, 2025 4:14 AM
>>>>>>>>>>>>>>> *To:* Rick Byers <rby...@chromium.org>
>>>>>>>>>>>>>>> *Cc:* David Adrian <dad...@google.com>; blink-dev <
>>>>>>>>>>>>>>> blin...@chromium.org>; geof...@chromium.org <
>>>>>>>>>>>>>>> geof...@chromium.org>
>>>>>>>>>>>>>>> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Remove:
>>>>>>>>>>>>>>> SwiftShader Fallback
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for the response Rick, I agree with much of what
>>>>>>>>>>>>>>> you've said and I think your views and suggested workarounds 
>>>>>>>>>>>>>>> are all
>>>>>>>>>>>>>>> generally reasonable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I just realised I previously responded to this thread but
>>>>>>>>>>>>>>> only replied to David - for transparency I've copied my 
>>>>>>>>>>>>>>> previous response
>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can confirm all content made with Construct since about
>>>>>>>>>>>>>>> 2018 requires WebGL to work and will show an error message if 
>>>>>>>>>>>>>>> WebGL is
>>>>>>>>>>>>>>> unavailable. I've included a screenshot of the message 
>>>>>>>>>>>>>>> Construct content
>>>>>>>>>>>>>>> published to the web will display when WebGL is not supported, 
>>>>>>>>>>>>>>> saying
>>>>>>>>>>>>>>> "Software update needed", since that has usually been the best 
>>>>>>>>>>>>>>> advice in
>>>>>>>>>>>>>>> that situation in the past. As my previous message says we long 
>>>>>>>>>>>>>>> ago removed
>>>>>>>>>>>>>>> any other fallback and are now likely too dependent on WebGL to 
>>>>>>>>>>>>>>> feasibly
>>>>>>>>>>>>>>> reimplement a canvas2d fallback.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Some other thoughts about workarounds/mitigations:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    - A swiftshader WASM module would at least give us a
>>>>>>>>>>>>>>>    workaround, but if that was something like a ~10 MB+ module 
>>>>>>>>>>>>>>> it would be a
>>>>>>>>>>>>>>>    very high download overhead which we'd be obligated to 
>>>>>>>>>>>>>>> include in every
>>>>>>>>>>>>>>>    Construct export for compatibility
>>>>>>>>>>>>>>>    - Swiftshader could be removed from insecure origins
>>>>>>>>>>>>>>>    with little impact to us, and using a permission policy for 
>>>>>>>>>>>>>>> cross-site
>>>>>>>>>>>>>>>    iframes should be straightforward to work with
>>>>>>>>>>>>>>>    - If it helps reduce the attack surface, we could live
>>>>>>>>>>>>>>>    with SwiftShader support for WebGL 1 only (no WebGL 2) with 
>>>>>>>>>>>>>>> minimum
>>>>>>>>>>>>>>>    capabilities (no extensions).
>>>>>>>>>>>>>>>    - A permission prompt to the user is not ideal but
>>>>>>>>>>>>>>>    better than nothing, and I imagine it would be tricky to 
>>>>>>>>>>>>>>> explain to a
>>>>>>>>>>>>>>>    normal web user though the prompt message (and makes 
>>>>>>>>>>>>>>> obtaining a WebGL
>>>>>>>>>>>>>>>    context async...)
>>>>>>>>>>>>>>>    - Regarding getting WebGL to work on more devices, as I
>>>>>>>>>>>>>>>    mentioned in my previous message, reviewing the GPU 
>>>>>>>>>>>>>>> blocklist to re-enable
>>>>>>>>>>>>>>>    WebGL for older devices if drivers have been updated or 
>>>>>>>>>>>>>>> workarounds for
>>>>>>>>>>>>>>>    issues can be found would help reduce the number of devices 
>>>>>>>>>>>>>>> subject to
>>>>>>>>>>>>>>>    SwiftShader. Being able to enable at least WebGL 1 will 
>>>>>>>>>>>>>>> still help with
>>>>>>>>>>>>>>>    Construct content.
>>>>>>>>>>>>>>>    - If a software fallback can be securely implemented for
>>>>>>>>>>>>>>>    WebGPU, Construct has a WebGPU renderer too now so that 
>>>>>>>>>>>>>>> would give us a
>>>>>>>>>>>>>>>    workaround (and potentially for any other WebGL content - 
>>>>>>>>>>>>>>> AFAIK many widely
>>>>>>>>>>>>>>>    used libraries like three.js now either support WebGPU or 
>>>>>>>>>>>>>>> are working on it)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for the consideration all.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Copy of my previous message:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OK, thanks for the information. I just want to point out
>>>>>>>>>>>>>>> that even stopping WebGL content for only 2.7% of users is still
>>>>>>>>>>>>>>> potentially very disruptive. Consider a web game on Poki that 
>>>>>>>>>>>>>>> requires
>>>>>>>>>>>>>>> WebGL and gets a million players. With this change, now 27,000 
>>>>>>>>>>>>>>> users will
>>>>>>>>>>>>>>> see a "WebGL not supported" error message. That's then 
>>>>>>>>>>>>>>> potentially a huge
>>>>>>>>>>>>>>> number of new support requests to deal with.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > Can you share the number for Construct about what
>>>>>>>>>>>>>>> percentage of your users are using the SwiftShader fallback? 
>>>>>>>>>>>>>>> Again, our
>>>>>>>>>>>>>>> numbers indicate that these are primarily older Windows 
>>>>>>>>>>>>>>> workstations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For the Construct editor itself, it is around 3%, so that
>>>>>>>>>>>>>>> seems in line. But the key point here is that Construct is 
>>>>>>>>>>>>>>> middleware: it
>>>>>>>>>>>>>>> is a tool our users develop web games in and then publish 
>>>>>>>>>>>>>>> independently of
>>>>>>>>>>>>>>> us. It is much more important that WebGL works for players of 
>>>>>>>>>>>>>>> those games
>>>>>>>>>>>>>>> than it does for Construct itself.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lots of people use older Windows workstations. We've had
>>>>>>>>>>>>>>> issues before where for example a graphics driver bug affecting 
>>>>>>>>>>>>>>> WebGL 1
>>>>>>>>>>>>>>> caused a great deal of trouble in a South American market, even 
>>>>>>>>>>>>>>> though I
>>>>>>>>>>>>>>> suspect it only affected a small percentage of devices - see
>>>>>>>>>>>>>>> https://issues.chromium.org/issues/40941645 which was never
>>>>>>>>>>>>>>> resolved. There are probably places in the world where there 
>>>>>>>>>>>>>>> are large
>>>>>>>>>>>>>>> numbers of people using older Windows workstations. I fear that 
>>>>>>>>>>>>>>> pulling
>>>>>>>>>>>>>>> WebGL support from those devices may result in much higher 
>>>>>>>>>>>>>>> numbers of
>>>>>>>>>>>>>>> unsupported users, and many more support requests, in the 
>>>>>>>>>>>>>>> specific markets
>>>>>>>>>>>>>>> where such devices are common.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is there anything that can be done to mitigate this change?
>>>>>>>>>>>>>>> Given SwiftShader allowed WebGL to be considered ubiquitous for 
>>>>>>>>>>>>>>> many years,
>>>>>>>>>>>>>>> engines like Construct long ago removed any fallback for 
>>>>>>>>>>>>>>> systems that do
>>>>>>>>>>>>>>> not support WebGL; we moved forward assuming we could rely on 
>>>>>>>>>>>>>>> WebGL, and so
>>>>>>>>>>>>>>> now it's probably infeasible to bring back any fallback as we 
>>>>>>>>>>>>>>> have too many
>>>>>>>>>>>>>>> key features that fundamentally require WebGL. Could 
>>>>>>>>>>>>>>> SwiftShader be adapted
>>>>>>>>>>>>>>> to not use JIT? Could some other fallback be found? Could the 
>>>>>>>>>>>>>>> GPU blocklist
>>>>>>>>>>>>>>> be revised to enable WebGL on as many older devices as possible?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think the number of affected users should be <1% to
>>>>>>>>>>>>>>> minimise the impact from such a change. At web scale 2.7% is 
>>>>>>>>>>>>>>> still a lot.
>>>>>>>>>>>>>>> Perhaps with revising the GPU blocklist and adding more 
>>>>>>>>>>>>>>> workarounds this is
>>>>>>>>>>>>>>> feasible. I fear if this goes ahead without any mitigation, it 
>>>>>>>>>>>>>>> will cause a
>>>>>>>>>>>>>>> great deal of trouble and is exactly the kind of thing sceptics 
>>>>>>>>>>>>>>> of the web
>>>>>>>>>>>>>>> will bring up to say that web technology sucks, browsers can't 
>>>>>>>>>>>>>>> be trusted,
>>>>>>>>>>>>>>> and people should just develop desktop games instead.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, 25 Feb 2025 at 22:31, Rick Byers <
>>>>>>>>>>>>>>> rby...@chromium.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sorry for the delay from API owners, as discussed on chat
>>>>>>>>>>>>>>> the chromestatus entry wasn't set up properly to request API 
>>>>>>>>>>>>>>> owner review
>>>>>>>>>>>>>>> (now fixed).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is a tricky one indeed (thanks for your input Ashley!).
>>>>>>>>>>>>>>> It looks like
>>>>>>>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4026>
>>>>>>>>>>>>>>> WebGL is used on about 20% of page loads, so 2.7% of that is 
>>>>>>>>>>>>>>> ~0.5% of page
>>>>>>>>>>>>>>> loads which is very high risk according to our rules of
>>>>>>>>>>>>>>> thumb
>>>>>>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.mqfkui78vo5z>
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Of course that's an upper-bound, how many will have a
>>>>>>>>>>>>>>> fallback? One option would be to collect some UKM data for 
>>>>>>>>>>>>>>> SwiftShader
>>>>>>>>>>>>>>> usage and review a random ~50 sites to observe the user 
>>>>>>>>>>>>>>> experience in
>>>>>>>>>>>>>>> practice. That could give us a better sense of what the real 
>>>>>>>>>>>>>>> user impact
>>>>>>>>>>>>>>> would likely be. Or Maybe Ashley can give us some examples of 
>>>>>>>>>>>>>>> some web
>>>>>>>>>>>>>>> games just to confirm they indeed go from being playable to
>>>>>>>>>>>>>>> unplayable without swiftshader on some specific devices? David, 
>>>>>>>>>>>>>>> do you have
>>>>>>>>>>>>>>> a device yourself you can test with that doesn't support GPU 
>>>>>>>>>>>>>>> WebGL?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regardless, unless sites have been really good about almost
>>>>>>>>>>>>>>> always falling back somehow, I suspect we'll find that there's 
>>>>>>>>>>>>>>> enough
>>>>>>>>>>>>>>> end-user impact to make this a high-risk change (but I could be 
>>>>>>>>>>>>>>> convinced
>>>>>>>>>>>>>>> otherwise such as via a thorough UKM analysis). In which case 
>>>>>>>>>>>>>>> then we could
>>>>>>>>>>>>>>> start working through our playbook for a phased plan for risky 
>>>>>>>>>>>>>>> breaking
>>>>>>>>>>>>>>> changes. Not unlike what we did for flash removal
>>>>>>>>>>>>>>> <https://www.chromium.org/flash-roadmap/>, or WebSQL
>>>>>>>>>>>>>>> <https://developer.chrome.com/blog/deprecating-web-sql> (both
>>>>>>>>>>>>>>> big security benefit but big web compat risk). For example:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    - Explore whether we can build swiftshader into a wasm
>>>>>>>>>>>>>>>    module that sites can use as a (probably even slower) 
>>>>>>>>>>>>>>> fallback themselves.
>>>>>>>>>>>>>>>    This turned out to be the key to making WebSQL deprecation 
>>>>>>>>>>>>>>> tractable. In
>>>>>>>>>>>>>>>    general our policy
>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.x5bhg5grhfeo>
>>>>>>>>>>>>>>>    is that we don't take functionality away that developers 
>>>>>>>>>>>>>>> can't replace with
>>>>>>>>>>>>>>>    some other substitute except in pretty extreme circumstances.
>>>>>>>>>>>>>>>    - Prompt the user on whether or not to enable it
>>>>>>>>>>>>>>>    per-origin (like a permission)
>>>>>>>>>>>>>>>    - Put 3p usage behind a permission policy so the
>>>>>>>>>>>>>>>    top-level site has to opt-in to allow 3p iframes to use 
>>>>>>>>>>>>>>> swiftshader
>>>>>>>>>>>>>>>    - Rely on some heuristics, (perhaps crowd-sourced
>>>>>>>>>>>>>>>    signals) to try to find a sweet spot in the safety vs. 
>>>>>>>>>>>>>>> functionality
>>>>>>>>>>>>>>>    tradeoff space. We did this for flash initially with things 
>>>>>>>>>>>>>>> like blocking
>>>>>>>>>>>>>>>    it for very small canvases.
>>>>>>>>>>>>>>>    - Anything we can do to make WebGL work on a larger set
>>>>>>>>>>>>>>>    of devices?
>>>>>>>>>>>>>>>    - Probably lots of other ideas that aren't occurring to
>>>>>>>>>>>>>>>    me right now, more examples in bit.ly/blink.compat.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On the other side of the equation, API owners can be
>>>>>>>>>>>>>>> convinced to accept more compat risk the more significant the 
>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>> benefits are. Are there more details you can share? Such as:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    - Are we confident that an attacker can only trigger
>>>>>>>>>>>>>>>    swiftshader on somewhere around 3% of users (vs. some knob 
>>>>>>>>>>>>>>> which can force
>>>>>>>>>>>>>>>    it to be used on a larger fraction)? To what extent do we 
>>>>>>>>>>>>>>> have reason to
>>>>>>>>>>>>>>>    believe that the vulnerable population size is large enough 
>>>>>>>>>>>>>>> to be a
>>>>>>>>>>>>>>>    plausible target for attackers? Is there anything we can do 
>>>>>>>>>>>>>>> to make the
>>>>>>>>>>>>>>>    vulnerable user base more reliably contained?
>>>>>>>>>>>>>>>    - How does swiftshader compare to other areas in terms
>>>>>>>>>>>>>>>    of the number of vulnerabilities we've found in practice? 
>>>>>>>>>>>>>>> Are there any
>>>>>>>>>>>>>>>    reports of ITW exploits of it? It looks like
>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>> <https://chrome-commit-tracker.arthursonzogni.com/cve/reward_per_components?start=2019-12-27&end=2025-02-25>
>>>>>>>>>>>>>>>    since 2020 SwiftShader has been about 8% of Chrome's VRP 
>>>>>>>>>>>>>>> spend - that seems
>>>>>>>>>>>>>>>    quite significant to me, but probably not in the top 5 areas 
>>>>>>>>>>>>>>> of concern.
>>>>>>>>>>>>>>>    This was obviously key to the immense cost and pain of Flash 
>>>>>>>>>>>>>>> removal - we
>>>>>>>>>>>>>>>    kept having severe security incidents in practice.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So assuming Ashley and I are right that this isn't likely to
>>>>>>>>>>>>>>> be easy, that means it's likely quite a lot of work to attempt 
>>>>>>>>>>>>>>> to phase-out
>>>>>>>>>>>>>>> SwiftShader in a responsible fashion. But with luck maybe we 
>>>>>>>>>>>>>>> can find a
>>>>>>>>>>>>>>> first step that is a good cost-benefit tradeoff (like putting 
>>>>>>>>>>>>>>> 3P usage
>>>>>>>>>>>>>>> behind a permission prompt)? Or maybe it's just a better 
>>>>>>>>>>>>>>> cost-benefit
>>>>>>>>>>>>>>> tradeoff to invest in other areas which pose a threat to a 
>>>>>>>>>>>>>>> greater number
>>>>>>>>>>>>>>> users (hardening ANGLE perhaps)? But of course I will defer to 
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> judgement of security and GPU experts like yourself on that 
>>>>>>>>>>>>>>> question, I'm
>>>>>>>>>>>>>>> happy to consult and support if you want to invest in a plan 
>>>>>>>>>>>>>>> that API
>>>>>>>>>>>>>>> owners can approve.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Rick
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Feb 19, 2025 at 2:48 PM 'David Adrian' via
>>>>>>>>>>>>>>> blink-dev <blin...@chromium.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > I wrote about this previously but I'm still concerned this
>>>>>>>>>>>>>>> is a major breaking change for existing published WebGL content 
>>>>>>>>>>>>>>> on the web.
>>>>>>>>>>>>>>> If the figure of 2.7% comes from my previous citing of 
>>>>>>>>>>>>>>> Web3DSurvey
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It does, not it comes from Chrome's metrics system.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > Does Google have their own internal data about the usage
>>>>>>>>>>>>>>> of SwiftShader?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is the 2.7% number.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > Suppose this change rolls out and we get reports that say
>>>>>>>>>>>>>>> our WebGL content no longer works for 10% of users in a South 
>>>>>>>>>>>>>>> American
>>>>>>>>>>>>>>> market. Then what? There is nothing feasible we can do about 
>>>>>>>>>>>>>>> it. These
>>>>>>>>>>>>>>> customers were previously getting by with SwiftShader, but now 
>>>>>>>>>>>>>>> they get an
>>>>>>>>>>>>>>> error message. So I fear this risks disaster for web games in 
>>>>>>>>>>>>>>> some markets.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > I mentioned I don't think it should be used as evidence to
>>>>>>>>>>>>>>> make such a big change as this. Maybe in some places it will 
>>>>>>>>>>>>>>> affect 25% or
>>>>>>>>>>>>>>> 50% of users - who knows? How can we be sure?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you share the number for Construct about what percentage
>>>>>>>>>>>>>>> of your users are using the SwiftShader fallback? Again, our 
>>>>>>>>>>>>>>> numbers
>>>>>>>>>>>>>>> indicate that these are primarily older Windows workstations. 
>>>>>>>>>>>>>>> Notably,
>>>>>>>>>>>>>>> SwiftShader is not used at all on mobile.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > V8 does JIT with untrusted JavaScript code and that is
>>>>>>>>>>>>>>> generally considered reasonably secure, is there any particular 
>>>>>>>>>>>>>>> technical
>>>>>>>>>>>>>>> reason SwiftShader is not considered as secure?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes. The GPU process is shared between all sites, whereas
>>>>>>>>>>>>>>> the V8 JIT is per-site. This means compromising the GPU process 
>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>> enough to bypass site isolation protections with a single bug.
>>>>>>>>>>>>>>> Additionally, V8 bugs can be reliably patched in the browser, 
>>>>>>>>>>>>>>> whereas
>>>>>>>>>>>>>>> SwiftShader "bugs" can be user-mode graphics driver bugs that 
>>>>>>>>>>>>>>> are simply
>>>>>>>>>>>>>>> more exposed via SwiftShader than they would be otherwise. In 
>>>>>>>>>>>>>>> this case,
>>>>>>>>>>>>>>> the browser can't patch the bug because it's in the driver.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thursday, February 13, 2025 at 12:12:07 PM UTC-5
>>>>>>>>>>>>>>> ash...@scirra.com wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I wrote about this previously but I'm still concerned this
>>>>>>>>>>>>>>> is a major breaking change for existing published WebGL content 
>>>>>>>>>>>>>>> on the web.
>>>>>>>>>>>>>>> If the figure of 2.7% comes from my previous citing of 
>>>>>>>>>>>>>>> Web3DSurvey (
>>>>>>>>>>>>>>> https://web3dsurvey.com/) then this should be seen as very
>>>>>>>>>>>>>>> much an underestimate, because that site uses a relatively 
>>>>>>>>>>>>>>> small sample
>>>>>>>>>>>>>>> size that is more likely to be focused on high-end devices 
>>>>>>>>>>>>>>> (samples are
>>>>>>>>>>>>>>> taken from developer-focused sites like the three.js website, 
>>>>>>>>>>>>>>> WebGPU
>>>>>>>>>>>>>>> fundamentals etc). I would not be surprised if the real 
>>>>>>>>>>>>>>> worldwide average
>>>>>>>>>>>>>>> was more like 4-5%. Then if that's a worldwide average, there 
>>>>>>>>>>>>>>> will probably
>>>>>>>>>>>>>>> be some specific countries or markets where the figure could be 
>>>>>>>>>>>>>>> more like
>>>>>>>>>>>>>>> 10%.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Suppose this change rolls out and we get reports that say
>>>>>>>>>>>>>>> our WebGL content no longer works for 10% of users in a South 
>>>>>>>>>>>>>>> American
>>>>>>>>>>>>>>> market. Then what? There is nothing feasible we can do about 
>>>>>>>>>>>>>>> it. These
>>>>>>>>>>>>>>> customers were previously getting by with SwiftShader, but now 
>>>>>>>>>>>>>>> they get an
>>>>>>>>>>>>>>> error message. So I fear this risks disaster for web games in 
>>>>>>>>>>>>>>> some markets.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Does Google have their own internal data about the usage of
>>>>>>>>>>>>>>> SwiftShader? Can more data about this be shared? I respect the 
>>>>>>>>>>>>>>> work done by
>>>>>>>>>>>>>>> Web3DSurvey but unfortunately for the reasons I mentioned I 
>>>>>>>>>>>>>>> don't think it
>>>>>>>>>>>>>>> should be used as evidence to make such a big change as this. 
>>>>>>>>>>>>>>> Maybe in some
>>>>>>>>>>>>>>> places it will affect 25% or 50% of users - who knows? How can 
>>>>>>>>>>>>>>> we be sure?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can there not be some other fallback implemented? V8 does
>>>>>>>>>>>>>>> JIT with untrusted JavaScript code and that is generally 
>>>>>>>>>>>>>>> considered
>>>>>>>>>>>>>>> reasonably secure, is there any particular technical reason 
>>>>>>>>>>>>>>> SwiftShader is
>>>>>>>>>>>>>>> not considered as secure?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd also point out that any website that has a poor
>>>>>>>>>>>>>>> experience with SwiftShader can already opt-out using the
>>>>>>>>>>>>>>> failIfMajorPerformanceCaveat context flag. If there is some 
>>>>>>>>>>>>>>> other mode that
>>>>>>>>>>>>>>> can be used instead, or just showing an error message is 
>>>>>>>>>>>>>>> acceptable, then
>>>>>>>>>>>>>>> websites can already implement that. In our case with Construct 
>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> specifically attempt to obtain hardware-accelerated WebGPU, 
>>>>>>>>>>>>>>> WebGL 2, or
>>>>>>>>>>>>>>> WebGL 1; only failing that do we resort to using SwiftShader on 
>>>>>>>>>>>>>>> the basis
>>>>>>>>>>>>>>> that showing the content with potentially poor performance is 
>>>>>>>>>>>>>>> better than
>>>>>>>>>>>>>>> not showing it at all.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, 13 Feb 2025 at 15:46, 'David Adrian' via blink-dev <
>>>>>>>>>>>>>>> blin...@chromium.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Contact emails
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> dad...@google.com, geof...@chromium.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Summary
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Allowing automatic fallback to WebGL backed by SwiftShader
>>>>>>>>>>>>>>> is deprecated and will be removed. This has been noted in 
>>>>>>>>>>>>>>> DevTools since
>>>>>>>>>>>>>>> Chrome 130.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> WebGL context creation will fail instead of falling back to
>>>>>>>>>>>>>>> SwiftShader. This is for two primary reasons:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. SwiftShader is a high security risk due to JIT-ed code
>>>>>>>>>>>>>>> running in Chromium's GPU process.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. Users have a poor experience when falling back from a
>>>>>>>>>>>>>>> high-performance GPU-backed WebGL to a CPU-backed 
>>>>>>>>>>>>>>> implementation. Users
>>>>>>>>>>>>>>> have no control over this behavior and it is difficult to 
>>>>>>>>>>>>>>> describe in bug
>>>>>>>>>>>>>>> reports.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SwiftShader is a useful tool for web developers to test
>>>>>>>>>>>>>>> their sites on systems that are headless or do not have a 
>>>>>>>>>>>>>>> supported GPU.
>>>>>>>>>>>>>>> This use case will still be supported by opting in but is not 
>>>>>>>>>>>>>>> intended for
>>>>>>>>>>>>>>> running untrusted content.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To opt-in to lower security guarantees and allow SwiftShader
>>>>>>>>>>>>>>> for WebGL, run the chrome executable with the 
>>>>>>>>>>>>>>> --enable-unsafe-swiftshader
>>>>>>>>>>>>>>> command-line switch.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> During the deprecation period, a warning will appear in the
>>>>>>>>>>>>>>> javascript console when a WebGL context is created and backed 
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> SwiftShader. Passing --enable-unsafe-swiftshader will remove 
>>>>>>>>>>>>>>> this warning
>>>>>>>>>>>>>>> message. This deprecation period began in Chrome 130.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Chromium and other browsers do not guarantee WebGL
>>>>>>>>>>>>>>> availability. Please test and handle WebGL context creation 
>>>>>>>>>>>>>>> failure and
>>>>>>>>>>>>>>> fall back to other web APIs such as Canvas2D or an appropriate 
>>>>>>>>>>>>>>> message to
>>>>>>>>>>>>>>> the user.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SwiftShader is an internal implementation detail of
>>>>>>>>>>>>>>> Chromium, not a public web standard, therefore buy-in from 
>>>>>>>>>>>>>>> other browsers
>>>>>>>>>>>>>>> is not required. The devices covered by SwiftShader (primarily 
>>>>>>>>>>>>>>> older
>>>>>>>>>>>>>>> Windows devices) are likely already incompatible with WebGL in 
>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>> browsers.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SwiftShader is not used on mobile; this only applies to
>>>>>>>>>>>>>>> Desktop platforms.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Blink component
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Blink>WebGL
>>>>>>>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebGL%22>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Motivation
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://chromium.googlesource.com/chromium/src/+/main/docs/gpu/swiftshader.md#automatic-swiftshader-webgl-fallback-is-deprecated
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Risks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SwiftShader is used by devices without hardware acceleration
>>>>>>>>>>>>>>> for WebGL. This is approximately 2.7% of WebGL contexts. 
>>>>>>>>>>>>>>> However, WebGL is
>>>>>>>>>>>>>>> considered fallible and in many cases, these draws are not 
>>>>>>>>>>>>>>> performant and
>>>>>>>>>>>>>>> provide an effectively unusable experience for users. Many 
>>>>>>>>>>>>>>> applications,
>>>>>>>>>>>>>>> such as Google Maps, prefer to fail out rather than use 
>>>>>>>>>>>>>>> SwiftShader.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Debuggability
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> None
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Flag name on about://flags
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --enable-unsafe-swiftshader command-line switch.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Finch feature name
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> AllowSwiftShaderFallback
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tracking bug
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://issues.chromium.org/40277080
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Launch bug
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://launch.corp.google.com/launch/4351104
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Estimated milestones
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Shipping on Desktop 137
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://chromestatus.com/feature/5166674414927872?gate=5188866041184256
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status
>>>>>>>>>>>>>>> <https://chromestatus.com/>.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>>>> Google Groups "blink-dev" group.
>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails
>>>>>>>>>>>>>>> from it, send an email to blink-dev+...@chromium.org.
>>>>>>>>>>>>>>> To view this discussion visit
>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42KV4DrSSyEgJaF4DnFOXAye-wRLrfD-LKGNkWhyWzshLA%40mail.gmail.com
>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42KV4DrSSyEgJaF4DnFOXAye-wRLrfD-LKGNkWhyWzshLA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>>>> Google Groups "blink-dev" group.
>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails
>>>>>>>>>>>>>>> from it, send an email to blink-dev+...@chromium.org.
>>>>>>>>>>>>>>> To view this discussion visit
>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c5131675-dff4-4aa0-8e84-4cdc373e3035n%40chromium.org
>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c5131675-dff4-4aa0-8e84-4cdc373e3035n%40chromium.org?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>>>> Google Groups "blink-dev" group.
>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails
>>>>>>>>>>>>>>> from it, send an email to blink-dev+...@chromium.org.
>>>>>>>>>>>>>>> To view this discussion visit
>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73jWBkuxvj%3DDDXmEQNwLfCa_uV5OZZ5nZJRj9ZMgP9yk7Q%40mail.gmail.com
>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73jWBkuxvj%3DDDXmEQNwLfCa_uV5OZZ5nZJRj9ZMgP9yk7Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>>>> Google Groups "blink-dev" group.
>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails
>>>>>>>>>>>>>>> from it, send an email to blink-dev+...@chromium.org.
>>>>>>>>>>>>>>> To view this discussion visit
>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73hYs9O-2hdmfn37fQb-U-8m_-08i3Qg9dkUhKNQQvNLSg%40mail.gmail.com
>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73hYs9O-2hdmfn37fQb-U-8m_-08i3Qg9dkUhKNQQvNLSg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "blink-dev" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to blink-dev+...@chromium.org.
>>>>>> To view this discussion visit
>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2cfb0848-03a1-4cd6-9c09-7ad8026a9f3dn%40chromium.org
>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2cfb0848-03a1-4cd6-9c09-7ad8026a9f3dn%40chromium.org?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BPGBXuNUkzoceK7kS%2BP72SFfCB%3D41qm-rz2iMWN08h_dkHFHw%40mail.gmail.com.

Reply via email to