Дослідження команди з Технологічного інституту Джорджії (Georgia Tech) виявило у Bluetooth‑трекерах Tile низку проблем приватності, що спрощують ідентифікацію пристроїв і відстеження маршрутів користувачів. Йдеться про статичні MAC‑адреси, повторне використання унікальних ідентифікаторів у BLE‑рекламних пакетах (advertisements) та передачу телеметрії на сервери без сквозного шифрування (E2EE). У сукупності це відкриває можливості для довгострокової кореляції пристрою з конкретною особою.
Що саме виявили: BLE‑ідентифікатори, статичні MAC і телеметрія без E2EE
Аналіз, що включав декомпіляцію Android‑додатка Tile і перегляд BLE‑трафіку між Tile Mate та смартфоном, показав: трекер постійно транслює відкриті advertising‑пакети з ідентифікаторами та постійним MAC‑адресом. Хоча частина ID псевдовипадково генерується, їх повторне використання з часом полегшує прив’язку сигналів до одного пристрою й будування історії переміщень.
На інфраструктурному рівні дослідники фіксують відправку до серверів локаційних даних, MAC‑адрес і унікальних ID без повноцінного E2EE. Важливо розрізняти шифрування каналу (TLS) і сквозне шифрування: перше захищає передачу від сторонніх, але сервер має доступ до вмісту; друге робить дані недоступними навіть для провайдера сервісу. За такої архітектури перехоплення BLE‑вещання або серверна кореляція можуть призвести до деанонімізації власника трекера.
Антисталкінг у Tile: обмеження підходу застосунку
Scan and Secure проти «захисту від крадіжок»
Функція Scan and Secure дає змогу користувачу шукати поруч несанкціоновані трекери, роблячи метки видимими під час сканування. Водночас опція «захист від крадіжок» приховує пристрій від такого виявлення, що створює конфлікт моделей загроз: інструмент для контрсталкінгу нейтралізується функцією, розробленою для непомітного відстеження майна. Дослідники зазначають, що при активному антивикраденні результати на сервері обмежуються, однак модифікований клієнт здатен зчитати приватні ідентифікатори, накопичені під час пошуку.
Чому критичний рівень ОС
Антисталкінг в екосистемах Apple і Google реалізований на рівні операційної системи: фонове BLE‑сканування і системні сповіщення про невідомі трекери працюють постійно. Tile як сторонній застосунок має обмежений доступ і залежить від ручних перевірок, що утворює «сліпі зони» виявлення. Архітектурно це поступається інтегрованим механізмам ОС, особливо коли користувач рідко запускає перевірку оточення.
Правовий і ринковий контекст: Amazon Sidewalk та репутаційні ризики
У 2023 році на материнську компанію Life360 подавали позови, в яких інтеграція з Amazon Sidewalk розглядається як фактор розширення зони виявлення і потенційних ризиків переслідування. Попри кроки Apple та Google щодо системних оповіщень, результати Georgia Tech вказують, що поточний протокол Tile все ще допускає необґрунтовану кореляцію ідентифікаторів і локаційних подій.
Позиція Life360 і запропоновані покращення
За словами дослідників, повідомлення про знахідки було надіслано Life360 у листопаді 2024 року. Компанія у коментарі для The Register підтвердила отримання попереджень і заявила про впровадження покращень, зокрема шифрування даних під час передачі та перехід на ротовані (rotating) MAC‑адреси. Технічні деталі не розкриті, тож зовнішня верифікація ефективності наразі обмежена.
Рекомендації від команди дослідження узгоджуються з найкращими практиками індустрії: BLE Privacy (RPA) для рандомізації MAC, криптографічно пов’язані ефемерні ідентифікатори з регулярною ротацією, E2EE для телеметрії та мінімізація серверної кореляції і строків зберігання геоданих.
Практичні поради користувачам і організаціям
Користувачам: регулярно оновлюйте застосунок Tile і ОС; реагуйте на системні попередження про «невідомі трекери»; періодично запускайте сканування оточення; за підвищених вимог до приватності обмежте участь у сторонніх мережах локалізації (зокрема Sidewalk); віддавайте перевагу трекерам із регулярною ротацією MAC та ідентифікаторів і прозорою політикою зберігання даних.
Організаціям: включіть трекери до реєстру ІТ‑активів і моделей загроз; перевірте угоди постачальників щодо локаційних даних; вимагайте політик відповідального розкриття вразливостей, дорожньої карти впровадження E2EE і повної рандомізації ідентифікаторів; періодично виконуйте BLE‑аудит у зонах з підвищеними вимогами до приватності (офіси, критична інфраструктура).
BLE‑трекери корисні, але їхня безпека визначається деталями протоколу. Якщо постачальник покладається на статичні ідентифікатори і «шифрування каналу» без E2EE, зростають ризики деанонімізації та спостереження. Оцінюйте архітектуру сервісу, вмикайте антисталкінг‑інструменти ОС, оновлюйте ПЗ і вимагайте від виробників прозорості, незалежних аудитів та технічних контролів рівня BLE Privacy і сквозного шифрування.
