Live data from Hacker News

Show HN: I built an HTML5 RTL-SDR application

radio.ea1iti.es

41–50 of 62 posts

Re: Show HN: I built an HTML5 RTL-SDR application

#41
post #35

Earlier quoted context omitted.

I'd say predicting instances of abuse of this API is tied to usage of the API, not existence of the API. I'd argue it's extremely generous to say we'd see a case of abuse after 10 deployments of this API. Can we point to at least 10 deployments of this API? [Ed.:] https://github.com/webusb/awesome lists applications using this API. It's 11≈14 depending on how you count. Most of them are pretty fringe, except arguably…

That doesn't make any sense. The API is available for abuse independently of how many legitimate users there are. Or are you thinking only about attacks where the attackers have a genuine reason to ask for USB access? Because IMO that is going to pretty rare, and also not very interesting because in those cases the alternative is you download an executable with unlimited permissions. But in any case it makes no diffe…

I'd argue that:

- a large part of privacy issues only exist under legitimate use cases

- a comparatively smaller but still relevant part of security issues would involve attacking (e.g. code injection) a legitimate web application (which the user may already trust) as a first step, and progressing from there

- the fact that such few genuine use cases exist makes users much less likely to accept any illegitimate use, since it will be a permission request box that they have never seen before and haven't been desensitized to

Re: Show HN: I built an HTML5 RTL-SDR application

#43

it's a chrome application not an html5 one. It only works on one browser (and its forks) because it uses proprietary, nonstandard apis.

> because it uses proprietary, nonstandard apis What are the other APIs to have USB access?

Write a proper GUI application.

Re: Show HN: I built an HTML5 RTL-SDR application

#44
post #26

Earlier quoted context omitted.

The UI makes it very obvious as you have to select a device. Anyone who is worried, including corporations, can disable it.

The UI also very temptingly looks like all the website can do is use the device for its intended function, because that's how normal users think and how it should work. But most devices were built with an assumption of trust between the driver and hardware, and now suddenly there's a security boundary there. With this there's an untrusted agent interacting with a device that may have vulnerabilities, which can itself…

What's the difference between a website accessing the USB device, and downloading an app that accesses it? (Apart from the website being more convenient and cross platform.)

To put it another way, why is it ok to trust Arduino.exe but not Arduino.com?

Re: Show HN: I built an HTML5 RTL-SDR application

#46
post #26

Earlier quoted context omitted.

The UI also very temptingly looks like all the website can do is use the device for its intended function, because that's how normal users think and how it should work. But most devices were built with an assumption of trust between the driver and hardware, and now suddenly there's a security boundary there. With this there's an untrusted agent interacting with a device that may have vulnerabilities, which can itself…

What's the difference between a website accessing the USB device, and downloading an app that accesses it? (Apart from the website being more convenient and cross platform.) To put it another way, why is it ok to trust Arduino.exe but not Arduino.com?

> What's the difference between a website accessing the USB device, and downloading an app that accesses it?

Arguably the browser is far more secure. A hypothetical "Arduino.exe" can access anything, not actually select the USB device the user selected due to a bug.

Re: Show HN: I built an HTML5 RTL-SDR application

#47

Earlier quoted context omitted.

The UI makes it very obvious as you have to select a device. Anyone who is worried, including corporations, can disable it.

The problem isn't the UI, the problem is that like all software, browsers have bugs, and a CVE in this part of the code base could have catastrophic consequences. Chromium and its derivatives are highly reviewed code bases, both by good and bad actors, and there's still a considerable list of CVEs every year.

> The problem isn't the UI, the problem is that like all software, browsers have bugs, and a CVE in this part of the code base could have catastrophic consequences. Chromium and its derivatives are highly reviewed code bases, both by good and bad actors, and there's still a considerable list of CVEs every year.

That is an argument against any feature whatsoever beyond maybe a JS-free links/lynx browser. The worse browser bug is a sandbox escape that can obtain root privileges. This has been done by exploiting many different JS features. USB communication is not more of a hazard than webgl or setTimeout().

Re: Show HN: I built an HTML5 RTL-SDR application

#49
post #26

Earlier quoted context omitted.

The UI also very temptingly looks like all the website can do is use the device for its intended function, because that's how normal users think and how it should work. But most devices were built with an assumption of trust between the driver and hardware, and now suddenly there's a security boundary there. With this there's an untrusted agent interacting with a device that may have vulnerabilities, which can itself…

What's the difference between a website accessing the USB device, and downloading an app that accesses it? (Apart from the website being more convenient and cross platform.) To put it another way, why is it ok to trust Arduino.exe but not Arduino.com?

The extra friction is a feature. People just click through popups that stop them from doing things in existing apps and on the websites. I'm sure I've accidentally allowed something before just because an element was underneath before the popup.

On the other hand, you don't accidentally install an app.

Re: Show HN: I built an HTML5 RTL-SDR application

#50

Earlier quoted context omitted.

The problem isn't the UI, the problem is that like all software, browsers have bugs, and a CVE in this part of the code base could have catastrophic consequences. Chromium and its derivatives are highly reviewed code bases, both by good and bad actors, and there's still a considerable list of CVEs every year.

> The problem isn't the UI, the problem is that like all software, browsers have bugs, and a CVE in this part of the code base could have catastrophic consequences. Chromium and its derivatives are highly reviewed code bases, both by good and bad actors, and there's still a considerable list of CVEs every year. That is an argument against any feature whatsoever beyond maybe a JS-free links/lynx browser. The worse bro…

> USB communication is not more of a hazard than webgl or setTimeout().

It is though. setTimeout is very limited. WebGL does lots custom allocations which are ripe for exploits (like the native arrays in JS). USB has all that + the scope of every device plugged in which may come with its own issues.

Post reply on HN