Bluetooth's Complexity Has Become a Security Risk(wired.com)
wired.com
Bluetooth's Complexity Has Become a Security Risk
https://www.wired.com/story/bluetooth-complex-security-risk/
130 comments
> I don't want linux-like configuration.
I want linux-like configuration. It's the only way to be sure.
I want linux-like configuration. It's the only way to be sure.
We at minimum need a user friendly way to change anything first.
More options are great, but currently we have none, and if it requires root access it'd be useless to most "regular" consumers.
More options are great, but currently we have none, and if it requires root access it'd be useless to most "regular" consumers.
Linux like configuration is utterly terrible. At least with iOS there's usually two modes: it either connects or it doesn't. When it connects, it works flawlessly. For Linux, it's a variety of possibilities including but not limited to: able to discover device but can't pair, pairs but unable to send any files, Bluetooth daemon crashes two seconds after pairing (GUI hangs and you have to manually grep through the logcat to figure out what went wrong), Bluetooth pairs but on reboot daemon fails to start with a cryptic error code. On googling the error code leads to a post on Ubuntu StackExchange from 5 years ago that references a post on the Arch Linux forum from even further back. On IRC support, you would be recommended to install Blueman/Bluez/whatever-their-favorite-bluetooth-software on top of your distro's version. And after a whole afternoon, it still wouldn't work. When you write a blog post complaining about it, people would tell you in the comment thread to go replace your device with a "ThinkPad" cause Linux is not supposed to run properly on most laptops despite being marketed as such. And then finally two months later someone posts a comment telling you to flip an entry on an obscure config file somewhere deep within the system and the problem magically goes away. So no, I don't want Linux-like configs.
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.
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.
> At least with iOS there's usually two modes: it either connects or it doesn't.
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.
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.
It's, IMO, due to how 99.9% of the world uses their bluetooth. It could have options to control these things but for most people, they just don't care. They might own one pair of bluetooth headphones and one bluetooth mouse and one car that pairs to their phone, and that would be about it.
So ironically it was designed to do anything & everything, like USB, but now it's a two-trick pony.
So ironically it was designed to do anything & everything, like USB, but now it's a two-trick pony.
It’s funny, anytime anyone mentions the loss of the 3.5mm jack on flagship phones, the loud Bluetooth brigade conveniently forgets just how inconvenient Bluetooth can be.
My experience with Apple and Bose devices has been pretty flawless, across keyboards/mice, headphones and speakers.
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?)
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?)
The bluetooth on my MBP2017 seems to work like shit if I try to use my bluetooth headphones (Plantronics Voyager 8200UC) and a bluetooth mouse (Microsoft Bluetooth Mouse 3600). The sound will stutter and the mouse will lag, no matter if I reset the OS, and I even got the MBP replaced under AppleCare yet it didn't resolve the matter.
None of this happens with those two peripherals on my Dell work laptop (Dell Precision 5200).
None of this happens with those two peripherals on my Dell work laptop (Dell Precision 5200).
> My experience with Apple and Bose devices has been pretty flawless
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.
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.
I had been using bluetooth headphones without issues for a few years. After moving into a new apartment, I started having all kinds of intermittent problems. Turns out the microwaves in the apartment complex were pretty bad, causing a ton of 2.4GHz noise. The Chromecast would also start dropping video streams whenever my roommate would cook stuff. Is there a source of a ton of 2.4GHz noise causing your problems?
That makes a lot of sense. I had to upgrade to a newer 5 GHz router because the 2.4 was impossible to use, and I do live in an apartment complex. Thanks for the insight.
The problems with Bluetooth are it doesn't pair, it doesn't unpair, you need to unpair first, you need to use the other protocol that transmits audio, the latency is way too high, it's insecure, the software stack hangs or crashes, you can't know for sure if two devices will work together, BLE is WAY too low level and a step back, the spec is way too big and complicated, ...
In 20 years they have not managed to make it good. It seems hopeless with the current institutions managing it. What a heap of hot garbage.
I agree with you, except about Bluetooth LE. LE (4.0) is a totally different protocol than 'classic' Bluetooth (<= 3), and shares no heritage. Nokia came up with the LE spec and dropped it down on the desk at the Bluetooth SIG and told them this was Bluetooth now ("wibree", [1]). The LE family is just a short couple of years old now, not 20.
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.
[1] https://en.wikipedia.org/wiki/Bluetooth_Low_Energy
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.
[1] https://en.wikipedia.org/wiki/Bluetooth_Low_Energy
How do I tell if a device is Bluetooth LE though? It still pairs in the same list as all the other Bluetooth devices and I don't see anything that identifies it otherwise.
So it kinda sucks for LE devices to get the "bad rep" because as far as consumers are concerned, LE devices suck as well, they just don't display those same issues all the time.
LE is a different spec and behaves completely different from traditional Bluetooth. People assume Bluetooth 4+ is LE but it's not. If you're pairing with a device in the traditional Bluetooth sense, it's not LE.
... ok, so how do you know you're using LE?
It's easier to tell when you're not using BLE. :)
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.
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.
If you're streaming audio over Bluetooth (i.e. headphones or speakers), you're not using BLE, you're using classic Bluetooth, and none of this matters. BLE didn't have the bandwidth for audio until 4.2, and still doesn't have an audio standard like classic Bluetooth's headset profile.
Bluetooth LE may be only a few years old, but it already has a split between insecure legacy pairing modes that shouldn't be used and actually-decent pairing modes that only work on newer devices.
Yeah if I recall that was due to issues with security if an attacker observed the initial key exchange in 4.0 and was resolved in 4.2 and 5, right?
Every Bluetooth device I have ever tried has failed to meet my expectations. I have a drawer full of Bluetooth devices that I regret purchasing. I've been fooled too many times already, I simply won't buy a device that relies on Bluetooth any more. For mouse/keyboard I like RF and for audio you can pry my 3.5mm jack from my cold dead hands.
The AirPods are magical. The only time the magic breaks down is when you're in a place where there is a ton of signal interference (e.g. walking around in busy parts of Manhattan). Aside from that, they're about as close to Just Works as anything I've ever used in my life.
Yeah, but they're pretty mediocre headphones in terms of sound quality, and they're built as a single unit making them impossible to recycle.
From what I understand they also don't fit/stay in a lot of people's ears. A lot of in-ear headphones come with different sizes for this reason.
I don't quite understand why you're being down-voted here for a very reasonable statement. I suppose that perhaps 'a lot' is a bit hyperbolical, and it is realistically closer to 'a small few'. I had AirPods for a while, but they simply did not fit comfortably in my ears. I bought some Jabra brand wireless headphones, which come with a selection of different sized buds, and I'm very satisfied with them thus far. They don't quite have the "sleek" look that Apple does so well, but the side button functions are excellent and the call quality seems clearer when in noisy areas. I've had a few friends complain about their AirPods just about not fitting, and I always recommend the Jabra's now.
They actually stay better even if wired Apple earbuds do not. There is no wire pulling them out.
As a headphone buff and snob, I respectfully disagree. I think they sound wonderful, and I own Sennheiser HD1s and HD820s. For as small and portable and convenient and affordable as they are, they are far higher audio quality than I would expect. I use them all of the time.
So it breaks when you need it the most? Gotcha
"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"
"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"
[deleted]
I was initially rather skeptical of bluetooth headphones - but after yet another gardening related headphone incident I bought a cheap pair (£30) and they worked perfectly well. They broke (headband snapped) and I upgraded to moderately priced Sony ones (~£100).
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'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 have a pair of moderately priced Sony BT headphones. Could be a similar model given the price range.
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.
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.
"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."
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:
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/
Mine are the MDR-XB650BT - I checked and they were probably cheaper than I thought (probably ~£60).
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.
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.
My favorite regular reason for mine cutting out and skipping is when I turn my head to the right.
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.
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.
Funnily, I had the almost the same experience (started with a cheap pair of headphones, loved them, broke them, went on to a ~100EUR Sony pair).
With Android never had any problem with bluetooth devices. Windows almost never.
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.
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.
Same with me. I’ve had two bluetooth headphones, one pair from sony and one pair from bower & wilkins. Never had problem with them.
I'm surprised when it works.
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.
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.
We have a couple of those bluetooth speakers (UE Booms) and I've never had a problem with them either!
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.
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.
All the Bluetooth issues being downplayed in this thread are a far cry from wired headphones that just work.
I've found (after many bad buys) a pair of cheap bluetooth headphones that 'just work' with my iphone. The problem is, there is no way for a customer to tell whether a bluetooth device is going to work well or not (or even not at all!)
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...
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 had zero problems while using Apple products: mouse, keyboard and Airpods. Other two non-Apple products: Withings watch and Honda Civic gave me no problems either.
Microsoft makes excellent Bluetooth keyboards and mice. Sennheiser does OK with headphones, with their newest models being markedly better than ones even to years ago. There are also a few, rare, small companies that do a pretty good job: TechNet and AfterShokz come to mind.
They're getting better. It's a little reminiscent of Android, actually, which wasn't really solid until KitKat.
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 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.
Those aren't problems of Bluetooth, those are problems of device implementations. The BT protocol makes it possible to manage pairings, un-pairings, and re-pairings, in any which way that makes good sense for the user. But a lot of device manufacturers don't spend the time to read even the most basic parts of the spec necessary to manage connections.
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.
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.
I have many BT devices, from budget to high-end, and they all have problems, from minor to major.
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".
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".
Having implemented a few devices, honestly, the spec couldn't be more straight forward. It's really a case of hardware engineers being terrible at user experience. Just because a device is expensive doesn't mean the company has put all necessary effort into the BT stack. Look at how many "simple" things Apple, Google, and Facebook screw up on a daily basis.
Yes, when it comes to protocols a lot of companies seem to have an attitude of "when it works, don't touch it", and the result is a mediocre experience because they forget to look at the edge cases.
Perhaps BT would be better with certification.
Perhaps BT would be better with certification.
And you forgot one: it seems impossible to pair (e.g.) two headphones with a single phone. This makes it impossible to listen with a buddy to a single audio source.
And they wonder why there's resistance to phones that are wireless only.
Their wireless audio protocol is bad and they should feel bad.
Their wireless audio protocol is bad and they should feel bad.
In my opinion part of the problem with Bluetooth is that the API exposed by android and IOS is like... two or three layers too low. Imagine if in web programming you set the MTU size in your HTML and you get the idea of what programming Bluetooth is like.
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.
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.
It isn't even the API vendors' fault necessarily.
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.
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.
> By comparison, being effective with HTTP does not require one to know anything about the PHY layer, or TCP stream reassembly.
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.
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.
> 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.
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.
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.
Apple does hide most of this, but consider that an iPhone app isn't the BLE product most developers are building, rather it is the device that iPhone app talks to, and where the bugs lurk. (Not that Apple doesn't have its fare share of BLE bugs at the chipset/driver level, which resurface with every new iOS release.)
Become? Become!? That's funny. That's Rich.
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.
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.
I'm someone who actually likes reading standards for fun (sometimes there are interesting things in them), and have read many of them as a result[1], and even implemented parts of some; but I still find Bluetooth, along with WiFi and GSM/LTE very intimidating.
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...
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's an industry standard designed at closed door meetings where you have to pay to get in and pay to read the spec.
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
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
Somehow you'd think it would also benefit participants if it was also reliable and fulfilled end user's requirements. It is not theoretically impossible to have wireless headphones with low enough latency for gaming.
It's true that only paying companies (associate membership or higher) can participate in working groups and contribute to the specifications, but once a specifications has been adopted it becomes public.
All of the adopted core specifications, profile specifications, and errata documents are public: https://www.bluetooth.com/specifications/
All of the adopted core specifications, profile specifications, and errata documents are public: https://www.bluetooth.com/specifications/
You should try USB 3.2, which is 1500 or 3000 pages, The original Intel version of USB 1.0 was a nice comprehensible 150 pages.
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.
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.
Wireless has a lot of stuff going on.
Layer 1 off wireless is split in many different levels.
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.
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.
> Is there something about wireless in particular that lends itself to this proliferation of complexity?
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.
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.
Frequency hoping is neat but kind of insane.
I much prefer WiFi’s wideband spread spectrum and just letting the user pick a different carrier frequency if there’s too much interference.
I much prefer WiFi’s wideband spread spectrum and just letting the user pick a different carrier frequency if there’s too much interference.
what's your favorite standard that you've read?
[deleted]
> Become? Become?!
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/
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/
what’s is your point about it being a dollar per chip? that it’s implemented by super cheap labor or something?
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.
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.
True. The likes of broadcom are hugely sophisticated and really really understand the spec.
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.
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.
All Bluetooth chips come with SDKs and depending on your solution another API in the OS of your board. At that point clients don't need to know much about bt and from my experience don't care beyond "how do I make these bytes appear on the other side".
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.
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.
> Bluetooth chips come with SDKs and depending on your solution another API
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.
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.
I've gotten so tired of protocols and specifications that are overly complex or are poor fits for how they're used that I've started developing my own for the services I'm implementing [0].
Making protocols & specs no more complex or ambiguous than necessary is a hard requirement in this modern, security-conscious world.
[0] https://github.com/kstenerud/specifications
Making protocols & specs no more complex or ambiguous than necessary is a hard requirement in this modern, security-conscious world.
[0] https://github.com/kstenerud/specifications
Who else is using your specs?
I couldn't say; Github doesn't report to me who is including my code or implementing my specs.
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.
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.
Neat, but I strongly recommend a "related" section in your list of pointers. One of the best ways to communicate what you've made is to relate it to things people already know. E.g. is this thing like Protobuffs or like Markdown? Is it like a Merkle Tree or like Moment? Another valuable thing this does is give people looking for an alternative technology a way to find your thing.
That's a great idea! Thanks!
Reminds me of this XKCD https://xkcd.com/927/
If it does, then you've misunderstood what it means.
It's about "god" standards, designed to encompass all other standards, a theme common in the 90s.
It's about "god" standards, designed to encompass all other standards, a theme common in the 90s.
I'd argue that it can apply to any situation where someone is unhappy with the current set of solutions, decided to create a better one for people to use, but simply ends up adding another one to the pile and increasing the convolution.
I hate bluetooth. I hate pairing viscerally.
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.
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.
Complaining about 3000 pages of spec, in comparison to WiFi, is a bit apples-to-oranges. A lot of Bluetooth is not just the binary protocol. There is a huge surface area of what basically amounts to RPC protocols for different, standardized device interfaces. Bluetooth is a wonder for having things like heart rate monitors, pointing devices, and audio interfaces specified in a single, standardized way. You can generally count on a BT device from literally thousands of vendors to behave in the same way in literally thousands of different client devices.
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.
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.
It'd be nice if we at least got the easy connectivity promised and just had to work out a few security kinks.
https://xkcd.com/2055/
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.
https://xkcd.com/2055/
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.
My favorite part is when headphones connect to the laptop in my backpack that’s closed and the laptop I’m currently using. They play music successfully but volume is set to 0 because I guess macOS does that in sleep mode.
So I have to open up the sleeping laptop just to disconnect bluetooth
So I have to open up the sleeping laptop just to disconnect bluetooth
I bought a Bluetooth speaker and only Apple devices can use it smoothly, my Android 8/9 phone remembers its paired speaker but can't connect it unless I unpair them, press speaker's pair button, pair my phone again every single times. I plan to buy a DAC that support Spotify connect.
Lately Bluetooth connectivity with Apple devices has been great for me. AirPods just work and everything is pretty snappy and stable.
Yet there is still quite a lot of friction.
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.
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.
When I connect my AirPods to my 2015 MBP they don't properly connect unless I open and hover over the speaker icon in the system bar. There's also an issue if I start connection with only the left bud, probably the right bud is the main one?
> There's also an issue if I start connection with only the left bud, probably the right bud is the main one?
I think they are symmetrical. You can use both separately, without the other.
I think they are symmetrical. You can use both separately, without the other.
My mouse (Logitech MX Master) supports Bluetooth. It also supports Logitech' s "Unifying Receiver" and has a button to switch between three different Logitech receivers. I think everyone can guess correctly which of these options just works and always does what you want it to.
To clarify if it's not clear - the button switches between three different receivers, Bluetooth or Logitech unifying receivers. Currently I have 2 BT profiles, and 1 Logitech. The mouse works flawlessly
If it's not obvious, the USB receiver works flawlessly. I occasionally have trouble with Bluetooth not connecting (or randomly disconnecting) with the same mouse, but it mostly works okay.
A clean slate that repeats all the same mistakes in 10 years, but at least we will have a $clean_slate+1 and really get it right this time.
I've gotten bluetooth to work a handful of times. I've not been able to repeat that feat enough times to figure out why it works when it works and doesn't work when it doesn't, so I just throw my hands up and stick to aux and USB wired connections.
How come we can't solve lag?
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.
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.
It seems like something endemic to the protocol. Logitech's recent wireless mice/keyboards have skipped bluetooth altogether - they determined the lag was simply too large for high performance gaming: https://www.reddit.com/r/MouseReview/comments/99qq4a/about_t...
I have a Logitech G603 mouse that supports both, and there is no noticeable lag when using the proprietary dongle. I'm still glad BT is supported as a fallback, but the lag is undeniable.
It seems the AirPods do this. It will delay the video so that it’s in sync. It might already be in the protocol.
I know that VLC on Android needs the audio sync delay to be set manually, and VLC is usually great about implementing features when possible so I assumed it wasn't part of the protocol.
The problem with BT is not unique to BT. Any protocol at the time when it's used by app developers is not understood and misused. Most products in the wild just use the example code provided in the sdks provided. You can make a whole product this way. Especially simple stuff like bt speakers.
You know what doesn't cause increased attack surface for your devices, doesn't have pairing issues, never cuts out audio randomly, works immediately upon connection, is low power, and doesn't introduce additional RFI into your living space? A headphone jack.
Just saying.
Just saying.
But I must have a 1mm thinner phone!
Expensive timebombed unrepairable accessories is a small price to pay in order to have a 1mm thinner expensive timebombed unrepairable phone!
Expensive timebombed unrepairable accessories is a small price to pay in order to have a 1mm thinner expensive timebombed unrepairable phone!
It has always been the case. Attending IDC in 1999 before a single device had been certified and the hardware standards and certification docs were already 3500 pages. You can only imagine how this has grown in 20 years.
Bluetooth is a "giraffe" technology. It evolved in to the current form through happenstance. Nothing about it is simple or normal, instead randomly weird and inconsistent. And nobody is surprised that after 20 years everyone rightfully assumes that it barely works and is full of holes. However, since the standards are controlled by the people who build the hardware it is not been possible for a functional, non-insane alternative to appear.
IIRC OpenBSD dropped bluetooth for this very reason.
I am using thread which is a lot more sensible https://openthread.io/
The funny thing is that the protocol is meant to be run by tiny devices. So of course one would thing they would have attempted to make it simple.
If you want simple you can build your own on top of 15.4. This way your device will work but only with your other device.
The big thing about BT is that it's everywhere.
The big thing about BT is that it's everywhere.
The top players (apple/samsung) have switched to proprietary stacks on top of bluetooth to get the "magic" pairing experience. Google is following suite soon. On non "magic" pairing devices, bt is still a pain in the ass to get to work comparatively.
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).
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).
My main gripe with BT is the inpossibility to limit even which profiles[0] are active. For example: I do not mind allowing audio, but can not allow any form of networking.
0: https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
0: https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
I've not looked at recent specs but Bluetooth security has always been a bit of a misnomer. It's roots are in FTP etc and older protocols not really designed for security in mind, never was. So to say it's become a security risk, when it already was, may be missing the point.
I've been looking for a way to stop bluetooth from pairing with the Macbook asleep, this looks promising to switch it off when the lid is shut at least:
https://apple.stackexchange.com/a/272244
https://apple.stackexchange.com/a/272244
You wonder why OpenBSD removed it ?
it is complex which is usually an issue with security, but the article title makes it sound like maybe security wouldn't be that bad if it weren't for complexity. Bluetooth was broken long before it became complex. A protocol that allows you to negotiate a key size of maximum 1 byte is just plain dumb[1].
[1] https://twitter.com/matthew_d_green/status/11287020035243745...
[1] https://twitter.com/matthew_d_green/status/11287020035243745...
Become??? BT complexity and security were a joke ever since ver 1.1.
What happened to UWB as an alternative for Wireless PAN?
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?
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?
I totally agree. Drivers should be easy to write, spec should be slim and modular. It does not stick with the idea of lightweight communication stack.
I have to assume the reason that Bluetooth is still annoying 10 years later is the lack of synchronicity between OS vendors and hardware vendors.
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.
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.
"3,000 pages long" and yet it's still a pain in the ass to use a Bluetooth peripheral with more than one device.
Also seen this weekend: x86 security issues, presumably also stemming from its complexity.
Dijkstra must be rolling in his grave.
Dijkstra must be rolling in his grave.
ohyouHchrist(1)
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.