An engineer got curious about how his iLife A11 smart vacuum worked and monitored the network traffic coming from the device. That’s when he noticed it was constantly sending logs and telemetry data to the manufacturer — something he hadn’t consented to. The user, Harishankar, decided to block the telemetry servers’ IP addresses on his network, while keeping the firmware and OTA servers open. While his smart gadget worked for a while, it just refused to turn on soon after. After a lengthy investigation, he discovered that a remote kill command had been issued to his device.

  • sem@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    2
    ·
    8 hours ago

    Not to fear! Here is the relevant part so the next person coming by doesn’t have to read the article:

    deep in the logs of his non-functioning smart vacuum, he found a command with a timestamp that matched exactly the time the gadget stopped working. This was clearly a kill command, and after he reversed it and rebooted the appliance, it roared back to life.

    a smart vacuum#039;s components and sensors

    (Image credit: Harishankar)

    So, why did the A11 work at the service center but refuse to run in his home? The technicians would reset the firmware on the smart vacuum, thus removing the kill code, and then connect it to an open network, making it run normally. But once it connected again to the network that had its telemetry servers blocked, it was bricked remotely because it couldn’t communicate with the manufacturer’s servers. Since he blocked the appliance’s data collection capabilities, its maker decided to just kill it altogether. "Someone—or something—had remotely issued a kill command,” says Harishankar. “Whether it was intentional punishment or automated enforcement of ‘compliance,’ the result was the same: a consumer device had turned on its owner.”

    • 0x0@lemmy.zip
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 hours ago

      it was bricked remotely because it couldn’t communicate with the manufacturer’s servers.

      That bit seems inaccurate… if it couldn’t communicate it wasn’t bricked remotely… it was more like digital seppuku.

      • sem@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        1
        ·
        6 hours ago

        Earlier in the article he says that he only disabled some of the network connections but he left open the ones for firmware updates and stuff so to me it’s not impossible that it was able to receive remote commands although I would certainly want to see more technical details to satisfy my curiosity.

        The article says in words that it was a remote command. But again, we don’t have any details supporting that description. So maybe the journalist got it wrong.