Show HN: I built an HTML5 RTL-SDR application

[jtarrio]

There are lots of RTL-SDR applications, but you have to install them. I used the HTML5 USB API that exists in Chrome (did you know about it?) to build one that you can run straight from your browser, on your computer or your Android phone.

[vrighter]

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

[meiraleal]

> because it uses proprietary, nonstandard apis

What are the other APIs to have USB access?

[vrighter]

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

[meiraleal]

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.

[vrighter]

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

[meiraleal]

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

Let the "Safari not Supported" era begin!

[goodpoint]

Write a proper GUI application.

[someothherguyy]

nit: The WebUSB API isn't really a part of "HTML 5"

https://wicg.github.io/webusb

[ocdtrekkie]

The correct definition for WebUSB is "Chrome API", as no other browser intends to implement it.

[vbezhenar]

Edge supports WebUSB.

[katdork]

Edge is just a Chromium fork, though.

[vbezhenar]

Yes, but so is Chrome and many other browsers.

[M95D]

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

[ngc6677]

`<radio-receiver></radio-receiver>` let's get that in html6!

Nice use of web components!

[someothherguyy]

HTML is a living standard. There likely won't ever be a "html6".

https://html.spec.whatwg.org/multipage/introduction.html#his...

[ramon156]

It's a living standard for today, but no one knows what tomorrow brings

[someothherguyy]

Yeah, that is why I said likely.

[assimpleaspossi]

Exactly. And there is no HTML5, either.

[wkat4242]

I wish Firefox would implement this API too, it's been years.

[eqvinox]

Mozilla's position is to not implement this API due to security and privacy concerns, and I agree with them on that even though I'd really like to use this API too.

[IshKebab]

Given that it's been available in Chrome for 7 years, if there were any security and privacy concerns we should be able to point to at least one abuse of this API right?

[eqvinox]

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 the 3 update/flash tools and maybe the Android mirror.

I'm not sure I'd expect to have seen a case of abuse here yet.

[IshKebab]

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 difference. If the API has been available to 75% of users for 7 years, it's downright idiotic to think making it available to 77% of users will make a difference.

[eqvinox]

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

[viraptor]

Yeah... It's an accident waiting to happen with someone's security key. (Yes, I'm aware chrome tries to protect that one... for now) We really need more intentionality around hardware use. There's many SDR apps already packaged for all systems. Stop trying to juggle chainsaws, please!

[teruakohatu]

The UI makes it very obvious as you have to select a device.

Anyone who is worried, including corporations, can disable it.

[eqvinox]

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 then also interact with vulnerabilities the host may have towards USB devices.

It's not that this can't be done, it's that this is changing the rules that existing security is built on.

I would try to make it work with whitelists and/or restricting the functionality to browser add-ons rather than plain websites. Both add extra checkpoints where some security can be added back in, or rather perform this "weakening" of the previous security boundary in a more controlled manner.

[IshKebab]

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?

[Etheryte]

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.

[teruakohatu]

> 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().

[goodpoint]

Good!

[dtagames]

Awesome! There's so much you can do with the browser now. Thanks for making an SDR app that's "gone native."

[tgsovlerkhgsel]

I'm unable to get it to work with my receiver (setRegBuffer failed block=0x600 reg=74, Caused By: RadioError.UsbTransferError: USB write failed value=0x74 index=0x610 status=stall), but I love the idea!

Looking forward to a local webusb+rtlsdr based Flightradar.

[jtarrio]

Is your stick an RTL-SDR Blog V4? Because it looks like the failure happens when accessing a R828D tuner, which should be supported.

[tgsovlerkhgsel]

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

[jtarrio]

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 :-)

[tgsovlerkhgsel]

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

[jtarrio]

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...

[wkjagt]

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

[jtarrio]

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

[wkjagt]

Awesome, thank you

[atVelocet]

Do you plan on expanding the functionality?

It is really amazing how flawless it work. You should do a blog post describing how you did it.

[jtarrio]

Yes, next up is frequency/band management. Recording will come later. Later still, who knows :-)

[radicality]

Awesome! On mobile now but intend to try it with my HackRF later. Anything to consider, or should work fine?

[RF_Savage]

That it only supports rtl-sdr sticks, not HackRF. So the HackRF will not work.

[goodpoint]

What's the benefit in using a browser for this?

[RamboRogers]

This is cool!

[wordglyph]

Excellent work!

[JSDevOps]

Wow that’s cool