一位工程师对他的iLife A11智能扫地机器人工作原理产生好奇，于是开始监控设备发出的网络流量。这时他发现，设备在未经他同意的情况下，正持续向制造商发送日志和遥测数据。用户哈里尚卡（Harishankar）决定在网络层面屏蔽遥测服务器的IP地址，同时保持固件和OTA服务器畅通。虽然他的智能设备暂时维持了运转，但不久后便彻底无法启动。
经过深入调查，他发现自己设备收到了远程清除指令。他多次将设备送修服务中心，技术人员每次都能正常启动且未发现任何故障。但设备归还后仅能正常工作数日，便会再次无法启动。经历多次拉锯战后，服务中心可能已不胜其烦，最终以过保为由拒绝接收。
为此他决定拆解设备查明故障原因，并尝试自行修复。由于A11是智能设备，采用搭载TinaLinux操作系统的全志A33片上系统，并配备GD32F103微控制器来管理包括激光雷达、陀螺仪和编码器在内的众多传感器。他自制PCB连接器并编写Python脚本通过电脑进行控制，试图逐项检测组件以定位故障。随后他构建了树莓派操纵杆手动驱动扫地机器人，证实硬件本身并无缺陷。
在转向软件和操作系统分析后，他发现了令人震惊的真相：这台智能扫地机器人不仅是安全隐患，更已成为个人数据的无底洞。首先，提供设备完全root权限的Android调试桥竟未设置任何密码或加密保护。制造商通过删除关键文件实施了临时安全协议，导致设备启动后立即断开连接，但被哈里尚卡轻松绕过。他继而发现设备使用Google Cartographer实时构建住宅的3D地图。
这种做法本身并不罕见——智能扫地机器人确实需要这些数据实现导航功能。但令人担忧的是，所有数据都被持续发送至制造商服务器。考虑到设备搭载的SoC处理能力有限，将数据传回制造商本无可厚非。然而iLife显然未就此与客户明确沟通。更令人不安的是，工程师在那台故障设备的日志深处，发现了一条时间戳与设备停止工作时刻完全吻合的指令。这显然是条清除指令，当他逆向执行该指令并重启设备后，机器立即恢复了正常运转。
为何A11在服务中心能正常运行，回到家中却拒绝工作？技术人员会重置智能扫地机器人的固件以清除清除代码，然后将其接入开放网络使其正常运转。但一旦设备重新连接至屏蔽了遥测服务器的网络，由于无法与制造商服务器通信，便会遭遇远程锁定。当他阻断了设备的数据收集功能后，制造商索性直接终止了设备运行。哈里尚卡表示：“某个主体——或某种机制——远程下达了清除指令。无论这是有意惩罚还是自动化合规执行，结果都一样：消费级设备背叛了它的主人。”
令人担忧的是，众多其他品牌的智能扫地机器人采用相同硬件架构，其运行机制很可能如出一辙。对于硬件性能有限、无法进行边缘计算的廉价设备而言，这种情况尤为普遍——它们必须将数据传送至远程服务器进行处理。一旦个人信息脱离用户可控设备，消费者对数据流向将完全失控，放任制造商随心所欲地使用这些数据。
最终，机主通过一系列技术改造实现了扫地机器人的完全本地化运行，摆脱了制造商控制。这使他重获数据自主权，让那台价值300美元遭软件锁定的智能设备得以按个人需求继续使用。对于缺乏专业技术知识与时长的普通用户，他建议“切勿将物联网设备接入主力WiFi网络”，并“将其视为家中陌生人”谨慎对待。
