Live data from Hacker News

Show HN: I built an HTML5 RTL-SDR application

radio.ea1iti.es

51–60 of 62 posts

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

#51
post #34

Earlier quoted context omitted.

Unfortunately I don't know what device it is. Would a lsusb help?

If you don't know, it probably isn't; they brand it quite extensively both outside and in the USB manufacturer strings (it appears as "Blog V4" in the device selection window.) If it is indeed not one of them, I'd be interested in getting one to test on, so I'd like to know where you got it from. Can you email me? My address is trivial to find or figure out knowing my website is https://jacobo.tarrio.org :-)

I took a closer look. It's a Hama Nano DVB-T (00053330), over a decade old.

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

#52
post #34

Earlier quoted context omitted.

If you don't know, it probably isn't; they brand it quite extensively both outside and in the USB manufacturer strings (it appears as "Blog V4" in the device selection window.) If it is indeed not one of them, I'd be interested in getting one to test on, so I'd like to know where you got it from. Can you email me? My address is trivial to find or figure out knowing my website is https://jacobo.tarrio.org :-)

I took a closer look. It's a Hama Nano DVB-T (00053330), over a decade old.

Ah yeah, E4000 tuner, those were hard to come by even 10 years ago, so I didn't support them. Only R820 and R828 and compatibles...

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

#53
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?

- People have been trained to understand downloading and executing an "Arduino.exe" is potentially dangerous and that they need to check if they trust the source

- most OSes expect a digital signature on "Arduino.exe" these days

- there's a whole ecosystem of protection and antivirus software that attempts to detect malicious use

- depending on your OS, an "Arduino.exe" can't even access USB devices without an additional signed driver and/or further administrative privileges

- a code injection attack against "Arduino.exe" is much harder; unlike "Arduino.com" which can load entirely different on each visit, you need to exploit an (easier to protect) auto-update mechanism. (Depending on the use case, an application can also be just fine without an update mechanism.)

- "Arduino.exe" isn't built on an ecosystem that routinely loads 3rd party code from outside sources

And to repeat, I don't think WebUSB in general is a bad idea. I'm arguing the security model should be more restrictive; that's why I suggested:

> I would try to make it work with whitelists and/or restricting the functionality to browser add-ons rather than plain websites.

The browser add-on ecosystem is IMHO a better framework to build something like WebUSB in, but to be fair I haven't spent thought on a more in-depth evaluation of this. Also note that there's good precedence for whitelist systems, e.g. in WinUSB the USB device itself can already do some signalling. (But that doesn't work for older USB devices and has its own can of worms…)

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

#54

Earlier quoted context omitted.

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.

> Arguably the browser is far more secure.

The browser is far more secure because everything it allows access to is tightly controlled, in most cases by scoping it to the website. Even if you grant persistent camera/microphone access, it remains scoped temporally: you need to have the website opened up.

An USB device fundamentally does not support this security model. Code that can interact with an USB device can put persistent state on it without any checks enforced upon it. That USB device may later interact with other (bug-laden) code on the same system, or even worse, be moved to a different host entirely, with a different OS stack there, and trigger interactions there.

Yes, the browser is far more secure — because it has very few (anti-)features like this. I'm incredibly happy that WebUSB is not particularly commonplace to use. Having secure browsers is more important to me than the convenience of USB access from websites.

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

#55
post #38
post #37

This is awesome, great work! Is there anywhere I can follow development on this? I'm really interested in seeing this evolve.

I don't have a dedicated place for announcements and such, but I post on my Bluesky whenever there's a major improvement (@jacobo.tarrio.org). And you can always star it on GitHub: https://github.com/jtarrio/radioreceiver

Awesome, thank you

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

#56

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?

there isn't a browser based usb api. It's as simple as that. You're coding for chrome, not the web

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

#57

Earlier quoted context omitted.

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

there isn't a browser based usb api. It's as simple as that. You're coding for chrome, not the web

Chrome, edge, opera, brave and many more. Just Safari doesn't support it, as always lagging behind. Firefox is out of the equation long ago.

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

#58

Earlier quoted context omitted.

there isn't a browser based usb api. It's as simple as that. You're coding for chrome, not the web

Chrome, edge, opera, brave and many more. Just Safari doesn't support it, as always lagging behind. Firefox is out of the equation long ago.

yes.... all of those are google chrome with lipstick. Doesn't change the fact that it is not a web standard.

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

#59
post #17

Earlier quoted context omitted.

You shouldn't treat them as different brosers. They're just skins.

I don't think that's true. They are different enough.

we're talking about the engine, not the skin put on it. They're only different in the ui

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

#60

Earlier quoted context omitted.

Chrome, edge, opera, brave and many more. Just Safari doesn't support it, as always lagging behind. Firefox is out of the equation long ago.

yes.... all of those are google chrome with lipstick. Doesn't change the fact that it is not a web standard.

> Doesn't change the fact that it is not a web standard.

Let the "Safari not Supported" era begin!

Post reply on HN