Here is the original Minetest project if someone has missed it: https://www.minetest.net/.

The Bluetooth classic, the variant which is typically used for audio and handsfree use cases, does not support address randomization. However, Bluetooth classic device does not necessarily need to be in discoverable mode for paired device to be able to connect. Typically they are discoverable only when they are set to some kind of pairing mode.

Bluetooth LE, which is used for wearables like smart watches etc, supports address randomization and it has mechanism for finding paired devices even though the address changes. Bluetooth LE devices must advertise for other devices to be able to connect. Many headsets nowadays use classic Bluetooth for audio streaming and handsfree but in addition they use Bluetooth LE for configuring the headset through their app. That is why the headsets are often advertising all the time.

As a side note, contact tracing apps are making our phones also to advertise. Fortunately they are using address randomization properly to ensure phones can't be tracked.

Assuming that all these headsets are bluetooth "classic", since I am yet to see a bluetooth low energy headset, how could they be tracked, anyway?

Were the headsets all in "discoverable" mode ? Are headsets announcing their MACs even when not in discoverable mode ? Or do they broadcast their MACs in plain text even during a paired&encrypted connection ?

Most likely no. LE Audio requires controller support for Isochronous channels which is major part of Bluetooth 5.2. Usually firmware updates for bt chipsets are more like bug fixes than new features.

Not to mention majority of devices on the market already ship from the factory with depleted firmware update slots. https://www.youtube.com/watch?v=4_nI9ok7iQg

Specifications will be published during the first half of 2020. Afaik specs will be public but some kind of qualification may be required.

I enjoyed it too. It reminds me of The Cuckoo's Egg by Cliff Stoll. Both were written in very similar style.

Comparing Zephyr and TNEO is like comparing apples and oranges. Zephyr is full fledged operating system with networking etc while TNEO is more like basic building blocks of os for those who want to implement everything themselves.

I can warmly recommend Zephyr for BLE usage. It is up to date with recent bt specs and implementation is really solid.

Thanks, I had no idea how many options there are

Well, those are mostly just vendor specific drivers.

Actual Bluetooth kernel code can be found here: https://github.com/torvalds/linux/tree/master/net/bluetooth

IMO it is quite well organised and readable.

Sorry - didn't mean to suggest it's not organized and readable. More that the sheer magnitude makes it not approachable. There's a LOT going on there.

As someone else pointed out it is not actually bandwidth problem. Reason behind this is that high quality audio streaming profile A2DP is one-way only and once mic is needed, profile is changed to bidirectional but low quality HSP. My workaround for conference calls is to use my MacBook's internal microphone instead of one of my Bluetooth headset.

I suspect that the underlying reason that the profile switch happens, though, is because of bandwidth limits. That’s what Sennheiser is telling their customers, at least.

https://sennheiseruk.happyfox.com/kb/article/175-different-b...

The real answer may be more subtle than that. Maybe there is just enough bandwidth, but using it would have an adverse effect on latency, which bidirectional use cases are more sensitive to.

Either way, the profiles were designed within constraints. They’re not arbitrary.

Similar idea than https://uriteller.io. This is nice way to check whether your end to end encrypted chat is really secure or not.

Uri Teller is a perfect name, that's brilliant.

I created a similar idea a while back when Gmail started caching images. The main advantage is the image itself contains the log: http://cache-logger.herokuapp.com/hello-world

Code can be found here: https://github.com/kale/image-cache-logger

This is brilliant. They recommend using a url shortener, but I want to see if anyone is parsing comments and visiting urls from HN.

https://uriteller.io/7S6asCJSwrOzApjG84hIRA

Edited to add:

Here's the view key if you're interested. Just append it to the end of uriteller.io:

ZBt0gGoUHtIsyQ7KFwikYg

A crawler on AWS hit it two minutes after I posted it.

Lots of Mac users with out of date OS :S https://uriteller.io/ZBt0gGoUHtIsyQ7KFwikYg

I clicked the link, but I'm not a bot, I swear!