5 ms·

Carmack said it best: "Putting anything that gets benchmarked in a position of security responsibility is very, very dangerous." https://twitter.com/ID_AA_Car

by mrec 8y ago

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 https://twitter.com/ID_AA_Carmack/status/395927588108918785 I think the original context was WebGL, but it applies everywhere.

blablabla123 8y ago
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.
- MaxBarraclough 8y ago
  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-memory-stealing-issue/ https://blog.mozilla.org/security/2011/06/16/webgl-graphics-... , https://news.ycombinator.com/item?id=16457791 https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/blog/webgl-a-new-dimension-for-browser-exploitation https://www.contextis.com/blog/webgl-a-new-dimension-for-bro... , https://www.contextis.com/blog/webgl-more-webgl-security-flaws https://www.contextis.com/blog/webgl-more-webgl-security-fla...
  - mrec 8y ago
    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/ https://www.khronos.org/api/3dportability/ http://floooh.github.io/2016/08/13/webgl-next.html http://floooh.github.io/2016/08/13/webgl-next.html https://www.phoronix.com/scan.php?page=news_item&px=Mozilla-Obsidian-Graphics-API https://www.phoronix.com/scan.php?page=news_item&px=Mozilla-...
    - skocznymroczny 8y ago
      > 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
      - MaxBarraclough 8y ago
        > 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?
        gmueckl 8y ago
        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.
        MaxBarraclough 8y ago
  - blablabla123 8y ago
    Sorry, that's actually only true for WebCL. https://www.khronos.org/webcl/public-mailing-list/archives/1612/msg00001.php 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.
    - MaxBarraclough 8y ago
      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/ https://www.w3.org/community/gpu/
- iainmerrick 8y ago
  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?
  - pjmlp 8y ago
    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.
    - iainmerrick 8y ago
      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.)
unixhero 8y ago
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.
- dwc 8y ago
  They would make forks ;)
  - unixhero 8y ago
    Not before they had a solid source code management system, ... oh wait!
- ebiester 8y ago
  A truly epic fight, I'm guessing.
- oldcynic 8y ago
  First persuade Matt to leave the BSD world, or Linus to leave Linux... Not happening in my lifetime I think.
- naner 8y ago
  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.
naikrovek 8y ago
... is webgl in a position of security responsibility? The browser sandbox is, and aren't webgl and the browser different things?
- mrec 8y ago
  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.
  - naikrovek 8y ago
    Got it. Thank you.

by mrec 8y ago

blablabla123 8y ago

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.

MaxBarraclough 8y ago
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-memory-stealing-issue/ https://blog.mozilla.org/security/2011/06/16/webgl-graphics-... , https://news.ycombinator.com/item?id=16457791 https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/blog/webgl-a-new-dimension-for-browser-exploitation https://www.contextis.com/blog/webgl-a-new-dimension-for-bro... , https://www.contextis.com/blog/webgl-more-webgl-security-flaws https://www.contextis.com/blog/webgl-more-webgl-security-fla...
- mrec 8y ago
  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/ https://www.khronos.org/api/3dportability/ http://floooh.github.io/2016/08/13/webgl-next.html http://floooh.github.io/2016/08/13/webgl-next.html https://www.phoronix.com/scan.php?page=news_item&px=Mozilla-Obsidian-Graphics-API https://www.phoronix.com/scan.php?page=news_item&px=Mozilla-...
  - skocznymroczny 8y ago
    > 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
    - MaxBarraclough 8y ago
      > 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?
      - gmueckl 8y ago
        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.
        MaxBarraclough 8y ago
- blablabla123 8y ago
  Sorry, that's actually only true for WebCL. https://www.khronos.org/webcl/public-mailing-list/archives/1612/msg00001.php 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.
  - MaxBarraclough 8y ago
    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/ https://www.w3.org/community/gpu/
iainmerrick 8y ago
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?
- pjmlp 8y ago
  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.
  - iainmerrick 8y ago
    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.)

unixhero 8y ago

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.

dwc 8y ago
They would make forks ;)
- unixhero 8y ago
  Not before they had a solid source code management system, ... oh wait!
ebiester 8y ago
A truly epic fight, I'm guessing.
oldcynic 8y ago
First persuade Matt to leave the BSD world, or Linus to leave Linux... Not happening in my lifetime I think.
naner 8y ago
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.

naikrovek 8y ago

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

mrec 8y ago
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.
- naikrovek 8y ago
  Got it. Thank you.