5 ms·

> Would you download random native programs and give them hardware access? No. But I wouldn't grant a "random" website hardware access either. A reputable nat

> Would you download random native programs and give them hardware access? No. But I wouldn't grant a "random" website hardware access either. A reputable native program with a legitimate reason for requesting hardware access though? Sure. Why shouldn't I be able to do the same for a reputable website?

nexuist 7y ago
The case for a reputable website is even stronger given that you can literally inspect the source code as it runs. While a native program might require disassembly and de-obfuscation, a website can only deliver JavaScript that can just be copy-pasted into a text editor. The one exception I can think of might be WebAssembly, but to date most native features (like location, filesystem access, even manipulating the DOM) require interop with JS to be used by wasm.
- toast0 7y ago
  Plenty of websites minify their javascript, which is on the train to obfuscation. Javascript is definitely obfuscatable if desired.
josteink 7y ago
> No. But I wouldn't grant a "random" website hardware access either. We’ve trained people unskilled in IT that’s apps are dangerous and websites are safer. They’ve finally gotten it. So let’s make websites unsafe, only one click away (which we know users will click)! What a great idea!
- Ajedi32 7y ago
  Sounds like your only objection is over how scary-looking the prompt is? Running a downloaded executable is already "one click away", and connecting a website to a Bluetooth device isn't nearly as dangerous as running an executable. The difference in levels of access and size of the exposed attack surface is huge.
  - josteink 7y ago
    It’s all baby steps. WebDRM: subvert control of the machine from the user. WebUSB: allow browser-based attacks on physically connected hardware. WebBLE: allow browser-based attacks on wirelessly connected gadgets too! What’s next? WebDMA? WebFdisk?
- CamperBob2 7y ago
  Sorry, but an industry that constrains progress to keep up with its slowest users isn't what I signed up for.

nexuist 7y ago

The case for a reputable website is even stronger given that you can literally inspect the source code as it runs. While a native program might require disassembly and de-obfuscation, a website can only deliver JavaScript that can just be copy-pasted into a text editor. The one exception I can think of might be WebAssembly, but to date most native features (like location, filesystem access, even manipulating the DOM) require interop with JS to be used by wasm.

toast0 7y ago
Plenty of websites minify their javascript, which is on the train to obfuscation. Javascript is definitely obfuscatable if desired.

josteink 7y ago

> No. But I wouldn't grant a "random" website hardware access either. We’ve trained people unskilled in IT that’s apps are dangerous and websites are safer. They’ve finally gotten it. So let’s make websites unsafe, only one click away (which we know users will click)! What a great idea!

Ajedi32 7y ago
Sounds like your only objection is over how scary-looking the prompt is? Running a downloaded executable is already "one click away", and connecting a website to a Bluetooth device isn't nearly as dangerous as running an executable. The difference in levels of access and size of the exposed attack surface is huge.
- josteink 7y ago
  It’s all baby steps. WebDRM: subvert control of the machine from the user. WebUSB: allow browser-based attacks on physically connected hardware. WebBLE: allow browser-based attacks on wirelessly connected gadgets too! What’s next? WebDMA? WebFdisk?
CamperBob2 7y ago
Sorry, but an industry that constrains progress to keep up with its slowest users isn't what I signed up for.