有天下午我在地铁站等车兜里揣着一块刚烧录好程序的 ESP32 开发板它通过串口往笔记本上刷屏MAC 地址、RSSI 信号强度、设备名称……屏幕上三十多行滚动记录几乎全是周围乘客的耳机、手环、手表和手机。那个瞬间我意识到一件事这些设备并不是被我偷看了而是它们一直在主动对所有人喊话谁在附近谁就能听见。蓝牙的隐形追踪说白了就是你的设备在不停地自我介绍。这篇文章聊的正是这件事BLE 广播的工作原理、真实世界里已经存在哪些利用手段、你自己复现一次追踪实验要花多少钱以及普通用户最后还能怎么保护自己。内容上我尽量兼顾两类读者一类是用蓝牙耳机、手环、键盘但担心隐私的普通用户另一类是跟我一样写嵌入式、搞蓝牙协议栈的开发者想搞清楚自己做的设备的暴露面到底在哪里。蓝牙技术本身不是今天才出现的新东西但大多数人对它的理解还停留在配对之后才能传数据——这个误解恰恰是隐私问题最深的根源。接下来我会从协议层开始一步一步拆开给大家看。1. 蓝牙广播其实是公开喊话协议机制从一开始就没打算保密1.1 BLE 广播三个信道面前人人平等先做一个类比。你把蓝牙理解成一座广场上的两种交流方式想让某个朋友过来你可以给他打私密电话这是连接Connection两个人之间建立一条专属链路你也可以站在广场中间用喇叭喊一嗓子我在哪里所有人只要竖起耳朵都能听见这是广播Advertising。很多隐私泄露发生在你扯着嗓子喊的这一步而不是私密电话那一步。低功耗蓝牙也就是 BLE在 2.4GHz 频段里一共划分了 40 个物理信道其中 37、38、39 这三个信道被专门留作广播信道。任何设备只要处于广播状态就会周期性地往这三个信道上发射数据包。关键是接收这些广播包不需要配对、不需要连接、不需要任何形式的安全认证甚至连打招呼都不用。监听者可以坐在 100 米开外拿一块几十块钱的开发板静悄悄地接收附近所有广播。做过协议栈开发的读者应该清楚BLE 从 Core Specification 4.0 开始就设计了这套发现-连接-绑定的三段式流程。发现阶段默认是公开的设计它的目的是让设备能被快速找到。但成也发现败也发现——正是这个必须开放的机制让扫描者和被扫描者之间完全不对等被扫描的普通用户没有任何方式知道谁在听也没有任何系统日志会记录自己被扫描了多少次。1.2 广播包里有哪些自报家门的信息我经常在项目里解析广播包这里从抓包的角度告诉大家一个典型的 BLE 广播包里到底有什么。一个广播帧除去固定的头部字段真正核心的部分是 AdvA广播者地址和一组 AD StructureAdvertising Data 结构体。AdvA 是 48 位的蓝牙设备地址可能是公开地址也可能是随机地址。公开地址的前 24 位叫 OUI由 IEEE 分配给各厂商也就是说光看地址前 6 个十六进制字符就能大概率判断出设备品牌。随机地址又分静态随机、可解析随机、不可解析随机三种后面我会单独讲随机化的局限。AD Structure 则是一连串类型-长度-值的小块常见的有这几类字段含义隐私风险Local Name设备本地名称比如AirPods Pro、Mi Band 7直接暴露品牌、型号、甚至主人起的个性化名称Service UUID设备支持的蓝牙服务列表服务集合就是很强的指纹手环用 0xFEE7、心率计用 0x180D一看便知Manufacturer Specific Data厂商自定义数据厂商靠它识别自己设备观察者也能靠它做统计和追踪TX Power Level发射功率等级配合 RSSI 可用于测距运算Appearance设备外观分类告诉监听者这是耳机、手表还是键盘传统 BLE 广播包只有 31 字节的空间扩展广播Extended Advertising最多能到 255 字节。31 字节听起来不多但放一个设备名、几个服务 UUID 绰绰有余。实际抓包中很多产品还非常老实名称字段填得清清楚楚厂商数据也在里面等于往广场上立了一块写着我是谁的牌子。经典蓝牙 BR/EDR 的情况类似它通过 Inquiry查询过程扫描附近设备返回的信息里包含 BD_ADDR 和 Class of DeviceCoD。CoD 是服务类和设备类型的编码同样能精确到这附近有一台手机、一个扬声器或一辆车载系统。经典蓝牙的地址是出厂烧录的通常不会变这比 BLE 的随机地址更稳定追踪起来反而更省事。1.3 经典蓝牙和低功耗蓝牙追踪风险不在功耗而在可发现做嵌入式的人常被问经典蓝牙和低功耗蓝牙有什么区别最常见的回答是低功耗蓝牙省电、传输速率低。但从隐私角度看真正的区别其实在于它们的可见方式。维度经典蓝牙 BR/EDR低功耗蓝牙 BLE发现方式Inquiry/Page设备需进入可发现模式周期广播无需进入任何模式典型用途音频通话、键鼠、车载免提传感器、手环、信标、防丢器功耗较高配对建立慢极低广播成本极低设备地址BD_ADDR 基本固定不变可能是公开地址或随机地址追踪便利度地址稳定容易长期关联广播频繁几乎实时暴露位置看懂这张表就明白了攻击者想要的不是高功耗的稳定连接而是低成本、持续可见的信号源。BLE 恰好完美满足这个需求——它本来就是为传感器手环每隔几百毫秒上报一次数据这种场景设计的。产品经理要的是用户靠近时快速被发现、快速连接、少耗电安全人员看到的是几十台设备以极高频率在公共信道上自报家门。所以我在项目评审时经常跟硬件同事强调一句话蓝牙省下的每一毫安时电都是拿暴露时长换来的。功耗越低广播越频繁设备被外界看到的时间就越长。2. 那些已经被验证的真实追踪案例商场、网络和防丢标签2.1 Beacon 与客流统计你路过商场时广播包已经替你签到前面说的还只是理论现实中的应用早就不新鲜了。你在商场、机场、体育馆里经常见到的蓝牙信标Beacon本质就是一个只做广播、不建连接的 BLE 小盒子。它以固定功率、固定频率往外广播一串 UUID 和大小数据正常用途是向手机 App 推送导购信息、签到打卡但它的另一面就是客流统计。原理非常简单商场在店里安装若干个 Beacon顾客手机里如果装了这家商场的 App并且授予了蓝牙权限App 就会在后台持续扫描广播数据。扫描到某个 Beacon 的 UUID 时App 连同时间戳一起上传到服务端。后端拿到这些数据就能算出这个手机背后这个人几点进店、在哪个柜组逗留了多久、一周来几次。这种方案在 iOS 和 Android 上都跑得通唯一的限制是 MAC 随机化让纯探针方案不依赖 App直接扫描所有蓝牙地址识别用户的准确性下降了。所以现在很多商家转而用Beacon App 上报模式一边拿导航导购当卖点一边把客流数据沉淀下来。整个过程里用户只是点过几次允许后续的长期追踪是默认发生的。2.2 匿名 ID 的旋转接触追踪系统如何用隐私换防疫并留下争议蓝牙追踪并不只有恶意的一面也有一个非常典型的正向案例那就是 2020 年 Apple 和 Google 联合推出的接触追踪通知Exposure Notification方案。思路大概是这样的每台手机周期性生成并广播一个随机旋转的匿名标识符同时也会持续监听周围设备广播的标识符并记录下来如果一个人被确诊系统会把他过去一段时间的密钥上传其他手机在本地匹配自己记录过的匿名标识符算出来有没有发生密切接触。这个方案刻意规避了 GPS 定位设计上不采集位置信息标识符不断轮换初衷是要防疫效果也要隐私保护。它确实贡献了一个重要结论蓝牙广播的分布式追踪能力是非常强的而且可以在一定程度上做到匿名。但它也留下了争议——匿名 ID 的旋转并不是万能的通过连续观察广播时间、信号强度、设备指纹依然可以在局部范围内重建人的移动轨迹。事实上这项技术恰好证明了只要广播存在追踪在技术上就是可行的剩下的问题只是谁来做、怎么做、做到什么程度。2.3 AirTag 与 Find My 网络一颗标签如何让成千上万陌生手机为你定位如果你的认知还停留在蓝牙只能做近距离通信那 AirTag 会刷新你的理解。AirTag 本身是一个 BLE 广播设备它不停地广播一个加密的滚动密钥。关键在后面任何一台开机的 iPhone 路过得够近都会把这个密钥连同自己的定位信息通过 Find My 网络上报给云端。失主再通过自己的 Apple 设备解密就能在地图上看到 AirTag 的当前位置。换句话说AirTag 的主人并没有为它装任何 SIM 卡也不需要自己的手机一直待在旁边它借助全球数以亿计的陌生 Apple 设备完成了远程定位。这套机制反过来也说明你的 iPhone 在不知情的情况下一直在为别人的防丢标签搬运位置信息。你的手机硬件、蓝牙天线、网络连接都成了别人定位服务的基础设施。这也是为什么 Apple 和 Google 后来陆续加入了未知追踪器检测当系统通过蓝牙扫描发现一个不属于你的追踪器在持续随行就会向你推送警告。这个防御机制同样靠的还是蓝牙扫描。技术在造出问题的同时也在努力补上安全网。2.4 为什么匿名在蓝牙面前常常失效MAC 随机化的局限你可能以为MAC 随机化能解决一切问题很多系统也确实默认开了随机地址但实际效果远没有宣传的那么理想。我在安全研究里常用的一个词叫关联攻击单个字段可以被换掉但多个特征组合起来就很难完全漂白。具体来说观察者通常会做这样的事记录广播包里除了地址之外的其他所有字段比如设备名、服务 UUID 列表、厂商数据、广播间隔把同一物理设备定义为这些字段的组合 同一时间同一地点 信号强度曲线连续变化即使 MAC 地址周期性更换只要上面那些特征没变就能把新旧地址关联到同一个真实设备上。Adobe 做过 Wi-Fi MAC 随机化失效分析蓝牙圈也有类似研究。另外经典蓝牙的 BD_ADDR 很多场景下根本不随机你的老款耳机、汽车蓝牙、固定外设一旦暴露过地址就相当于泄露了长期身份。还有一个容易被忽略的细节BLE 的可解析随机地址是允许已配对设备解析出真实身份的也就是说一旦你和某个设备配过对、它的公钥长期存在你手机里第三方如果拿到了配对关系仍然可以还原设备身份。随机化的真实作用是提高了追踪成本而不是消灭追踪。这个结论请大家先记住后面讲防护时还要用到。3. 花几十块钱复现隐形追踪实验ESP32 当 BLE 扫描器3.1 为什么选 ESP32 而不是手机 App写这一章前我斟酌了一下要不要放代码后来还是决定放。因为纸上谈兵很难让人真正紧张起来只有自己跑一次扫描看到自家耳机、手环的广播数据出现在屏幕上那种我一直在被人知道的体感才是最真实的。为什么不推荐直接用手机 App一个是平台权限限制iOS 上第三方 App 根本无法像系统那样做长期后台扫描Android 上很多扫描器 App 也需要一堆授权另一个原因是你的手机本身就是个移动基站拿它做实验容易混入它自己发出的广播数据不干净。更重要的是ESP32 开发板只要二三十块钱板载双模蓝牙既能扫 BLE也能玩经典蓝牙 Inquiry串口输出可以直接接电脑记录数据是安全研究者入门监听设备的标准选择。我手头常备的开发板就是 ESP32-S3 和 ESP32-DevKitC前者跑协议栈更稳后者便宜、资料多。如果你只是复现实验随便哪个型号的 ESP32 都行。顺带回应一下热搜里那个问题ESP32 蓝牙是 Class 2 吗——没错ESP32 的 BLE 发射功率默认在 0dBm 上下属于 Class 2 范围典型的有效半径十米级。但这个十米级已经很够用了广播功率再往上调暴露半径也跟着涨。3.2 搭建扫描器的完整步骤与代码需要准备的东西非常少一块 ESP32 开发板约 20 到 50 元一根 Micro USB 或 Type-C 数据线电脑上装好 Arduino IDE并在开发板管理器里安装 esp32 开发包。Arduino 的 ESP32 核心包里自带 BLE 库不需要额外安装依赖。把下面代码烧录进去打开 115200 波特率的串口监视器就能看到附近设备在喊话。#include BLEDevice.h #include BLEScan.h #include BLEAdvertisedDevice.h class ScanCallback : public BLEAdvertisedDeviceCallbacks { void onResult(BLEAdvertisedDevice advertisedDevice) override { Serial.printf(MAC: %s | RSSI: %d dBm | Name: %s\n, advertisedDevice.getAddress().toString().c_str(), advertisedDevice.getRSSI(), advertisedDevice.getName().c_str()); } }; void setup() { Serial.begin(115200); BLEDevice::init(); BLEScan* pScan BLEDevice::getScan(); pScan-setAdvertisedDeviceCallbacks(new ScanCallback()); pScan-setActiveScan(true); pScan-setInterval(100); pScan-setWindow(99); } void loop() { BLEScan* pScan BLEDevice::getScan(); pScan-start(5, false); delay(3000); }这段代码做四件事setActiveScan(true)开启主动扫描。处于主动扫描时扫描器会向广播者发送 SCAN_REQ 请求广播者收到后返回一个额外的扫描响应包大部分设备的 Local Name 就是在这个响应里传出来的。所以这点很值得注意你以为设备没广播名字其实只是懒你主动一问它就说了。setInterval(100)和setWindow(99)把扫描参数拉满100 是扫描间隔单位 0.625ms99 是监听窗口意思就是几乎全时段都在听广播信道。start(5, false)表示连续扫描 5 秒后停止false 代表不要求结果同步。onResult回调里把地址、信号强度、设备名直接输出到串口。真正跑起来你会发现5 秒一次扫描每次能扫到十几到几十台设备。BLE 广播间隔常见范围是 100ms 到 1s你的扫描窗口足够覆盖绝大部分设备的广播节奏。3.3 实测结果解读设备名、MAC 与 RSSI 背后藏着的秘密这是我在办公区跑了一次 5 分钟扫描后截出来的一段代表性结果字段做了关键部分脱敏序号MAC 前缀来源设备名RSSI推断1AppleAirPods Pro-55dBm就在周围可能戴在耳朵上或放桌上不到十米2Huawei / Honor手环型号-61dBm附近有人戴着手环3未知厂商随机地址为空但带 0xFEE7 服务-48dBm大概率是健身手环距离很近4Samsung某手机名称-78dBm楼层隔墙信号衰减后距离较远5固定地址无名称无服务为空-30dBm强信号无名设备可能是测试工装或某种传感器看完这组数据你大概能理解攻击者视角的乐趣和可怕哪怕不开 GPS光靠 RSSI 就能粗略判断设备在十几米内还是几十米外多个监听点同时收到同一设备的广播就能做 RSSI 三角定位这在楼宇内比 Wi-Fi 定位还方便设备名、服务 UUID、厂商数据组合起来可以直接判断这个人的装备体系——用什么品牌的耳机、什么手环、什么手机连带消费力画像都出来了如果某个固定地址的设备连续几天在同一时段出现在同一位置就可以相当有把握地说它的主人作息很有规律。整个过程不涉及破解、不涉及入侵、不需要任何密码。你只是站在路边听了一会儿而那些说话的设备完全不知情。3.4 这个实验说明了什么我必须说清楚做这个实验的目的不是教你伏击别人而是让你理解一个事实——蓝牙追踪的技术门槛低到几乎没有。一个初学者花几十块钱、一下午时间就能复现教科书级别的广播监听。这意味着恶意者不需要什么高深技能就可以批量收集附近设备的身份信息、品牌信息、位置信息。那为什么我们平时没感觉到被追踪因为攻击者监听但不打扰的时候被监听者没有任何体验上的变化。耳机照样连、手环照样记步、手机照样推送通知。风险是悄无声息的。如果你本身就是做嵌入式的这个实验还有一个额外收获你在设置自己产品的广播间隔、广播功率、广播内容时最好拿着这块 ESP32 站在产品旁边扫一扫看看它自报家门时报了什么。能少报一点就少报一点这个习惯真的能救很多人。4. 隐私泄露的重灾区不只在广播包系统权限、配对记录与音频链路4.1 App 拿蓝牙权限到底干了什么广播只是隐私泄露的一条腿另一条腿藏在系统和应用权限里。你打开手机的应用权限列表会看到某些 App 持有蓝牙或附近设备权限。如果你以为它们只是用蓝牙连个音箱那就太天真了。在 Android 12 之后蓝牙扫描相关权限被合并为附近设备NEARBY_DEVICES在 iOS 上App 需要在 Info.plist 里声明 NSBluetoothAlwaysUsageDescription也就是为什么需要蓝牙你授权后才允许扫描。持有蓝牙权限的 App 能在后台调用系统蓝牙扫描接口读取附近广播包里的 UUID、名称、RSSI然后把数据传回服务器。光有蓝牙权限还不够精确但如果 App 同时还拿到了定位权限那这两者一叠加一个相当清晰的人在哪、身边有什么设备、在移动还是在停留画像就出来了。所以我在日常使用里的习惯是一个 App 如果只做笔记、只做社交、只看视频完全没有理由拥有蓝牙权限。第一次弹窗就果断拒绝不影响 App 核心功能就说明它本来就是用蓝牙采数据的。另外 iOS 在设置-隐私与安全-蓝牙、Android 在设置-隐私-权限管理-附近设备里都能看到哪些应用持有该权限值得每隔一段时间清理一次。4.2 配对记录是比广播更持久的身份线索很多人不知道你手机里的已配对设备列表本身就是一份情报价值极高的数据库。因为一旦配对成功系统就会保存对方的蓝牙地址、服务信息、配对密钥有些设备还会被记住个性化名称。你删掉配对关系前这些数据都不会自动消失。一份两周前的配对记录能准确告诉攻击者你两周前用过一副什么耳机、连过一台什么车机、配过哪个心率带。更麻烦的是经典蓝牙的发现模式。老协议栈里设备处于可发现状态时第三方可以通过 LMP 层信息枚举设备能力和名称既不需要配对也不需要连接。现在手机和系统修复了很多但大量存量 IoT 设备、老款耳机、工装设备还停留在旧协议栈上它们是更容易被识别的钉子户。如果你问我怎么自查最简单的一条定期翻一遍蓝牙设备列表凡是你想不起在哪配对的、来路不明的设备直接忽略此设备。别犹豫不会影响你正常使用。4.3 蓝牙音频的链路切换A2DP 与 SCO以及断断续续背后的协议逻辑热搜里有个词很典型蓝牙 A2DP 切 SCO 模式。很多用户遇到的情况是耳机连着手机正听着歌突然声音断断续续甚至像电话音质然后过一会儿又好了。这其实是协议自动切换造成的不是玄学。A2DP 是高级音频分发协议负责高质量音频播放带宽占用大而打电话走的是 HFP免提协议底层对应 SCO/eSCO 链路带宽窄、延迟要求高。当手机来电话、发起语音通话、或者某些系统检测到麦克风被调用时耳机往往要从 A2DP 切到 SCO 链路于是音质下降、延迟出现甚至在某几毫秒的时间里表现为卡顿、断裂。如果你看到蓝牙连接电脑声音断断续续除了切换问题还要考虑 2.4GHz 频段的拥挤——蓝牙和 Wi-Fi、USB 3.0、微波炉全挤在同一段频谱里环境干扰一大蓝牙底层就会重传包表现出来就是声音一顿一顿。这段和隐私有什么关系两个层面。第一链路的频繁切换、异常重传会让设备在射频层面呈现出独特的呼吸节律这种节律跟设备型号、固件版本强相关观察者可以用来补充指纹信息第二也是更实际的一点——很多用户以为只要不连音频蓝牙就是静默的但通话切链路、麦克风被调用的过程往往不是用户主动触发的。App 一旦拿到了相关权限可以在系统层面唤起通话通道那时候你的耳机、音箱其实已经变成了一个房间里的耳朵。参与通话的设备是谁、通过什么链路保持连接这些状态在蓝牙协议里是可见的。当然这里并非说蓝牙音频天生不安全而是提醒大家注意高带宽音频链路和低带宽通话链路之间的切换很多时候不受用户控制它本身也是设备身份的一部分。4.4 廉价蓝牙键盘与配件输入内容明文传输的隐患还有一个非常实际、但被绝大多数人忽略的场景蓝牙键盘。办公室里常见的廉价蓝牙键盘尤其是那些几十块钱、固件很多年不更新的产品有两个硬伤。第一很多低成本外设只实现了蓝牙协议里较弱的 Legacy Pairing传统配对加密密钥协商过程没有开启 MITM 防护一些旧实现在加密上是可被攻破的。第二有些产品为了兼容性在配对绑定时用的是固定 PIN 码甚至部分固件不会真正启用加密链路。安全研究圈发布过好几次针对低成本蓝牙键鼠的按键注入、按键记录攻击演示利用的就是协议实现不完整、加密缺失等问题。这意味着什么你在公共场合用一把廉价蓝牙键盘输入密码监听者理论上可能捕获并还原你的按键内容。这不是电影情节是有真实漏洞库和公开演示的。选购蓝牙键盘尽量挑支持 Secure Connections、固件持续更新的品牌型号配对时如果系统提示输入 PIN 码实际是从头到尾没经过真实密钥协商的高危信号要格外警惕。5. 普通用户能做的自查与防护把被看见的选择权拿回来5.1 五分钟自查清单从系统设置开始前面讲了很多原理下面给一份可以直接照着做的自查清单整个过程五分钟就能完成打开手机蓝牙设置检查已配对设备列表把一切不认识、想不起来的设备全部删除在 iOS 的隐私与安全-蓝牙或者 Android 的隐私-附近设备里逐个审查持有蓝牙权限的 App非必要立即关闭检查系统设置里可被发现模式的开关尽量保持关闭手机一般只在蓝牙设置页停留时才允许被发现拿到这个原则就够了查看系统是否有未知跟踪器提醒功能遇到检测到未知的追踪器推送先别急着忽略仔细看看自己身上、包里、车里是不是多了什么不认识的小东西有条件的话打开硬件地址随机化或随机 MAC等类似选项不要为了连公共设备而长期关闭它。这套动作的成本几乎为零但能挡掉大量最粗放的追踪行为。很多隐私泄露不是被什么高端黑客盯上了而是你的设备一直开着广播、一直开着权限正好被某个自动收集数据的体系扫进了数据库。5.2 系统级 MAC 随机化与追踪器检测现代系统的防御武器现代手机系统在隐私上其实做了不少努力。iOS 和 Android 在系统级默认引入随机 MAC 后传统的固定地址探针追踪方案已经失效了大半这也是商场客流统计转向 App 合作模式的重要原因之一。MAC 随机化不是万能的但它是成本最低、收益最高的一道防线别主动关闭它。未知追踪器检测是第二道防线。iOS 和 Android 现在都能通过蓝牙扫描发现周围不属于你的追踪器判断它是否在持续随行。收到这类提醒正确的做法是停下来按提示查看追踪器的位置必要时用手机靠近它触发声音提示然后联系场所安保或按平台指引处理。这类功能依赖的就是我们前面说的蓝牙扫描能力——防守方和进攻方用的是同一套机制区别只在系统有没有帮你在后台看着。5.3 什么时候该彻底关闭蓝牙我知道有些读者看到这会问那我不用蓝牙的时候是不是应该彻底关掉我的回答是看场景但关掉确实是终极手段。睡觉、开会、远途出差、长时间不用无线耳机时直接下拉控制中心把蓝牙关了。这一步会断开所有蓝牙连接停止本机的大部分蓝牙广播。对于任何一个监听者来说一台蓝牙完全沉默的设备几乎等于不存在。代价也很小——下次要用的时候打开重新连接耳机也就一两秒的事。需要提醒的是控制中心的蓝牙开关和系统设置里的完全禁用并不完全等价。iOS 控制中心关闭蓝牙会断开已配设备但系统级设置里的蓝牙开关才是真正关闭蓝牙模块的入口Android 各版本行为也有差异。追求极致隐私的用户可以养成习惯到了固定场所比如家里直接在系统设置里关掉蓝牙模块这样最干净。5.4 给开发者的两句提醒如果你和我一样做蓝牙开发有几件事希望放在心里。第一产品默认配置别走最大暴露路线。很多开发板、模块的默认参数是广播间隔 20ms、发射功率最大、广播内容里塞满设备名和服务信息这在开发调试时很方便但上线后就是给用户埋雷。合理的设计应该是广播间隔适当拉长、广播内容尽量精简、静态标识匿名化能做成连接后才交换身份信息就不要在广播阶段暴露任何数据。参考一下 Core Specification 5.3 里关于隐私和扩展广播的建议很多细节值得读。第二权限采集要克制。如果你的 App 只是做蓝牙灯控、连一个音箱那就不需要在后台持续扫描所有广播包。只请求必要的连接权限扫描完马上停数据本地处理而不是上传。把能不采集就不采集、采了也别留当成默认原则比写十页隐私政策更有用。说回我自己。做蓝牙开发这几年最大的体会是蓝牙不是点对点的电话而是一个带永久麦克风的公共广场。你能听到别人别人也能听到你只是大多数时候我们都没注意听。我不建议大家因此恐慌到每晚关机、彻底抛弃无线设备——那等于把便利全扔掉也不是蓝牙设计的初衷。真正值得做的是搞清楚你的每台设备在什么时候、以什么频率、向谁广播了自己的存在。做完上面这套自查你大概率会发现原来静音状态下的耳机也会时不时喊一嗓子。然后你就可以决定让谁听不让谁听。这才是隐私控制该有的样子。