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 <phist...@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 < > blink-dev@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+unsubscr...@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%2BPGBXtxkOdqMrRBM_O3JusyxHpVT%2BMN22Ja_0d81f6ce0_0Jw%40mail.gmail.com.
