13 ms·

> the wifi+bt chip has bluetooth hardware-disabled in solder Just... why??

• josephcsible 5y ago
  Attack surface reduction, maybe? Bluetooth vulnerabilities at really low levels in the stack aren't that uncommon. And if it's just disabled in solder and not on the silicon die, wouldn't it be practical to re-enable it by taking it apart if you really wanted?
  • cge 5y ago
    Attack surface reduction? On a device with unencrypted storage, the root password displayed in the about screens, no verified boot, no password by default (with password protection that amounts to a lock screen), and unprotected USB access to all user files by default? Where there are four exposed pins on the exterior that allow mounting of the root filesystem as USB mass storage regardless of password protection (https://github.com/ddvk/remarkable2-recovery https://github.com/ddvk/remarkable2-recovery), and the root password is stored in plain text?
    • josephcsible 5y ago
      Doesn't everything you listed require physical possession of the device to do anything with, whereas Bluetooth can be exploited just by walking near a malicious device?
      • tata71 5y ago
        RCEs in your kernel mean verified boot is a baseline desire.
• detaro 5y ago
  Potentially certification. Or it's just missing support components that would be needed for BT to work, but weren't put in because BT wasn't part of the design, and thus disabled since it wouldn't work either way.
• MartijnBraam 5y ago
  I guess they just didn't hook up the uart connection for the bluetooth side of wifi/bt chip since they were not using it?