Как отслеживают Android и iOS: device-pixel-ratio, датчики, различия WebView и Safari — и почему у телефонов меньше энтропии GPU и шрифтов.
Большая часть исследований и инструментов для фингерпринтинга написана с оглядкой на десктопный браузер, но сегодня больше половины веб-трафика приходит с телефонов. Мобильный фингерпринтинг — это не просто десктопная техника, запущенная на маленьком экране: массовое производство «схлопывает» одни сигналы, а сенсорный ввод, датчики и навязанные платформой движки браузера открывают новые. В этом материале разберём, что именно меняется, когда объектом фингерпринтинга становится устройство у вас в кармане.
Ключевые выводы
- Телефоны выпускаются в куда меньшем наборе комбинаций железа и ПО, чем ПК, поэтому сигналы canvas, WebGL и шрифтов несут меньше энтропии на мобильных устройствах, чем на десктопе.
- Мобильные устройства добавляют собственные ценные сигналы, которых у десктопов почти нет:
devicePixelRatio, точные размеры экрана, число точек касания и датчики движения/ориентации. - На iOS Apple требует, чтобы любой браузер — включая «Chrome» и «Firefox» — работал на WebKit, поэтому сам движок рендеринга почти ничего не говорит о том, каким приложением пользуются; на Android же приложения встраивают WebView на основе Chromium, который выдаёт себя токеном
wvв user-agent. - Carrier-Grade NAT означает, что многие мобильные пользователи и так делят один IP-адрес, поэтому фингерпринтинг на уровне устройства оказывается для трекеров сравнительно ценнее в мобильных сетях, чем в проводном широкополосном доступе.
- Собственные мобильные сигналы — метрики экрана, рендерер GPU, обнаружение WebView — можно увидеть с помощью проверки отпечатка от BrowserInsight, запущенной прямо в браузере телефона.
Почему мобильный отпечаток отличается от десктопного
Базовая механика фингерпринтинга одинакова на любом устройстве: объедините достаточно независимых сигналов, и пересечение сузится до одного браузера. На мобильных устройствах меняется форма этого энтропийного бюджета. Настольные ПК собираются из огромного числа независимо выбранных компонентов — видеокарта, монитор, шрифты, установленное ПО, — поэтому вывод рендеринга canvas и WebGL сильно различается от машины к машине. Телефоны устроены наоборот: конкретная модель поставляется с завода с одним фиксированным GPU, одним фиксированным набором предустановленных шрифтов и экраном, физический размер которого за вас выбрала Apple или производитель. Такая однородность снижает энтропию рендеринга на устройство, но не снижает идентифицируемость — она просто смещает источник идентифицирующей информации.
Device-pixel-ratio, экран и сигналы датчиков
Поскольку экраны телефонов выпускаются в ограниченном каталоге физических размеров, сочетание размеров в CSS-пикселях и devicePixelRatio куда более информативно на мобильных устройствах, чем аналогичные числа на десктопе. Значение 393×852 при device-pixel-ratio 3 — это не просто «какой-то экран телефона»: именно эта пара чисел соответствует конкретной линейке моделей iPhone, а в сочетании с отступами безопасной зоны из-за «чёлки» или Dynamic Island скрипт часто может сузить догадку до нескольких поколений устройств ещё до чтения хотя бы одного сигнала рендеринга.
Сенсорный ввод добавляет вторую структурную зацепку. navigator.maxTouchPoints и CSS-медиафича (pointer: coarse) отличают устройство с сенсорным вводом по умолчанию от устройства, управляемого мышью, и большинство мобильных браузеров стабильно сообщают ненулевое число точек касания, даже когда палец не касается стекла. Ещё более чувствительный уровень добавляют движение и ориентация: события DeviceOrientationEvent и DeviceMotionEvent, стандартизированные как часть семейства Generic Sensor API от W3C, раскрывают показания акселерометра и гироскопа в реальном времени. Начиная с iOS 13 Apple требует явного разрешения пользователя для доступа к этим данным, и с тех пор браузеры постепенно ужесточают доступ; там, где эти данные всё ещё доступны без запроса разрешения, небольшой, но устойчивый калибровочный дрейф показаний акселерометра сам по себе может служить низкоуровневой аппаратной подписью.
Android WebView против Chrome и iOS Safari
Какой именно движок отрисовывает мобильную страницу, зависит от платформы, а не от приложения, — и обе платформы навязывают это противоположными способами.
На Android любое приложение может встроить компонент Google WebView на основе Chromium, чтобы отрисовывать веб-контент внутри собственного интерфейса — предпросмотр в меню «Поделиться», встроенный браузер, экран входа. Такой встроенный WebView обычно добавляет токен wv к своему user-agent (например, Mozilla/5.0 (Linux; Android 14) ... Chrome/124.0.0.0 Mobile Safari/537.36 wv) — именно по нему сайты и аналитические инструменты отличают «настоящий Chrome» от встроенного браузера приложения. Документация Chrome по WebView для нескольких устройств описывает, как этот компонент версионируется и обновляется независимо от приложения-хоста — а значит, одно устройство на Android может одновременно нести несколько разных реально работающих версий WebView в разных приложениях.
На iOS правила App Store от Apple заставляют любой сторонний браузер использовать WebKit — тот же движок, что и Safari, — поэтому «Chrome для iOS» и «Firefox для iOS» на деле являются оболочками WebKit вокруг кода рендеринга Apple, а не движками Blink или Gecko, которые эти названия подразумевают на десктопе. У встроенного просмотра на iOS тоже есть своё разделение: приложения, использующие SFSafariViewController, разделяют cookie и сохранённые логины с Safari, а приложения со встроенным «голым» WKWebView получают изолированный контекст с отдельными cookie. Это различие важно для отслеживания — сессия WKWebView внутри социального приложения не видит вашу историю просмотров в Safari, но её всё равно можно фингерпринтить независимо. Документация WebKit по предотвращению отслеживания описывает правила разделения хранилища, действующие в этих разных контекстах.
Почему на мобильных устройствах меньше энтропии GPU и шрифтов
Поскольку конкретная модель телефона поставляется с одним GPU и одним набором шрифтов, «сырая» уникальность, которую дают эти сигналы, на мобильных устройствах ниже — но сами значения больше говорят о конкретной модели устройства. Строка рендерера WebGL вроде Apple GPU в сочетании с сообщаемым номером семейства GPU соответствует конкретному диапазону чипов iPhone и iPad, а строки рендерера Adreno от Qualcomm или Mali от ARM на Android аналогично соответствуют определённым поколениям SoC. Перечисление шрифтов куда менее полезно на мобильных устройствах, чем на десктопе, поскольку ни iOS, ни Android не позволяют обычным приложениям устанавливать системные шрифты так, как это делают Windows и macOS, — большинство телефонов показывают каждой странице один и тот же небольшой список шрифтов, встроенных в ОС. Это сводит один из самых высокоэнтропийных сигналов десктопа почти к нулю на мобильных устройствах, и именно поэтому сигналы экрана, датчиков и касаний, описанные выше, несут пропорционально больший вес в идентификации.
| Сигнал | Энтропия на десктопе | Энтропия на мобильных | Почему различается |
|---|---|---|---|
| Рендеринг canvas / WebGL | Высокая | Ниже | У каждой модели телефона фиксированный, ограниченный набор GPU |
| Установленные шрифты | Высокая | Очень низкая | Приложения обычно не могут добавлять системные шрифты на iOS/Android |
| Размер экрана + device-pixel-ratio | Низкая | Высокая | Физические размеры экрана соответствуют конкретным моделям устройств |
| Точки касания / тип указателя | Н/П | Умеренная | Подтверждает сенсорное устройство по умолчанию, чего почти нет у десктопов |
| Датчики движения/ориентации | Н/П | Умеренная | Показания акселерометра/гироскопа в реальном времени, зависят от разрешения |
| User-agent / токен WebView | Умеренная | Высокая | Отличает нативный браузер, встроенный WebView и конкретное приложение |
Что видят и чего не видят операторы связи и приложения
Всё описанное выше выполняется на стороне клиента, внутри собственного JavaScript страницы, — это то, что сайт может узнать о зашедшем на него телефоне, и оно никогда само по себе не уходит на сервер. Мобильный оператор или приложение-хост WebView видят другую, сетевую картину: ваш IP-адрес, заголовок User-Agent, а для оператора конкретно — через какую вышку и какой шлюз прошёл ваш трафик, а не хеш canvas или показания датчиков. Мобильные сети дополнительно усложняют отслеживание по IP, поскольку операторы пропускают большие пулы абонентов через Carrier-Grade NAT (CGNAT), так что тысячи телефонов могут в любой момент делить один видимый публичный IP. Это хорошо для приватности местоположения, но с точки зрения трекера это делает IP-адрес более слабым идентификатором на мобильных устройствах, чем в проводном домашнем интернете, — именно поэтому сигналы на уровне устройства и браузера, описанные выше, значат больше для уникальной идентификации мобильного посетителя, чем для десктопного, сидящего за собственным выделенным IP.
Проверьте собственные мобильные сигналы
Самый быстрый способ увидеть, насколько раскрыт браузер вашего телефона: откройте проверку отпечатка от BrowserInsight прямо на телефоне. Она покажет сочетание размеров экрана и device-pixel-ratio, строку рендерера GPU, наличие токена WebView в user-agent и общую оценку анонимности — а затем запустите её ещё раз во встроенном браузере какого-нибудь приложения, чтобы увидеть, насколько иначе о себе сообщает этот контекст.
Часто задаваемые вопросы
Мобильный фингерпринтинг проще или сложнее десктопного?
Точнее будет сказать — он устроен иначе. Сигналы canvas, WebGL и шрифтов несут меньше энтропии на мобильных устройствах, потому что железо и ПО более стандартизированы. Но метрики экрана, касания, датчики и контекст WebView/приложения добавляют сигналы, которых у десктопов почти нет, так что мобильного посетителя всё равно можно эффективно сузить до конкретного устройства — просто самые ценные сигналы теперь другие.
Даёт ли использование Chrome или Firefox на iPhone другой отпечаток, чем Safari?
На уровне движка — почти нет. Apple требует, чтобы любой браузер на iOS использовал WebKit, поэтому «Chrome для iOS» отрисовывает страницы тем же движком, что и Safari. Сами приложения всё же могут отличаться строкой user-agent, поддержкой расширений и настройками по умолчанию, но глубинные сигналы рендеринга — вывод canvas и WebGL — во всех них исходят из одного и того же базового кода WebKit.
Может ли сайт понять, что он работает внутри встроенного WebView, а не в настоящем браузере?
Обычно да. Android WebView, как правило, добавляет токен wv к своей строке user-agent, а встроенные браузеры на обеих платформах часто лишены API или расширений, доступных в полноценном приложении-браузере, либо показывают отличающуюся конфигурацию viewport/безопасной зоны. Сайты, для которых это важно (проверка рекламы или обнаружение ботов), специально проверяют эти признаки.
Действительно ли датчики телефона вроде акселерометра используются для фингерпринтинга?
Они могут давать слабый сигнал в браузерах, которые всё ещё раскрывают данные о движении без запроса разрешения, поскольку производственные допуски оставляют небольшой, но устойчивый калибровочный дрейф на каждом устройстве. Это второстепенный сигнал по сравнению с данными экрана и GPU, и с iOS 13 Apple требует явного разрешения на доступ к нему, что закрыло тихую версию этого вектора на устройствах Apple.
Защищает ли VPN от фингерпринтинга мобильного браузера?
Нет, по той же причине, что и на десктопе: VPN меняет ваш IP-адрес, а не метрики экрана, рендерер GPU, датчики или сигнатуру WebView. Он помогает с отдельной проблемой отслеживания на уровне сети и оператора связи, но скрипт фингерпринтинга считывает одни и те же сигналы устройства независимо от того, активен ли VPN-туннель.
Заключение
Мобильный фингерпринтинг — это не уменьшенная версия десктопного: он отдаёт часть самых высокоэнтропийных сигналов десктопа в обмен на другой набор, который работает не менее эффективно. Стандартизированное железо сглаживает энтропию canvas, WebGL и шрифтов, но точная геометрия экрана, данные касаний и датчиков, а также разделение между нативными браузерами и встроенными WebView с лихвой это компенсируют. Всем, кто строит или оценивает системы фингерпринтинга для мобильного трафика, нужно взвешивать эти сигналы иначе, чем для десктопных посетителей, — а всем, кто хочет понять собственную уязвимость, стоит проверить, что реально сообщает их телефон, а не полагаться на десктопные рекомендации без изменений.
Рекомендуем прочитать:
