Bluetooth's Complexity Has Become a Security Risk
wired.com
wired.com
I end up pairing/unpairing my home speakers with my phone constantly, not because bluetooth is brittle, but because Android doesn't have options like "remember pairing but don't automatically connect with this device", or, "select audio output", or, "do/dont continue playing audio when this device loses connection". Otherwise, when I turn my headphones on to bike to work in the morning, my phone will be paired with the speakers, and the headphone will connect for calls but not audio.
I don't want linux-like configuration. I don't want to root my phone. But having no control on these thousand dollar devices over the most common tasks we use them for despite billions in R&D and tens of thousands of developers is ludicrous.
I'm curious if the problems are with Android, with non-premium speakers/headphones, or a combination of the two? And why? (Is it not following the spec, bad UX, or insufficient QA/testing?)
Mine have been terrible. I have a 2018 MB Pro and a pair of QC35 II and it stutters dozens of times during the day. Before that I had a 2014 MB Pro and a cheapo BT headphone and have similar issues.
None of this happens with those two peripherals on my Dell work laptop (Dell Precision 5200).
I want linux-like configuration. It's the only way to be sure.
More options are great, but currently we have none, and if it requires root access it'd be useless to most "regular" consumers.
A better solution would be more robust cross platform Bluetooth stacks. We have tons of high quality, open source TCP/IP networking software, elliptic curve cryptography and key exchange libraries. The same needs to be done for Bluetooth. If companies like Google have enough money to relaunch and rebrand IoT home assistants every other week and publish new networking stacks written in Go for their latest container orchestrator/mobile OS/browser every 6 months then I am sure they can find time and funding for better Bluetooth firmware.
Those two modes aren't quite good enough, though. One recent fun episode occurred when I walked up to our house and started doing some work outside, while both I and someone inside were listening to music. For some reason, my phone automatically disconnected from my headphones, and connected to the bluetooth speaker inside, somehow disconnecting whatever it was originally connected to. So, for the person inside, the bluetooth speaker stopped playing their music and started playing something random, which proceeded to start and stop a few times, and then get louder and louder and LOUDER while I was standing outside, fiddling with my phone and headphones, trying to figure out why my music stopped playing.
My guess is that the root cause is that there's a crippling design flaw at the root of the Bluetooth spec: Its original designers apparently never considered the possibility that multiple people might share their electronics.
So ironically it was designed to do anything & everything, like USB, but now it's a two-trick pony.
Their wireless audio protocol is bad and they should feel bad.
"Hey let's make everybody use the unregulated band for a basic function so that we make our phones thinner and we can sell more expensive accessories, how about that"
Bluetooth can be good but there are just too many devices which are 'bluetooth compatible' in theory but have many odd incompatibilities. Perhaps it is the complexity of the spec that causes this to happen to bluetooth, rather than wifi...
I've literally never had any problems connecting any of these to any devices (desktop PC, iPads, iPhones).
Bluetooth also seems to work pretty much perfectly with my car as well.
I'm not doubting you have problems - but interesting to note that for some people Bluetooth does actually seem to work.
I still don't know how to unpair on some black boxes. My partner has a speaker, and I think auto-pairing occurs if used previously, so we have a strange ritual of turning off bluetooth on other devices until it seems to correct itself when wanting to use it.
I've always assumed this was a UI issue.
I've had phones that have presented themselves as a pointing device to a computer. Some as modems. Some that have transferred/pushed files okay on some OSs, not others. I have no idea what's going on with Bluetooth most of the time, and it's quite infuriating. On Linux Blueman doesn't give much away. On a Windows PC I have, using Bluetooth kills WIFI, and requires a reboot to fix.
From a mobile perspective if I say try and transfer a file from a phone, it can turn Bluetooth on, fail and then leave it on.
Wireless headphones sound like a great idea though! But again not sure which protocols are being used. Again that's a UI issue, I've a streaming speaker - and have no idea about the stream quality of what I'm listening to. Oh for some simple feedback diagnostics.
Mind you - I never 'unpair' a device - I just set the BT device to be in pairing mode (or whatever it is called) and then connect from my phone/tablet and that removes the previous connection. Having to do this on both devices and that the step necessary to initiate pairing is device specific is the only issue I have with BT - but it's a relatively minor one.
Linux though is a complete disaster: when I turn the headphones on I _always_ have to manually disconnect them and reconnect. Even so, from time to time they stick to the audio only profile and there is not way to use the embedded microphone unless I disconnect them, turn them off, turn them on and repeat the incantation.
You can't charge and listen at the same time (wtf)
I get no warning when the battery is about to die (combined with the above this really sucks, they shut off in the middle of something)
I dual boot OSX and Windows on my laptop and I have to re-pair the headphones every time I switch OSes. I suspect each OS has a different encryption key, but the headphones can't tell the difference between which OS is running.
They cut out and skip all the time when walking through the City. They are borderline unusable when walking between the train station and my office.
They cut out and skip occasionally when not walking through the City, for no discernable reason.
They have an obnoxious and unnecessary blue LED that blinks periodically when they are turned on. This lights up our whole bedroom at night and annoys the crap out of my wife. I have to keep a piece of black electrical tape over the LED.
These are the best bluetooth headphones I have ever owned, they sound great, and I absolutely hate them.
These were an inexpensive model, but were nonetheless very well-reviewed on many tech sites, and often recommended as one of the top budget options.
I use mine when I commute by train into Edinburgh and they really haven't given me any problems - I didn't even know they had a blue LED until I checked there... :-)
Battery life is good enough for my purposes - but I do make a point of keeping them charged up as I live in fear of a commute without an audiobook! They certainly don't cut out for me.
Your suspicion is correct.
The real problem is that Apple and Microsoft both have not provided any way to specify the key to connect with, and they both paired independently, creating a different key each time.
One solution would be to find where the link key was stored in one of the OSs and copy it over to the other OS. Then they would both use the same link key and you are good to go until you re-pair for some reason. I don't know if this (still) works, but some instructions are here:
https://www.insanelymac.com/forum/topic/268837-dual-boot-bluetooth-pairing-solved/
For example, I have a microsoft bluetooth mouse that is utterly painless & two AA batteries last for something like a year working full time. Also have a pair of Jabra 65t, pairing is annoying and on rare occasions it hiccups, but 97% of the time they are excellent. I had owned BT mice & headphones previously, and they have never been better than today.
For many of the tasks you'd want high bandwidth for, you probably want WiFi (or even point-to-point WiFi established over Bluetooth LE like AirDrop). LE is a huge step forward because it distinguishes between the two major use cases (low bandwidth - low power - promiscuous mode vs. high-bandwidth - paired) and allows for the development of standards which meet each use case without compromise. Part of why Bluetooth was pretty garbage before is that its use cases overlapped so heavily with WiFi, but it wasn't allowed to (or ever going to) replace it. This lead to this weird hybrid high-power, middling bandwidth, paired but you-probably-dont-want-it-to-be spec.
LE 2 (Bluetooth 5) addresses some of your concerns by increasing the bandwidth available for LE devices, without compromising on power efficiency.
The Tesla Model 3 uses traditional Bluetooth for phone calls and streaming but the Phone as a Key functionality is BLE. When you walk up to the car and try to open it and the car says FU then BLE isn't working.
When your Xiaomi Mi Band smartwatch hasn't buzzed all day but you pull your smartphone out of your pocket and have 8 missed calls, 100 messages, and 500 emails then BLE isn't working.
When you're at a Tech Conference and the Conference App uses BLE Beacons to help navigate you indoors and it can't determine your location then BLE isn't working.
For example, a lot of re-pairing issues come about from the device resetting its own device ID. Some rare devices do this on every soft-power-cycle. A good many devices do it on recovering from power-failure (e.g. dead battery). At that point, the device is basically a completely different "device". The best devices keep their device ID in non-volatile memory so they can recover from power failure without resetting their device ID.
Having built a few BT devices as a hobbyist, it's not really that hard to make a good pairing experience. You just have to... think things through and not do the most bare minimum work.
Perhaps BT would be better with certification.
I stress "from minor to major"; in my experience BT does ultimately work, but there are always minor, odd, kinks like (I assume) an Android update preventing my headhphones to establish a "media" connection 50%+ of the time.
Given that also my high-end devices are subject to problems (eg. ~400$ mobile phone with ~400$ headphones), then the specification may be technically correct but practically unusable.
To me, "practically unusable" == "broken".
Another issue I see is more of a view point that people have trouble shaking. Typically we think of the server as being more powerful than the client, but in BLE the client usually has more processing power and battery by several orders of magnitude. Once you examine this preconception BLE makes a whole lot more sense.
Bluetooth is really a good bad example of committee design.
Compared to HTTP/TCP/IP, abstractions between layers of the BLE stack are extremely leaky. Examples: indicating choice of PHY coding and channels in the equivalent of a `listen/connect` call, or the three different but intertwined places where fragmentation/reassembly can happen. Being effective with BLE requires deep understanding of the entire stack, and since it is difficult for a single person to have such level of understanding, we get bugs. By comparison, being effective with HTTP does not require one to know anything about the PHY layer, or TCP stream reassembly.
I suspect this is due to not having enough independent implementations of each layer - Bluetooth is designed and standardized by one committee, and the entire stack usually implemented as a single "thing", making it too easy to break abstraction when a new feature needs to be added.
Bluetooth or LE? LE with GATT in my experience deals with none of this. At least not on an Apple product, CoreBluetooth hides all of this from me as an iOS or macOS developer.
Maybe not PHY, but you definitionally need to understand TCP, in fact, you have keep-alive and timeout headers that are directly related to TCP. Further more, HTTP/2 is a whole another level of leaky when it comes to HTTP/TCP.
Do you have any idea how bloody insanely complex bluetooth is?
Just the the core stuff,
https://www.bluetooth.com/specifications/bluetooth-core-spec...
without the various protocol specs... https://www.bluetooth.com/specifications/protocol-specificat... or the GATT or ...
The bloody core spec is 3000 PAGES of standardese.
All in stuff that costs less than a dollar per chip.
silicon is free. you are paying for the r&d. that’s why volume matters. at the volume of bluetooth chips, they are almost indeed free. most of that dollar is distribution costs.
my point is, the cost of the chip isn’t a signal of anything except the ubiquity of it.
But _none_ of your consumer level gadgets are made by broadcom.
Broadcom will sell millions of these cheap as chips chips to second tier players.
Who may sell on to third tier players.
Who buy or pull a bluetooth stack and sort of vaguely maybe know what they doing, tie it all together and get the BT compliance stamp (which sort of means it doesn't shit all over the RF spectrum and vaguely works)...
...and then the sell it to you.
ie. The chip manufacturer hopefully has clue.... then it gallops rapidly downhill from there.
BT is massive but that's mostly BT classic which is slowly going away as more and more chips are BLE only which is saner. That's why we're adding isochronous channels to keep it interesting.
Yup and a simple embedded version of a useful subset of that is (just counted) about 4000 non-comment non-blank lines _just_ for the header files.
And assumes you then understand what the API does which is probably less comprehensively documented than the underlying HCI spec.
Is there something about wireless in particular that lends itself to this proliferation of complexity? I've read 802.3 (Ethernet) and it was nowhere near as dense and intimidating.
[1] MP3, JPEG, JPEG2000, JBIG2, H.261 to 264, MPEG 1 and 2, USB, SATA, IEEE1284, RS-232, a bunch of RFCs, and too many others to list, those are just the ones I remember reading recently...
It benefits all of the participants to build a big, deep moat where the paying participants have the expertise.
This is how, by the way, warts like this occur: https://news.ycombinator.com/item?id=17402274
All of the adopted core specifications, profile specifications, and errata documents are public: https://www.bluetooth.com/specifications/
A tiny (but still HUGE) part of this VAST spec is the fact that these bluetooth chips are ruddy frequency hopping radios.
Something that a decade or two ago was only seen in high end military radios.
I much prefer WiFi’s wideband spread spectrum and just letting the user pick a different carrier frequency if there’s too much interference.
And that is excluding the Type C, Type A and all other connector Spec.
And there is the newest WiFI 802.11ax or WiFi 6, Even earlier this year as I skim through it, the draft still has 2000+ comments unresolved. ( One reason I am looking forward to 802.11be to fix this mess instead )
Sometimes I do miss the day of parallel port, everything was so simple. That is may be me getting old.
This, combined with the fact that interoperability is paramount, but there are only a few providers make for complicated standards. The interop between a few providers problems means the standards have to bow to actual usage a lot more.
This applies a lot more to 3gpp (cellular) stuff than WiFi though. Especially because 3gpp is commercial only, is a lot more 'trust the network', and cares about billing. Moreover, the interop is meant to give a pretty seamless roaming ability, whereas e.g. 802.3 is only about working on a single subnet.
Moreover with WiFi, which partially uses time-division (like ethernet) you cannot have two devices sending at the same time. However, unlike old-style shared medium Ethernet, you can have two devices outside of range of each-other, but both reaching your WiFi router. This means the transmissions scramble each other at the router, but the devices can't detect this.
Hence, you cannot do CSMA/CD (collision detection) but need CSMA/CA (collision avoidance). This means you get ACK messages at layer 1 of your protocol.
In general, it might be the Multiple Access model that makes wireless hard.
You stole my comment! No but in all seriousness, this is a long-standing issue. The A) requirement of making BT-enabled devices backwards compatible, B) the monstrous stack of protocols involved in like every use-case, & C) an assumption that Spread-Spectrum Frequency Hopping @ the physical layer is a substitute for encryption, all combine to make a BT kind of especially terrifying.
Take for example the Nike Fit Band, an iconic bluetooth peripheral that's been on the market for some time:
2015: https://securelist.com/how-i-hacked-my-smart-bracelet/69369/
2016: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4737495/
2017: https://www.zdnet.com/article/bluetooth-security-flaw-bluebo...
I'm sure I can find one from last year as well, but you get the point.
Also here's this for good-measure: http://ubertooth.blogspot.com/
Making protocols & specs no more complex or ambiguous than necessary is a hard requirement in this modern, security-conscious world.
The point is to make specs that people actually WANT to use, which requires advocacy (to get more eyeballs on it), and collaboration (to fix things I've missed).
I build these things to scratch an itch, but I want others to find them useful, as well.
It's about "god" standards, designed to encompass all other standards, a theme common in the 90s.
Recently, I rented a Dodge mini van. Was all they had.
The pairing is voice. Fucking menu via voice! It took 10 minutes...
Please say:
Manage devices Add a new device Configure . . .
What priority, say 1 through 5...
I say 1.
Priority 1 is in use by [device name]
And on and on. I was angry when done. I will never use that POS again. Ugh!
Someone at Dodge needs to try again. I know you meant well. I know you were probably told to do it too. But damn. It is a real fail.
I hate quality changes for very thin reasons.
I hate quality changes for technical reasons.
I hate charging.
About the only time I loved Bluetooth was running windows XP and that excellent driver could pair with my old flip phone and do it all. Network, act as mic, etc... I did it once and done too. Ran that setup for a couple years until I got a better phone.
Here is the thing. Brb
Back! Had to change devices.
I can be convinced to go wireless. It is going to take more than the mess we have today.
Just renewed my phone with headphone Jack. Brand new, should be good for years.
The wireless devices need to be serviceable, the protocols need to be sane and robust too, or the whole affair is a total net loss.
It's more fair to compare BT to heavy protocols like ZigBee, or worse yet, ZWave. If you wanna dig into a shit-show of wireless protocols, look no further than ZWave. That thing is a complete boondoggle.
I've been pretty happy with BT.
I have a few Bluetooth speakers. If I accidentally close the app but forget to disconnect from settings too, then no one else can pair with them until I return. This seems like standard behavior, and makes me worry that if I lose my phone at the wrong moment, I might brick a few devices.
I really like common standards, but if the consortium can't fix either security or usability, we might be better off with a clean slate.
Airpods have the best support and they still require you to find out how to pair them when you change device and wait.
Keyboard/mouse is insane. If you want to use them with two different laptops.
I think they are symmetrical. You can use both separately, without the other.
So I have to open up the sleeping laptop just to disconnect bluetooth
Complexity Is a Security Risk
There should be a part of the protocol that determines the lag and a standard way for programs to then set their delay accordingly, so that when I'm watching a video the sound is synced with the screen. Instead I have to manually try several different lag times until one feels good enough.
Just saying.
Expensive timebombed unrepairable accessories is a small price to pay in order to have a 1mm thinner expensive timebombed unrepairable phone!
The big thing about BT is that it's everywhere.
Imagine if you had to do the standard bt pairing process for wifi. Device to connect to has to be broadcasting, Device trying to connect has to be listening, after connection you have to ensure that the passcodes are the same etc etc. If the connection drops then repeat the process sometimes(<BT 5.0).
[1] https://twitter.com/matthew_d_green/status/11287020035243745...
I remember it being proposed as an alternative. Is it any easier to use/secure? The high frequencies should work fine for short ranges, no?
Unfortunately, this is something that Apple does well, and most other manufacturers and operating systems have a poorer experience.
I say that as an ex-Apple user, not a fanboy. I love my Linux Desktops, but the Bluetooth pairing is a huge pain. Likewise, when I boot into Windows for games - Bluetooth peripherals are far annoying than their Apple counter-parts.
Dijkstra must be rolling in his grave.