Hi,
Disclaimer: I am a support person and not necessarily the developer.
We have a few in-house tools that use threejs and need WebGL; they used to work in centos-7. Recently, we have been migrated to rocky-9 and our pre-existing tools no longer work; IT indicates that WebGL is insecure and, therefore, turned off.
Questions: is there a (secure) alternative to WebGL? What to use instead?
If you want to render graphics in a web browser with a certain level of complexity, WebGL is the only solution. I’m skeptical of their claim that it’s insecure, it’s been around for nearly 15 years so at this point it’s probably as safe as any other browser feature.
I’m genuinely interested in why your IT folks think so. For the last decade there were several attempts to manifest WebGL as prone to security risks. All attempts failed, as they have been proved to be inconsistent, unrelated to WebGL, or a pure marketing trick. There is one specific big company that is notorious of speaking against WebGL.
The only insecurity I’m aware of in webGL is being able to lock up the thread (which you can do with regular javascript as well.), or DOS the GPU (context loss).
There used to be canvasrenderer but it was deprecated since webGL is basically available everywhere now.
https://www.reddit.com/r/programming/comments/9tiejj/canvasrenderer_removed_from_threejs_webgl_is/
Khronos’ take on security:
https://www.khronos.org/webgl/security/
There are no GLSL ES commands or drawing commands in WebGL that can be used to access memory outside the bounds defined by the specification. The GPU's registers or other internal state cannot be accessed. To do so would require providing invalid input to the OpenGL driver, which is disallowed by the specification. For example, the size of a vertex buffer is defined at its creation, and data can not be set outside this valid range. vertexAttribPointer settings cannot be made in a way that would give access outside the valid range of the created and bound buffers. Out-of-range indices cannot be used for drawing. Uncleared renderbuffers cannot be accessed. Uncleared vertex buffers cannot be accessed. Uncleared textures cannot be accessed. Even an uncleared back buffer cannot be accessed.
There are no arbitrary data writing commands in GLSL. The WebGL specification requires all array accesses to be safe. A shader cannot address outside a texture; there is no such concept in OpenGL. A shader cannot draw with unbound or uninitialized textures.
The only remaining issue is denial of service as described above. This is not just an issue for WebGL but for any technology allowing web applications to issue drawing commands. It will be solved by the graphics driver preempting or killing offending contexts with functionality such as that described in the robustness extensions.
The Khronos group and WebGL working group are looking forward to widespread deployment of WebGL in a robust and secure manner.
I reached out to the developer for more details, he pointed me to the browser gpu page: chrome://gpu ; the very first section shows the following :
Graphics Feature Status
=======================
* Canvas: Software only, hardware acceleration unavailable
* Canvas out-of-process rasterization: Disabled
* Direct Rendering Display Compositor: Disabled
* Compositing: Software only. Hardware acceleration disabled
* Multiple Raster Threads: Enabled
* OpenGL: Disabled
* Rasterization: Software only. Hardware acceleration disabled
* Raw Draw: Disabled
* Skia Graphite: Disabled
* Video Decode: Software only. Hardware acceleration disabled
* Video Encode: Software only. Hardware acceleration disabled
* Vulkan: Disabled
* WebGL: Software only, hardware acceleration unavailable
* WebGL2: Software only, hardware acceleration unavailable
* WebGPU: Disabled
In contrast, the same settings in my personal computer show everything as “Hardware accelerated”, and with both OpenGL and WebGPU Enabled
At the risk of sounding stupid …
I wonder if that is the reason I can’t run my own WebGPU programs that I uploaded to my webpage? I use the Chrome browser. The WebGL and WebGL2 programs that I have uploaded work just fine. But the WebGPU versions of the same programs refuse to run.
I originally thought that the problem might be that my website does not have https certification. After all, I can run the three.js WebGPU examples just fine. And I thought that Chrome had fully embraced WebGPU starting sometime last year.
Well, as initially mentioned, I myself am not the one developing the program that no longer works…someone reported the WebGL problem, and I just started to probe the internet.
For what is worth, last night I learned about some hidden page: chrome://flags
I don’t know what IT did or meant to do about a month ago, but if I go to chrome://flags, I can re-enable one of those flags, more specifically: “Override software rendering list”
This does not necessarily turn on WebGPU, but at least enables WebGL hard acceleration; now, I do see a spinning cube when I go to http://get.webgl.org/
In your, Graphics Feature Status table above,
I don’t see any security warnings.
I see a browser or perhaps operating system not capable of hardware acceleration.
Maybe your rocky-9 OS hasn’t got the correct graphics card drivers installed.
What graphics card is it?
I was not expecting to see any kind of security warning anywhere; what I understood from the report is that it was more of a judgement call by our IT to disable something. But, maybe they just changed the default since most people wouldn’t know how to undo such change, anyway.
As indicated in my previous post, I was able to enable WebGL back.
Other than that, here are the specs from the Linux session:
OPERATING SYSTEM INFORMATION
Operating System .............. GNU/Linux
Distribution .................. Rocky 9.3
Kernel Version ................ 5.14.0-362.18.1.el9_3.0.1.x86_64
Kernel Architecture ........... x86_64
Kernel Optimization ........... x86_64
COMPUTER HARDWARE INFORMATION
Computer Manufacturer ......... HPE
Computer Model ................ ProLiant DL380 Gen10
BIOS Version .................. U30 (07/20/2023)
Memory Installed .............. 1536 GB installed in 24 DIMMs (0 slots free)
Memory Type & Speed ........... DDR4 2933 MHz Synchronous
Number of CPU(s) .............. 48 [2 sockets * 24 core(s) each]
CPU Manufacturer .............. Intel
CPU Model/Family .............. Xeon
CPU Clock Speed ............... 3000 MHz
Graphics Card (or GPGPU)....... NVIDIA Corporation TU102GL [Quadro RTX 6000/8000]
Graphics Driver ............... 470.182.03
If there is no security warning to be found anywhere, on yours or your IT profesionals computer, then how did you presume, as the title suggests, “WebGL: presumably insecure”?
First of all, this is all second hand; I learned about this claim from some colleagues, this past Thursday; but, because of Easter and the weekend, I am yet to get to hear anything from the horse’s mouth, heck, I don’t even know who the horse is. In the meantime, I figured I would start probing the internet, looking for evidence, asking questions.
So, no, I don’t have hard evidence of any insecurity, that’s why I said “presumably”. Other than that, it wouldn’t be the first this happens, I often do get orders from our Cybersecurity team to either remove some software or upgrade to a newer version; then again, this has been about software that I myself have installed and I actually get a personalized e-mail.
Hope next week to get to the bottom of this, if this is a thing.
I think I understand where your IT department is coming from now.
You can use webgl detection to fingerprint users in place of cookies.
Here is an example of a cross browser fingerprinter.
Not very good since it only gathers information likey to be very common amongst browsers.
It checks webgl contexts.