4 ms·

That's a fair argument, but it doesn't appear that that updates are high on sleep number's priority list: > The hub includes Python 2.7.18. While extremely old

That's a fair argument, but it doesn't appear that that updates are high on sleep number's priority list: > The hub includes Python 2.7.18. While extremely old (keep in mind the Hub appears to have been last updated in 2018) If we give them the benefit of the doubt, perhaps they intended to to keep it up to date but ultimately compaines need to either be transparent about their remote access and manage it responsibly, which includes keeping the system patched, or give up access

binwiederhier 2y ago
> Python 2.7.18 I am not defending them for not keeping their stuff up-to-date, but it is very common practice for embedded systems to be hopelessly outdated. I've done what OP describes with IPMI/BMC systems for $mainboardmanufacturer1 and $mainboardmanufacturer2 (both really big name brands), and their BMC systems were equally outdated. It was almost comical, but really sad at the same time. Moral of the story is to firewall things off really well, I suppose. At $oldjob, I designed an upgrade mechanism to do A/B image updates so things were always up to date, or at 2-3 weeks out of date. See [1]. For small embedded systems that do not have enough space/bandwidth, this may not be feasible though. [1] https://blog.heckel.io/2019/09/18/image-based-upgrades-upgrading-software-and-os-of-80k-servers-every-two-weeks/ https://blog.heckel.io/2019/09/18/image-based-upgrades-upgra...
- flaminHotSpeedo 2y ago
  I know I'm preaching to the choir, but I do prefer not having to treat my bed as a hostile device on my network
  - bitmasher9 2y ago
    Either treat your devices as potentially hostile or simply don’t connect your bed to a network.
  - hughesjj 2y ago
    I mean it's not like sleep number can tell when you're having sex or sleeping or anything.... Er, I mean okay, well at least they're budget friendly.... Well at least they don't have an ssh server constantly running in the background or something
  - nucleardog 2y ago
    Even if it didn’t have the intentional backdoor… you probably should be treating it as hostile anyway. Even where not intentionally hostile, not intentionally privacy invading, not trying to fetch updates so it can show you more ads, not… most of this stuff is so hopelessly out-of-date and full of security vulnerabilities it’s only not hostile out of luck. I don’t connect anything to WiFi unless absolutely necessary. And by that I don’t mean “the device demands it” (I just won’t buy the damn thing) but “it’s a core part of the functionality I’m asking of it”. I’ll prefer zwave/zigbee, Bluetooth, or something else wherever possible when communication is required. (If I were forced to use this bed and it had no manual controls I would definitely have used Bluetooth, avoiding this whole issue.) And even for the devices that do get a WiFi connection… they run entirely isolated, on a separate SSID and VLAN from my normal devices and traffic, and with a whitelist for what traffic is allowed. As far as I’m concerned the only difference between this bed and the other devices is that we know about the issues with this bed. We have no reason to believe that the other devices are any better, and in fact a pretty large body of evidence suggesting that they’re probably not.
    - fooqux 2y ago
      > And even for the devices that do get a WiFi connection… they run entirely isolated, on a separate SSID and VLAN from my normal devices and traffic, and with a whitelist for what traffic is allowed. This is what I do today, and honestly I'm about to give up. We lost. Trying to get stuff like airplay / DLNA to work via mDNS is already impossible across subnets, and telling family to switch networks if they want to control X with their phones is just a shit solution. I have to disable 90% of my vehicle's "infotainment" screen to not feel spied upon, and which breaks the app I can use for remote starts, etc. Maybe when the "Mega-Hack of 2025" happens and all IoT devices go nuclear something will change. But for now, if you buy a device it expects to be on one giant /24 and anything different creates problems. I'm starting to spend way more time than I want maintaining all the various pieces of networking glue that keeps my devices and home automation functioning. It's no longer fun, and I'm tired of fighting it. I still have an ancient sleep number bed, with no connectivity. It's leaking, and old enough to drink. I'd like to replace it, but still can't bring myself to do it because of articles like this. I've never felt more like Abe Simpson yelling at a cloud.
