Comment by jkot

10 years ago

> security risk is the product of defect rate multiplied by attack surface.

Call me crazy, but security sensitive application should not have direct access to 3D acceleration, microphone, camera, USB etc.

8 comments

jkot

Reply
pdkl95  10 years ago

Not only should it not have direct access to hardware[1], important data such as private keys shouldn't even be directly accessible by any part of the browser. We've known how to keep keys in their own management process for a long time (e.g. pgp-agent, ssh-agent).

[1] Putting USB anywhere near the web may be the stupidest idea I've ever heard. Attempts to add USB access to the browser should be seen as an attack. A camera or microphone can be a serious security problems, but failures in those features can (at least theoretically) be limited to features related to a specific hardware. Failures related to the USB buss can grant access to a lot of hardware that was never designed for security.

btrask  10 years ago

See the later quote:

> (It should also be possible to block or control access to each of these.)

The good news is that the capabilities of the sandbox don't need to be every-expanding, the way browsers have been. The sandbox should support everything the hardware can do, and then there are policy decisions about what capabilities web pages actually get.

  • coldcode  10 years ago

    > The sandbox should support everything the hardware can do

    Until you can emulate a hardware GPU in software at the same performance point, your sandbox is unusable. The web is more than text.

  • TeMPOraL  10 years ago

    At this point the sandbox is indistinguishable from your OS.

    • btrask  10 years ago

      The difference is priorities. By separating them, your OS can be fast and featureful, and your sandbox can be secure. Better yet if there are several competing, portable sandboxes, so you can choose the best OS and best sandbox separately.