5 ms·

Will this API be opt-in, or can we expect another security disaster like with WebGL? https://news.ycombinator.com/item?id=16457791 https://news.ycombinator.com

Will this API be opt-in, or can we expect another security disaster like with WebGL? https://news.ycombinator.com/item?id=16457791 https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/en/blog/webgl-a-new-dimension-for-browser-exploitation https://www.contextis.com/en/blog/webgl-a-new-dimension-for-... , https://www.contextis.com/en/blog/webgl-more-webgl-security-flaws https://www.contextis.com/en/blog/webgl-more-webgl-security-... Edit I should have given a quote from one of the articles covering the issue, so here's one: > anyone running Firefox 4 with WebGL support is vulnerable to having malicious web pages capture screenshots of any window on their system

kvark 7y ago
It's up to the browser to decide if it's enabled by default at some point in the future. There is nothing in a Web API saying that it has to be forcefully enabled. I do share the concern that security of talking to the GPUs is hard. We'll do our best. I think it's important for the Web platform to reach this capability. Interestingly, the implementations are more diverse, because there isn't a single Angle-like library that everyone is going to use. This may mean that it's easier to find a vulnerability in a concrete browser, but harder to make an exploit that works portably.
- JulienSchmidt 7y ago
  I feel like this should require the user's explicit permission, just like audio, camera, location or Flash and Java Applets at the end of their life. WebGPU is a great innovation, but we have both privacy and security concerns here. It should be available where and when the user wants it, not silently in the background.
  - vasco 7y ago
    Why don't you say the same about CPU or RAM? In the end it's just resources that are abstracted away to the user, used with the purpose of performing tasks in the most efficient way possible.
    - _jal 7y ago
      Because some resources have mature security controls around them, and some don't. Why do you care if someone can see your bank account number? In the end they're just numbers.
      - e12e 7y ago
        > Because some resources have mature security controls around them So we thought, then ROWHAMMER arrived..
  - indolering 7y ago
    What you really want is a security first web browser, not something that must prioritize feature completeness to achieve commercial success. I would love a spin-off of the Tor browser sans Tor.
ericflo 7y ago
Whether or not the API is opt-in is orthogonal to its security hardening - this is a false dichotomy.
- jeswin 7y ago
  But that's not what parent was saying, I think. He was saying that WebGL not being opt-in was a security disaster; while saying nothing about the security hardening of the WebGL module itself. Even when a module is well tested, I'd like non-essential modules to be opt-in too.
  - m_eiman 7y ago
    I’d like Javascript to be opt-in. Turning it on by default was a mistake.
    - hutzlibu 7y ago
      You are free to disable it as a very small minority. The web is not a static document viewing anymore. Now I agree, that sites should have a static fallback, as I also do not want to run a full webapp, when all I want is a static article for example. But this is because of a different problem - the financing of most of the web, through advertisment and not the fault of javascript.
      - tracker1 7y ago
        Much like frames, iframes and window.open are really useful features... advertisers and abusers made it bad. I remember the first time I saw a popup in the 90's, my first thought was, "oh this is going to get bad." And I would never buy a product from X10.
- MaxBarraclough 7y ago
  I'm not suggesting any false dichotomy, I'm trying to reason about the likely security consequences given what we saw with WebGL in Firefox: serious security flaws in its implementation, with the features enabled in the browser by default. See my links above, one of which summarises with anyone running Firefox 4 with WebGL support is vulnerable to having malicious web pages capture screenshots of any window on their system. My thoughts are along these lines: ┌────────────────────┬──────────────────────────┬──────────────────────────────┐ │ │ Secure implementation │ Insecure implementation │ ├────────────────────┼──────────────────────────┼──────────────────────────────┤ │ Opt-in │ Minimal security impact │ Significant security impact │ │ Enabled by default │ Minimal security impact │ Security disaster │ └────────────────────┴──────────────────────────┴──────────────────────────────┘
ape4 7y ago
Fingerprinting is one security concern.
- aabhay 7y ago
  Security implications are always good to point out, though this is not unique to webGPU at all. Some fingerprinting techniques don't even require enabling javascript.
- EastSmith 7y ago
  Crypto mining is another
notyourday 7y ago
Browsers should be run in a VM, via a fake GPU which is mapped to a window ( possibly root window ) of a main desktop. Giving code fetched from the internet in real time full access to hardware, especially complex hardware, is lunacy. I'm shocked that neither Google nor Mozilla still have internalized this lesson.
- MaxBarraclough 7y ago
  The browser should simply disable WebGPU by default. It's already intended to be sandboxed, but given what happened with WebGL, I'm not convinced we can trust it. There's nothing to gain by faking a GPU. Edit For clarity, I'm saying you may as well just disable WebGPU. A CPU-based simulated GPU would indeed improve security, but its performance would be so atrocious that there would be no point having it compared to the existing drawing APIs.
  - notyourday 7y ago
    There is - it is a GPU with all the bells and whistles but even if the browser's security context is broken, the browser cannot access anything on a real desktop.
    - MaxBarraclough 7y ago
      It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues. A CPU-based fake GPU is guaranteed to have performance so poor that it isn't worth doing. This is the reason modern graphics APIs don't make provisions for CPU-based implementations. If we aren't confident in the security of the WebGPU implementation (and we're agreed that we aren't), the solution is simply to disable support for WebGPU in the browser. The browser can still offer facilities like the Canvas API.
      - notyourday 7y ago
        > It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues. That was my mistake - i was not clear. I'm talking about virtualized GPUs that can be passed to a VM running a minimum system needed to boot a browser.
ddevault 7y ago
The web is an ever growing rube goldberg machine of security vunlerabilities. The web is impossible to secure and the web will never be secure. Only browse sites that you trust, with JavaScript disabled and adblocking enabled, and hope that they haven't been compromised. This is the best you can do in the face of the reckless behavior of browser vendors.
fulafel 7y ago
A lot of other web APIs and features had rce vulnerable implementations in stable browser releases when they were new, some worse than others. Eg webaudio, SVG, etc. Not an excuse of course but tells of the cross cutting systemic problems.
moron4hire 7y ago
This is really old information

kvark 7y ago

It's up to the browser to decide if it's enabled by default at some point in the future. There is nothing in a Web API saying that it has to be forcefully enabled. I do share the concern that security of talking to the GPUs is hard. We'll do our best. I think it's important for the Web platform to reach this capability. Interestingly, the implementations are more diverse, because there isn't a single Angle-like library that everyone is going to use. This may mean that it's easier to find a vulnerability in a concrete browser, but harder to make an exploit that works portably.

JulienSchmidt 7y ago
I feel like this should require the user's explicit permission, just like audio, camera, location or Flash and Java Applets at the end of their life. WebGPU is a great innovation, but we have both privacy and security concerns here. It should be available where and when the user wants it, not silently in the background.
- vasco 7y ago
  Why don't you say the same about CPU or RAM? In the end it's just resources that are abstracted away to the user, used with the purpose of performing tasks in the most efficient way possible.
  - _jal 7y ago
    Because some resources have mature security controls around them, and some don't. Why do you care if someone can see your bank account number? In the end they're just numbers.
    - e12e 7y ago
      > Because some resources have mature security controls around them So we thought, then ROWHAMMER arrived..
- indolering 7y ago
  What you really want is a security first web browser, not something that must prioritize feature completeness to achieve commercial success. I would love a spin-off of the Tor browser sans Tor.

ericflo 7y ago

Whether or not the API is opt-in is orthogonal to its security hardening - this is a false dichotomy.

jeswin 7y ago
But that's not what parent was saying, I think. He was saying that WebGL not being opt-in was a security disaster; while saying nothing about the security hardening of the WebGL module itself. Even when a module is well tested, I'd like non-essential modules to be opt-in too.
- m_eiman 7y ago
  I’d like Javascript to be opt-in. Turning it on by default was a mistake.
  - hutzlibu 7y ago
    You are free to disable it as a very small minority. The web is not a static document viewing anymore. Now I agree, that sites should have a static fallback, as I also do not want to run a full webapp, when all I want is a static article for example. But this is because of a different problem - the financing of most of the web, through advertisment and not the fault of javascript.
    - tracker1 7y ago
      Much like frames, iframes and window.open are really useful features... advertisers and abusers made it bad. I remember the first time I saw a popup in the 90's, my first thought was, "oh this is going to get bad." And I would never buy a product from X10.
MaxBarraclough 7y ago
I'm not suggesting any false dichotomy, I'm trying to reason about the likely security consequences given what we saw with WebGL in Firefox: serious security flaws in its implementation, with the features enabled in the browser by default. See my links above, one of which summarises with anyone running Firefox 4 with WebGL support is vulnerable to having malicious web pages capture screenshots of any window on their system. My thoughts are along these lines: ┌────────────────────┬──────────────────────────┬──────────────────────────────┐ │ │ Secure implementation │ Insecure implementation │ ├────────────────────┼──────────────────────────┼──────────────────────────────┤ │ Opt-in │ Minimal security impact │ Significant security impact │ │ Enabled by default │ Minimal security impact │ Security disaster │ └────────────────────┴──────────────────────────┴──────────────────────────────┘

ape4 7y ago

Fingerprinting is one security concern.

aabhay 7y ago
Security implications are always good to point out, though this is not unique to webGPU at all. Some fingerprinting techniques don't even require enabling javascript.
EastSmith 7y ago
Crypto mining is another

notyourday 7y ago

Browsers should be run in a VM, via a fake GPU which is mapped to a window ( possibly root window ) of a main desktop. Giving code fetched from the internet in real time full access to hardware, especially complex hardware, is lunacy. I'm shocked that neither Google nor Mozilla still have internalized this lesson.

MaxBarraclough 7y ago
The browser should simply disable WebGPU by default. It's already intended to be sandboxed, but given what happened with WebGL, I'm not convinced we can trust it. There's nothing to gain by faking a GPU. Edit For clarity, I'm saying you may as well just disable WebGPU. A CPU-based simulated GPU would indeed improve security, but its performance would be so atrocious that there would be no point having it compared to the existing drawing APIs.
- notyourday 7y ago
  There is - it is a GPU with all the bells and whistles but even if the browser's security context is broken, the browser cannot access anything on a real desktop.
  - MaxBarraclough 7y ago
    It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues. A CPU-based fake GPU is guaranteed to have performance so poor that it isn't worth doing. This is the reason modern graphics APIs don't make provisions for CPU-based implementations. If we aren't confident in the security of the WebGPU implementation (and we're agreed that we aren't), the solution is simply to disable support for WebGPU in the browser. The browser can still offer facilities like the Canvas API.
    - notyourday 7y ago
      > It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues. That was my mistake - i was not clear. I'm talking about virtualized GPUs that can be passed to a VM running a minimum system needed to boot a browser.

ddevault 7y ago

The web is an ever growing rube goldberg machine of security vunlerabilities. The web is impossible to secure and the web will never be secure. Only browse sites that you trust, with JavaScript disabled and adblocking enabled, and hope that they haven't been compromised. This is the best you can do in the face of the reckless behavior of browser vendors.

fulafel 7y ago

A lot of other web APIs and features had rce vulnerable implementations in stable browser releases when they were new, some worse than others. Eg webaudio, SVG, etc. Not an excuse of course but tells of the cross cutting systemic problems.

moron4hire 7y ago

This is really old information