CJefferson 2y ago
While 2.7.18 hasn't been updated since 2018, it's also the last version of Python 2. I've got several programs stuck in 2.7.18, as they have sizable dependancies that never got updated to Python 3 -- unless I'm willing to rewrite several large Python packages, I'm stuck here forever. As long as the program isn't network connected, I don't see a problem with fixing a Python version, and set of packages, and leaving the software running forever.
- flaminHotSpeedo 2y ago
  Oh good catch, I thought python 2's depreciation was more recent, time flies I guess!

binwiederhier 2y ago

> Python 2.7.18 I am not defending them for not keeping their stuff up-to-date, but it is very common practice for embedded systems to be hopelessly outdated. I've done what OP describes with IPMI/BMC systems for $mainboardmanufacturer1 and $mainboardmanufacturer2 (both really big name brands), and their BMC systems were equally outdated. It was almost comical, but really sad at the same time. Moral of the story is to firewall things off really well, I suppose. At $oldjob, I designed an upgrade mechanism to do A/B image updates so things were always up to date, or at 2-3 weeks out of date. See [1]. For small embedded systems that do not have enough space/bandwidth, this may not be feasible though. [1] https://blog.heckel.io/2019/09/18/image-based-upgrades-upgrading-software-and-os-of-80k-servers-every-two-weeks/ https://blog.heckel.io/2019/09/18/image-based-upgrades-upgra...

flaminHotSpeedo 2y ago
I know I'm preaching to the choir, but I do prefer not having to treat my bed as a hostile device on my network
- bitmasher9 2y ago
  Either treat your devices as potentially hostile or simply don’t connect your bed to a network.
- hughesjj 2y ago
  I mean it's not like sleep number can tell when you're having sex or sleeping or anything.... Er, I mean okay, well at least they're budget friendly.... Well at least they don't have an ssh server constantly running in the background or something
- nucleardog 2y ago
  Even if it didn’t have the intentional backdoor… you probably should be treating it as hostile anyway. Even where not intentionally hostile, not intentionally privacy invading, not trying to fetch updates so it can show you more ads, not… most of this stuff is so hopelessly out-of-date and full of security vulnerabilities it’s only not hostile out of luck. I don’t connect anything to WiFi unless absolutely necessary. And by that I don’t mean “the device demands it” (I just won’t buy the damn thing) but “it’s a core part of the functionality I’m asking of it”. I’ll prefer zwave/zigbee, Bluetooth, or something else wherever possible when communication is required. (If I were forced to use this bed and it had no manual controls I would definitely have used Bluetooth, avoiding this whole issue.) And even for the devices that do get a WiFi connection… they run entirely isolated, on a separate SSID and VLAN from my normal devices and traffic, and with a whitelist for what traffic is allowed. As far as I’m concerned the only difference between this bed and the other devices is that we know about the issues with this bed. We have no reason to believe that the other devices are any better, and in fact a pretty large body of evidence suggesting that they’re probably not.
  - fooqux 2y ago
    > And even for the devices that do get a WiFi connection… they run entirely isolated, on a separate SSID and VLAN from my normal devices and traffic, and with a whitelist for what traffic is allowed. This is what I do today, and honestly I'm about to give up. We lost. Trying to get stuff like airplay / DLNA to work via mDNS is already impossible across subnets, and telling family to switch networks if they want to control X with their phones is just a shit solution. I have to disable 90% of my vehicle's "infotainment" screen to not feel spied upon, and which breaks the app I can use for remote starts, etc. Maybe when the "Mega-Hack of 2025" happens and all IoT devices go nuclear something will change. But for now, if you buy a device it expects to be on one giant /24 and anything different creates problems. I'm starting to spend way more time than I want maintaining all the various pieces of networking glue that keeps my devices and home automation functioning. It's no longer fun, and I'm tired of fighting it. I still have an ancient sleep number bed, with no connectivity. It's leaking, and old enough to drink. I'd like to replace it, but still can't bring myself to do it because of articles like this. I've never felt more like Abe Simpson yelling at a cloud.

CJefferson 2y ago

While 2.7.18 hasn't been updated since 2018, it's also the last version of Python 2. I've got several programs stuck in 2.7.18, as they have sizable dependancies that never got updated to Python 3 -- unless I'm willing to rewrite several large Python packages, I'm stuck here forever. As long as the program isn't network connected, I don't see a problem with fixing a Python version, and set of packages, and leaving the software running forever.

flaminHotSpeedo 2y ago
Oh good catch, I thought python 2's depreciation was more recent, time flies I guess!