Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: OpenBLE, Swagger for Bluetooth

demo.openble.org

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Show HN: OpenBLE, Swagger for Bluetooth

#21

Post by crote »

candiddevmike wrote: post #3
SV_BubbleTime wrote: post #2

> Even though shunned by Apple and Mozilla, Web Bluetooth enjoys wide support and just works. That’s an interesting way to say Chrome Only feature but you shouldn’t care because Mozilla ran Firefox into 3%/ground and Safari doesn’t matter. IDK… to the point of the project… I guess that’s cool. But once you have defined and tested your GATTs, it hasn’t been my experience to come back to it a ton of times. I just wrote…

What justification is there for not implementing this across all browsers?

Security.

A lot of hardware devices pretty much implicitly trust the device on the other side of the data connection, because historically anyone able to run software on a machine also has physical access to the device. This resulted in devices accepting firmware updates over Bluetooth, for example, because how else would you update the firmware?

And now with protocols like Web Bluetooth, the only thing standing between between the average user and a random website completely owning their physical hardware devices is a single "I agree" permission popup.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#22

Post by jwells89 »

johnny22 wrote: post #11
candiddevmike wrote: post #3

Earlier quoted context omitted.

What justification is there for not implementing this across all browsers?

because there's still a huge argument about what features from the host system that the web browser should be able to deal with. Lots of people think that webusb, webserial, webbluetooth and similiar things are a security and/or privacy nightmare.

And while some argue that it's enough to put these features behind permission dialogs, browsers already have enough of those that many users will blaze through and approve anything that pops up in order to silence the noisy browser and make the page work as expected, which naturally has major implications.

That's not to say that WebUSB, WebBluetooth, etc shouldn't exist, but clearly putting everything behind dialogs doesn't scale and something better needs to be figured out.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#24

Post by seanalltogether »

I don't know about other people, but I've worked for 2 companies now that don't use numerous GATT characteristics to handle numerous operations. They use 1 characteristic with a notify handler and specify numerous operations to go over that characteristic. Discovery time is the reason for doing this. So while this ble swagger type thing might be valuable for simple devices, it might not relevant to more heavy users of ble.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#25

Post by CamperBob2 »

candiddevmike wrote: post #3
SV_BubbleTime wrote: post #2

> Even though shunned by Apple and Mozilla, Web Bluetooth enjoys wide support and just works. That’s an interesting way to say Chrome Only feature but you shouldn’t care because Mozilla ran Firefox into 3%/ground and Safari doesn’t matter. IDK… to the point of the project… I guess that’s cool. But once you have defined and tested your GATTs, it hasn’t been my experience to come back to it a ton of times. I just wrote…

What justification is there for not implementing this across all browsers?

"B...b...b.but the bad guys might use it."

We would never have had PCs with the attitude seen in this thread.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#26

Post by ryukoposting »

seanalltogether wrote: post #24

I don't know about other people, but I've worked for 2 companies now that don't use numerous GATT characteristics to handle numerous operations. They use 1 characteristic with a notify handler and specify numerous operations to go over that characteristic. Discovery time is the reason for doing this. So while this ble swagger type thing might be valuable for simple devices, it might not relevant to more heavy users o…

Same here. One company did use a handful of GATT characteristics, but some of them still served a dozen different purposes.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#27

Post by jtrueb »

seanalltogether wrote: post #24

I don't know about other people, but I've worked for 2 companies now that don't use numerous GATT characteristics to handle numerous operations. They use 1 characteristic with a notify handler and specify numerous operations to go over that characteristic. Discovery time is the reason for doing this. So while this ble swagger type thing might be valuable for simple devices, it might not relevant to more heavy users o…

I am of the opinion that a community-backed, portable library of encoders/decoders for a single L2CAP stream or notified characteristic would be far more useful than numerous "standardized" services. I often find the implementation lacking and have to implement something custom, which is nearly always easier over a single characteristic. Something in C++ or Rust would be ubiquitous enough that it could have one counterpart in firmware and another in Android/iOS/WASM. Many GATT characteristics do not handle compression or time-series data well, and there is no shim without going custom over your own characteristics. When I need something optimal, I am probably not using a standard BLE service.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#28

Post by ryukoposting »

greggsy wrote: post #23

Seems to be unsupported on any iPhone browsers - I’m assuming it’s WebKit constraint?

The only mainstream browser that supports Web Bluetooth is Chrome. Maybe Apple told Google "no, don't implement that." There are good reasons for that. Web Bluetooth's usefulness is dubious, and the potential for exploits is massive.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#29

Post by ryukoposting »

As another commenter mentioned, it's common practice to shove all your device's functionality into one characteristic to reduce service discovery time (and, in some cases, memory footprint in firmware). With that in mind, can OpenBLE be used to describe the structure of the bytes being read, written, and indicated by the characteristics?

OpenAPI is useful because it not only generates a frontend for testing an API, it also can be used to generate the skeleton of an API's implementation. Can I generate Zephyr macros using this tool? Can I generate Android or iOS code? A complete tool should be able to generate firmware, Android, and iOS code for both a GATT server and client.

As a professional firmware engineer working in IoT, I'd advise against hanging your hat on Web Bluetooth. Bluetooth is already rife with security problems, and exposing direct control of it to a browser is asking for zero-day nightmares. This is beside the antipattern involved in asking web apps to directly control a peripheral's communication interface.

Re: Show HN: OpenBLE, Swagger for Bluetooth

#30

Post by SV_BubbleTime »

CamperBob2 wrote: post #25
candiddevmike wrote: post #3

Earlier quoted context omitted.

What justification is there for not implementing this across all browsers?

"B...b...b.but the bad guys might use it." We would never have had PCs with the attitude seen in this thread.

The browser does not need to be an OS.
Post reply on HN