Датчики движения выдают стабильный фингерпринт устройства через калибровочный шум. iOS закрыл это запросом разрешения, а Chrome на Android — до сих пор нет.
Фингерпринтинг через canvas и WebGL считывает то, как устройство рендерит. Фингерпринтинг сенсоров считывает нечто иное: как физическое оборудование устройства двигается — точнее, как оно сообщает о движении, которого на самом деле никогда не было. Каждый акселерометр, гироскоп и магнетометр сходит с конвейера с крошечными, постоянными производственными погрешностями, и сырые данные, которые эти чипы отдают веб-странице, несут эту погрешность как своего рода подпись. В этой статье разберём, как её раскрывают API DeviceMotion, DeviceOrientation и Generic Sensor, почему это в основном явление телефонов и планшетов, и почему запрос разрешения, закрывший эту технику на iOS, так и не появился на Android.
Ключевые выводы
- API
DeviceMotionEventиDeviceOrientationEventраскрывают показания датчиков движения устройства в реальном времени. Более новые классы Generic Sensor API (Accelerometer,Gyroscope) читают то же самое оборудование, но работают только в Chromium — ни Safari, ни Firefox их не реализуют. - Производственные допуски оставляют на каждом чипе акселерометра и гироскопа слабое, но устойчивое смещение и характерный шум — калибровочный фингерпринт, который остаётся стабильным между сессиями, браузерами и даже после сброса до заводских настроек, потому что он «зашит» в физический кремний, а не в какое-либо состояние ПО.
- Это в первую очередь мобильный вектор: у ноутбуков и настольных компьютеров обычно вообще нет акселерометра или гироскопа, поэтому сигнал почти не встречается за пределами телефонов и планшетов.
- Ограничение доступа неоднородно. Начиная с iOS 13 Apple требует явного запроса разрешения — и там это действительно закрыло бесшумную версию техники. Chromium же не спрашивает вообще: его собственная проектная документация описывает акселерометр и гироскоп как выдаваемые автоматически. На Android страница верхнего уровня по HTTPS до сих пор может читать калибровочный шум без единого запроса.
- Проверка отпечатка BrowserInsight показывает сигналы, раскрываемые вашим устройством, а руководство по мобильному фингерпринтингу описывает, как этот сигнал вписывается в более широкую картину мобильного трекинга.
API DeviceMotion, DeviceOrientation и Generic Sensor
Данные о движении веб-странице раскрывают два пересекающихся поколения API. Более старая пара — DeviceMotionEvent и DeviceOrientationEvent — срабатывает непрерывно после подключения слушателя, отдавая ускорение, скорость вращения и углы ориентации как обычные свойства события:
window.addEventListener('devicemotion', (event) => {
const { x, y, z } = event.accelerationIncludingGravity;
// x, y, z слегка «плавают» даже когда устройство неподвижно лежит на столе
});
Более новое семейство Generic Sensor API — Accelerometer, Gyroscope и Magnetometer — заменяет модель на основе событий выделенными объектами-сенсорами, которые скрипт может напрямую создавать, настраивать и опрашивать. (Пояснение W3C по сенсорам движения — ненормативная записка рабочей группы, полезная для понимания их взаимосвязи; сами интерфейсы определены в отдельных спецификациях для каждого сенсора.)
const sensor = new Accelerometer({ frequency: 60 });
sensor.addEventListener('reading', () => {
console.log(sensor.x, sensor.y, sensor.z);
});
sensor.start();
Две оговорки о доступности. Классы Generic Sensor — это функция Chromium: их реализуют Chrome, Edge и Opera, тогда как Safari и Firefox не реализуют ни Accelerometer, ни Gyroscope, поэтому старая пара событий остаётся единственным путём, работающим во всех движках. А внутри самого Chromium Magnetometer спрятан за флагом #enable-generic-sensor-extra-classes и не включён по умолчанию — обычной странице показания магнетометра недоступны так, как доступны показания акселерометра и гироскопа.
Оба подхода в итоге считывают одно и то же оборудование. Для фингерпринтинга важно не то, какой именно API отдал числа, а то, что содержится в этих числах, даже когда ничто не движется.
Калибровочный шум как устойчивый ID устройства
Положите телефон плашмя на стол и запросите его акселерометр. По идее он должен сообщить (0, 0, 9.8) — только гравитацию и ничего больше. На практике он сообщит что-то вроде (0.013, -0.007, 9.79): небольшие ненулевые показания по всем осям. Это отклонение — не погрешность измерения в обычном смысле, а заводская калибровка акселерометра, причём удивительно стабильная. MEMS-акселерометры и гироскопы производятся массово, и каждый отдельный чип несёт немного отличающееся смещение и погрешность масштабного коэффициента из-за особенностей производства. Академические исследования фингерпринтинга на основе сенсоров неоднократно показывали, что этот вектор смещения несёт реальную энтропию — достаточную, чтобы помочь различить отдельные экземпляры одной и той же модели, особенно если объединить показания нескольких осей и нескольких датчиков.
Именно это делает калибровочный шум принципиально другой категорией сигнала по сравнению с выводом canvas или WebGL. Хеш canvas меняется при смене браузера или при изменении растеризации драйвером GPU; список шрифтов меняется при установке нового шрифта. Калибровочный шум не меняется ни от чего из этого — он переживает обновление браузера, сброс до заводских настроек и даже переустановку ОС, переживает переход с Chrome на Firefox на одном и том же телефоне, потому что это свойство физического кристалла сенсора, а не какого-либо состояния ПО, которое скрипт мог бы очистить. Скрипту достаточно захватить несколько секунд показаний «в покое» и извлечь среднее смещение по каждой оси, чтобы получить значение, стабильное на весь срок службы устройства.
Ограничение доступа — и где оно не действует
Долгое время DeviceMotionEvent и DeviceOrientationEvent срабатывали вообще без единого запроса разрешения — любая страница могла подключить слушателя и начать бесшумно читать калибровочный шум в фоне, без каких-либо видимых признаков для пользователя. Это изменилось с выходом iOS 13, когда Apple начала требовать явного вызова DeviceOrientationEvent.requestPermission() — который обязательно должен исходить из пользовательского жеста вроде нажатия — прежде чем Safari начнёт отдавать какие-либо события движения или ориентации. Страница больше не может просто при загрузке читать акселерометр; ей нужно спросить, а пользователю — сначала увидеть и принять системный диалог.
Легко решить, что остальные движки последовали примеру. Chromium не последовал — и в этой детали стоит разобраться, потому что она касается большинства телефонов в мире.
Chromium действительно ограничивает, кто может добраться до датчиков. Доступ регулируется механизмом Permissions Policy, где список по умолчанию для accelerometer и gyroscope — 'self', так что стороннему кросс-доменному iframe они недоступны; кроме того, требуется защищённый (HTTPS) контекст и браузерный контекст верхнего уровня, находящийся в фокусе. Но чего Chromium не делает — так это не спрашивает пользователя. Его собственный проектный документ по Generic Sensor описывает модель прямым текстом: акселерометр и гироскоп — это «auto-grant + opt-out», то есть разрешение выдаётся автоматически, с возможностью отказаться. Никакого запроса при этом не появляется.
Именно поэтому accelerometer, gyroscope и magnetometer фигурируют как запрашиваемые названия в более широком векторе фингерпринтинга Permissions API — но то, что название можно запросить, не означает, что о нём спросили пользователя.
Честный итог — это раскол, а не чистая победа: сырой калибровочный сигнал по-прежнему присутствует в оборудовании везде. На iOS скрипт действительно не соберёт его, пока пользователь не нажмёт «Разрешить». А в Chrome на Android обычная страница верхнего уровня по HTTPS всё так же может подключить слушателя devicemotion и читать калибровочный шум без запроса и без каких-либо видимых признаков — практически как и десять лет назад. iOS закрыл бесшумную версию этой техники; Chromium лишь сузил проход, так и не вынеся решение на суд пользователя.
Почему это в первую очередь мобильный вектор
Акселерометры и гироскопы встречаются в ноутбуке или настольном компьютере по одной распространённой причине — функция определения закрытия крышки или обнаружения тряски на некоторых моделях, — но подавляющее большинство настольного оборудования вообще не поставляется с этим набором сенсоров, и ни DeviceMotionEvent, ни классы Generic Sensor не могут ничего считать в обычном настольном браузере. Телефоны и планшеты — противоположный случай: датчики движения и ориентации практически повсеместны, потому что сама ОС полагается на них для поворота экрана, подсчёта шагов и функций дополненной реальности, поэтому и оборудование, и раскрывающая его поверхность API присутствуют фактически на каждом устройстве этой категории.
Именно поэтому эта техника дополняет, а не дублирует более широкую картину мобильного фингерпринтинга: геометрия экрана и device-pixel-ratio сужают круг до вероятной модели устройства, которое у вас в руках, а калибровочный шум сенсоров — там, где он ещё доступен для чтения, — способен сузить его вплоть до конкретного экземпляра. Именно потому, что на мобильных платформах энтропия GPU и шрифтов давно сглажена массовым производством, такая точность «до отдельного аппарата» и оказывается особенно ценной. Это лишь небольшая часть общей картины фингерпринтинга браузера, но именно в мобильном трафике это один из немногих сигналов, переживающих даже полный сброс пользователем всего остального на устройстве.
Меры смягчения
- Держите ОС и браузер обновлёнными. Запрос разрешения на iOS появился именно как обновление браузера, а не как переключаемая настройка — устаревший мобильный браузер может по-прежнему отдавать данные о движении без единого запроса.
- Отклоняйте запросы на доступ к движению/ориентации, назначение которых вам непонятно, — и помните, где запроса не будет вовсе. На iOS у страницы, которая запрашивает доступ к акселерометру без очевидной причины (это не игра, не AR-функция и не шагомер), обычно нет законной потребности в нём, и отказ там работает. А в Chrome на Android запроса, который можно было бы отклонить, чаще всего просто нет — так что полагаться на него как на средство контроля не стоит.
- На Android реальный рычаг — выбор браузера. Раз Chromium выдаёт разрешение автоматически, осмысленная мера защиты — это не запрос, а браузер, который ограничивает или рандомизирует доступ к датчикам на уровне своей политики; это тот же класс защиты, что мы разбираем в сравнении инструментов приватности.
- Воспринимайте это как один сигнал среди многих. Даже там, где он доступен для чтения, калибровочный шум вносит лишь одну ось в более крупный фингерпринт наряду с параметрами экрана, строками GPU и состояниями разрешений — ни один отдельный сигнал не является серебряной пулей для трекеров, и ни одна отдельная мера не устраняет риск фингерпринтинга полностью.
- Проверьте, что раскрывает именно ваше устройство. Запустите проверку отпечатка BrowserInsight прямо на телефоне, который хотите оценить.
Часто задаваемые вопросы
Может ли сайт читать акселерометр моего телефона без запроса разрешения?
Зависит от телефона. На iOS — нет: начиная с iOS 13 Safari требует явного запроса разрешения через DeviceOrientationEvent.requestPermission(), и до вашего согласия ни одно событие не придёт. В Chrome на Android — обычно да: Chromium считает акселерометр и гироскоп выданными автоматически и не показывает никакого запроса. Он требует HTTPS, страницы верхнего уровня (не кросс-доменного iframe) и вкладки в фокусе — но в этих рамках страница вполне может читать данные о движении бесшумно.
Меняет ли сброс телефона его сенсорный фингерпринт?
Нет. Калибровочный шум возникает из-за производственных допусков физических чипов акселерометра и гироскопа, а не из-за какого-либо состояния ПО. Сброс до заводских настроек, переустановка ОС или смена браузера не меняют смещение базового оборудования.
Раскрывают ли этот сигнал настольные и ноутбучные браузеры тоже?
Редко. Большая часть настольного и ноутбучного оборудования просто не оснащена акселерометром или гироскопом, поэтому DeviceMotionEvent и классы Generic Sensor API попросту нечего сообщить. Это в подавляющем большинстве случаев сигнал телефонов и планшетов.
Идентифицирует ли фингерпринтинг сенсоров точнее, чем canvas или WebGL?
Сам по себе — нет, это более узкий, одноосевой сигнал. Его ценность для трекеров в необычной устойчивости (переживает сбросы и смену браузера) и в доступности на мобильных устройствах, где другие высокоэнтропийные настольные сигналы вроде шрифтов и рендеринга canvas сравнительно сглажены.
Полностью ли защитит отказ в доступе к датчикам движения?
Там, где запрос вообще появляется, — то есть на iOS — отказ действительно работает для этого источника: страница, так и не получившая разрешение, не получит вообще никаких событий движения или ориентации. В Chromium же отклонять обычно нечего, так что полагаться на это средство контроля там не выйдет. В любом случае это не влияет на другие пассивные сигналы вроде размера экрана, строк рендерера GPU или состояний разрешений, которые страница по-прежнему может читать без единого запроса.
Заключение
Фингерпринтинг сенсоров — узкий, но необычно устойчивый сигнал: там, где хеш canvas или список шрифтов может измениться с обновлением ПО, калибровочное смещение, «зашитое» в чип акселерометра или гироскопа, остаётся неизменным на весь срок службы устройства. Это ещё и наглядный пример того, насколько по-настоящему расходятся мобильный и настольный фингерпринтинг: сигнал, почти отсутствующий на ноутбуках, оказывается близким к повсеместному на телефонах — именно потому, что само оборудование там повсеместно.
Про разрешения большинство пересказов ошибается. iOS в 2019 году действительно закрыл бесшумную версию этой техники, и отсюда легко сделать обобщение «браузеры это починили». Но Chromium так и не ввёл запрос — его задокументированная модель это автоматическая выдача с возможностью отказаться, — поэтому на Android, где сосредоточено большинство мобильного трафика, страница верхнего уровня по HTTPS читает калибровочный шум сегодня примерно так же свободно, как и до iOS 13. Базовая физика при этом не изменилась ни там, ни там, и именно поэтому этот вектор стоит понимать отдельно, а не сворачивать в ориентированный на настольные системы плейбук фингерпринтинга.
Рекомендуем почитать:
