Hacker News Reader

Hacker News

Comment by mrec | Hacker News Reader

Parent Full thread

mrec

Carmack said it best:

"Putting anything that gets benchmarked in a position of security responsibility is very, very dangerous."

https://twitter.com/ID_AA_Carmack/status/395927588108918785

I think the original context was WebGL, but it applies everywhere.

View on HN

Makes me wonder that Matt Dillon, Theo De Raadt, Linus Torvalds, John Carmack and Bryan Cantrill would have been able to make if they were founders of a company together.

A truly epic fight, I'm guessing.

Many of these people found success by focusing on engineering solutions instead of founding companies. Makes me instead question what we'd lose if they made that choice years ago.

First persuade Matt to leave the BSD world, or Linus to leave Linux...

Not happening in my lifetime I think.

They would make forks ;)

Not before they had a solid source code management system, ... oh wait!

... is webgl in a position of security responsibility? The browser sandbox is, and aren't webgl and the browser different things?

WebGL as a proxy API is implemented by the browser, yes, but the thing it's proxying (the graphics driver) is well outside the sandbox and is arguably too complex to be secured by parameter validation and the like. If the driver has an exploitable bug in its shader compiler, for example, the WebGL layer is unlikely to be able to guard against it.

Got it. Thank you.

That's why WebGL is dead (apart copyright/patent issues, IIRC from Apple), there will be no new version. Instead an alternative standard is being development.

First I'm hearing of this. Got a link?

Related reading: remember that time a bug in Firefox's WebGL let an attacker grab a screenshot of your whole monitor?

https://blog.mozilla.org/security/2011/06/16/webgl-graphics-... , https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/blog/webgl-a-new-dimension-for-bro... , https://www.contextis.com/blog/webgl-more-webgl-security-fla...

Not GP, but I think the ossification of WebGL has little to do with security concerns and a lot to do with the fact that the GL model is a poor fit to the direction hardware has taken over the past couple of decades. Realistically, any successor is going to be benchmarked to within an inch of its life too, so the same worry would apply.

The shape of that successor is still very vague, but it'll probably be closer to the Vulkan/Metal/DX12 generation. Various interested parties have been putting together exploratory proposals (see e.g. Mozilla's Obsidian), and Khronos appears to be accepting that "Vulkan everywhere" ain't going to happen and working on a "3D portability" initiative that's pretty much lowest-common-denominator. That would almost certainly have a web binding if it pans out.

Disclaimer: I don't work in this area, I just follow it out of morbid curiosity.

A few links:

https://www.khronos.org/api/3dportability/

http://floooh.github.io/2016/08/13/webgl-next.html

https://www.phoronix.com/scan.php?page=news_item&px=Mozilla-...

It's called WebGPU. All the major players are cooperating. The mailing list reveals quite active biweekly meetings.

https://www.w3.org/community/gpu/

Thanks! I had no idea about that project.

> Khronos appears to be accepting that "Vulkan everywhere" ain't going to happen and working on a "3D portability" initiative that's pretty much lowest-common-denominator. That would almost certainly have a web binding if it pans out.

this isn't actually such a bad idea. Right now, WebGL isn't OpenGL everywhere either. It's "OpenGL where possible but Direct3D on Windows because OpenGL drivers used to be terrible". Likewise, it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux

> Likewise, it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux

So, a higher-level graphics API. Like WebGL?

I'm not just being facetious - if we're ruling out a low-level API like Vulkan, aren't we back to square one?

What's wrong with WebGL that could be fixed with an API like you describe?

WebGL is modelled after the worst part of OpenGL: hardware state is presented as something that can be altered by the application software at any time in any way, no matter how brain dead the change actually is. Instead of preventing the user to from writing slow rendering code on top of that interface, it actively encourages that.

The new generation of interfaces are based on the tenet that most of the state information is known in advance anyway and can be precompiled into static opaque handles which represent precomputed and sanity-checked hardware register values that the driver just needs to push when required instead of having to run the heavy checking again each time the user calls some glEnable/glDisable or other state altering shenanigans.

I think that a new JavaScript interface that is modelled like this, but is sufficently high level, might be faster, easier to use and safer to implement than what we currently have.

You clearly know a lot more than I do - so that kind of thinking is reflected in the architectures of Direct3D 12/Vulkan/Metal?

Could an indirection layer really be practical?

(Vaguely related: Zed Shaw's blog post on Indirection Is Not Abstraction, https://zedshaw.com/archive/indirection-is-not-abstraction/ )

I don't understand what you mean here. You definitely can't expose Vulkan to untrusted code because it is designed to have a very high level of trust between driver and application - the driver is quite likely to crash the whole system on bad input. And there are countless possibilities for bad input in this interface.

So what you need for browsers is an interface that keeps the general ideas of flexible buffer usage and immutable state objects, but puts the user in a rubber cell with heavily padded levers. It can be done, but it likely can't have the full flexibility of DX12/Vulkan/... with memory aliasing etc.

I'm not talking about directly wrapping Vulkan, I was referring to skocznymroczny's comment: "it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux"

The goal would be to maximally retain the advantages of the new generation of graphics APIs, while accommodating all three as backends to the system. (Comparable to the way ANGLE maps WebGL onto Direct3D, but without 'picking favourites'.)

You sound ambivalent on the practicality of this. WebGL itself has been more successful at doing this (wrapping a highly 'trusting' graphics API to give a secure and portable API) than I thought it would be (though we did have the very alarming security issue I mentioned before).

There are GLSL exploits.

"Vulnerability analysis of GPU computing"

https://lib.dr.iastate.edu/cgi/viewcontent.cgi?referer=&http...

"Grand Pwning Unit: Accelerating Microarchitectural Attacks with the GPU"

https://www.vusec.net/wp-content/uploads/2018/05/glitch.pdf

Just two random papers, there are quite a few others.

Ah, and as usual when discussing 3D APIs, games console also use their own flavours, XBox is not the exception.

WebGL also does not use OpenGL on game consoles.

Sorry, that's actually only true for WebCL.

https://www.khronos.org/webcl/public-mailing-list/archives/1...

According to this post the future lies in WebVulkan - which is both computing and graphics. On the other hand people from the big companies including Google and Apple are working on WebGPU.

That said, and having worked on a complex WebGL project myself where my colleagues were complaining all the time how bad WebGL is (sorry, won't search the references for that though :P), I wonder how there can possibly be any future for it.

Ah yes, WebCL. A web standard too far. I recall Mozilla saying they wouldn't bother implementing it as people could just use compute shaders in WebGL, but my understanding is that this isn't really practical even now, years later.

From a quick google, I don't think there's really any such thing as 'WebVulkan'. Following the discussion above, I don't see that it would really be a good idea anyway. Wrong level of abstraction.

Someone above linked to this article on 'GPU for the Web' (which I presume is what 'WebGPU' refers to), which as you say looks like it might be the successor to WebGL - https://www.w3.org/community/gpu/

Dead, or just stable?

From my testing it looks like WebGL 1 (corresponding to ES 2) is widely available on both mobile and desktop and performs pretty well. I assume WebGL 2 will reach a similar level of support in a couple of years.

For 95% of use cases that’s exactly what we want. I don’t want or need a new 3D standard, I just want the existing standard to work well.

Is there any risk that WebGL 1 availability is going to regress? I hope not!

WebGL is definitely not yet suitable for AAA games, and I’m sure there must be disagreement over the best way to get there. Is that what you’re referring to?

WebGL is still pretty much hit-and-miss, you might have hardware that runs perfectly fine OpenGL ES 3.x native games and then for whatever reason browser vendors blacklist the GPU/OS combination thus running as if software rendering was being used.

And as 3D creator it is not possible to check for this, so people get to the page and dismiss as not being worthy their time.

ES 3 / WebGL 2 is patchy, yes, but I've found ES 2 / WebGL 1 to be reasonably reliable these days. (Edit to add: mainly thinking about iOS, Android and macOS. I haven't experimented much with Windows and Linux.)

Reply on news.ycombinator.com