Fun with Logitech MX900 Bluetooth receivers (2006)
nynaeve.net
nynaeve.net
Oh that brings memories.
Fun fact, Bluetooth is still shit in Windows 10. A ham friend bought a TP-Link UB500 bluetooth stick to connect to some bluetooth-to-serial adapter for one of his radio... Windows recognized it, but refused to connect to the serial adapter. Only after installing dedicated drivers for the BT stick [1], it worked.
It's mind-boggling that Windows still doesn't ship with a fully functioning native Bluetooth stack. Everything Bluetooth should be standardized for decades now.
My favorite: if your program is listening for devices in the background, the windows Bluetooth pairing menu breaks. Specifically the devices you're listening for will never show up about 50% of the time. If they do, it's likely that pairing will fail with no indication or reason.
Additionally, windows 10 does not support simultaneous audio sink and source. You absolutely cannot ever have your phone stream audio to your computer and then the computer pipe it back out to your BT headphones. I'm not sure if windows actually supports audio sink at all apart from HFP (phone call audio). Windows 7 supported this. All linuxes also have had this for over a decade.
At work, Microsoft forcibly updated one of our testing machines to W11, and there was nothing at all I could do to make it see our BT device. They are completely bog standard SPP serial devices using BT classic/EDR. Both of which have been a standard part of the BT spec since before W10 was even considered.
Windows' Bluetooth stack is an atrocity and an embarrassment. It's outrageously broken and incomplete. It is hands down, no contest the single worst Bluetooth implementation of any OS since windows 7. When linux has better Bluetooth than you, you've really fucked up.
Intel has gone down the drain just as well, I used to recommend their wifi/bt chips a long time, but not any more.
If you wait until the OS is up, the device itself can offload a good amount of logic and processing to the device driver.
My bet would be that the main reason is that it's easier to find programmers who can write complex device drivers than it is to find ones who can write complex embedded firmware, and it's quicker/easier in general to write device drivers than firmware.
That and just 99% of people will never notice that it doesn't work outside of the OS, and of the rest, 99% will only be vaguely annoyed but not change brands over that.
To use a bluetooth keyboard from the stage of "Press F10 to Enter Setup" we need the firmware (whether BT host, mainboard, or something else) to have a full bluetooth stack, some way to manage pairing/unpairing devices, and a bunch of other stuff.
If we do this outside the BT host, we probably need changes to the operating systems at least to handle how we're going to hand-off the state of the bluetooth stack when the OS takes control. Unless we want to _separately_ manage pairing/unpairing in the firmware, we would probably want some way to expose that to the operating system to be able to push its paired devices down.
And then it's probably still not super useful unless we substantially lengthen the prompt time because the time for you to turn the keyboard on, coax it into connecting, and hit the button is gonna probably have the OS booted already.
If you want this today just don't use bluetooth. Get one of the devices that uses "2.4GHz" or uses "Bluetooth + 2.4GHz" and shove a dongle in there. The keyboard/mouse will appear as a normal USB-connected device and you can use them how you want.
During the CSR hid2hci era, the adapter would just remember the last N pairings, since a sufficiently smart adapter can technically just store the keys used by the host when it tries to pair, then "impersonate" the host during the HCI part.
You still need to check if your motherboard supports Bluetooth at boot but many do.
You need two things: 1) a processor which can present HID devices OR a Bluetooth adapter depending on the presence of 2) a driver which can inform the adapter when it should be in BT mode instead of the default HID and which can configure the firmware to auto-connect to which devices in HID mode.
The first is easy and effecively free. The USB stack is (usually) implemented in firmware which makes it trivial to present as different device classes.
My guess is the problem comes down to drivers. It is difficult and quite expensive to have a custom driver upstreamed to Windows Update. You can't do this without a custom driver or userland software. On the other hand, if you simply present as a generic BT adapter, windows has a generic driver that will (usually) always work and is always installed.
The benefit of this feature is miniscule and there probably is not enough demand to make it worthwhile for CSR to sell their soul to Microsoft to have their driver blessed.
In this day and age, almost nobody ships a custom driver for anything. You just use the generic drivers Windows already has for all standard device types.
While I was posting in that thread I also noticed there are a gazillion attempts in github to do something like this, so complicated it is not.
So the content is supposed to have an NBSP between the sentences, was encoded as UTF8, but declared as ISO-8859-1 or similar at some stage in its history. The page seems now to declare UTF8, so it's presumably had the wrong decoding reencoded as UTF8.
Unless you mean it degraded on the same device.
However, that has been discussed on many other topics that are directly to do with TLS/certificates etc. so I don't think it's worth bringing up (aimed at the OP) every time there's an HTTP linked.
Maybe rewritten it could be viewed as a warning for those who care instead of a criticism.
Whether or not that matters when viewing this particular site is up for debate
If that's a big threat vector, I feel like the much bigger risk would be visiting malicious sites, not a local or ISP located attacker injecting stuff into benevolent-but-HTTP-only ones.
Another trick that could easily be pulled by a malicious ISP/wifi provider is to insert a redirect into the HTTP page to go to an HTTPS site controlled by the attacker (presumably with some semi-related name so as to not seem suspicious to the user) and to then bypass non-HTTPS restrictions in the browser.
The author is likely not updating it anymore, so you are effectively complaining to a group of people here that can do absolutely nothing about it.