Торин Оукенпантс (Thorin Oakenpants), автор проекта arkenfox, предлагающего набор надстроек и изменений конфигурации к Firefox для усиления защиты и конфиденциальности пользователей, рассказал о развитии в Firefox новых средств для противодействия скрытой идентификации пользователей (fingerprinting).
Под скрытой идентификацией понимается формирование идентификаторов браузера в пассивном режиме на основе косвенных признаков, таких как как разрешение экрана, список поддерживаемых MIME-типов, специфичные параметры в заголовках (HTTP/2 и HTTPS), анализ установленных плагинов и шрифтов, доступность определённых Web API, анализ истории посещений, специфичные для видеокарт особенности отрисовки при помощи WebGL и Canvas, манипуляции с CSS, анализ особенностей работы с мышью и клавиатурой, а также методы хранения идентификаторов в областях, не предназначенных для постоянного хранения информации (“Supercookies”, например, кэш Favicon, база автозаполнения форм).
В Firefox планируют поддерживать две встроенные реализации защиты от скрытой идентификации (существуют и внешние дополнения для защиты, такие как CanvasBlocker):
- RFP (Resist Fingerprinting) – перенесённая из Tor Browser реализация защиты от снятия отпечатков, уже долгое время доступная через настройку “privacy.resistFingerprinting” в about:config .
- FFP (Future Fingerprinting Protection, в исходном коде и на Bugzilla иногда встречается устаревшее название RFPLite) – новая “облегчённая” реализация, которая призвана решить некоторые проблемы c usability в RFP, о которых в bugzilla.mozilla.org давно висят уведомления о проблемах. Для включения FFP в about:config предусмотрена настройка “privacy.fingerprintingProtection”.
Обе реализации могут быть включены одновременно, при этом будет применяется наиболее строгая защита.
Недостатком и одновременно достоинством существующей защиты (RFP) является то, что она активна одновременно во всех окнах и вкладках, кроме дополнений (т.е. защита либо включена либо выключена для всех окон и вкладок, без выборочной активации). С одной стороны это не позволяет пользователям деактивировать защиту для сайтов-монополистов, от работы с которыми пользователь не может отказаться, и которые из-за своего влияния имеют возможность выдвигать пользователям ультиматумы, вплоть до принуждения к использованию Chrome. С другой стороны, предложенный подход не позволяет менее влиятельным сайтам совершать подобные злоупотребления, так как велика вероятность, что пользователь просто перейдёт на другой сайт, а не будет отключать защиту специально ради них.
При этом наличие влиятельных сайтов, отказывающихся работать при использовании защиты, не позволяет включить защиту по умолчанию – пользователь просто перейдёт на браузеры на основе Chromium, чьи методы защиты приватности существенно уступают Firefox. Ещё одно достоинство RFP в том, что наличие единого переключателя упрощает интеграцию сложной функциональности в различные подсистемы браузера, уменьшая количество принимаемых в расчёт состояний системы.
Что касается новой системы защиты FFP, её главное достоинство в возможностях более гибкой настройки – предложено более 60 аспектов защиты, включение которых можно настроить через параметр privacy.fingerprintingProtection.overrides. Среди прочего поддерживается отключение защиты для определённых сервисов, а также при низком уровне нарушения работы сайтов – имеется возможность включить её по умолчанию.
Недостатки FFP – оборотные стороны достоинств:
- Система более сложна в реализации, и поэтому реализация и отладка сложного поведения, аналогичного RFP, приводит к бо́льшим трудозатратам. Отсюда следует, что при равных затратах на реализацию и поддержку обеих систем, FFP будет проигрывать по функциональности и/или стабильности, а также тому, какой любая из систем могла бы быть, если бы все ресурсы, отведённые на реализации защит от скрытой идентификации, не распылялись на несколько систем, а тратились эксклюзивно на одну из них.
- Так как защита может быть гибко настроена, и конкретные настройки скрыть на практике невозможно, то множество включённых защит само по себе является отпечатком. На практике это приведёт к тому, что ценящие приватность будут активировать настройки скоординированным образом. Однако сама возможность установки их нескоординированным образом приведёт к тому, что некоторое число пользователей их установит разнообразно, де-факто став уникальными.
- Выполнив ультиматум одного сервиса, пользователь потенциально предоставляет данные всем “сервисам”, с которым тот обменивается данными уже на стороне сервера. При этом возможность такого обмена данными отнюдь не иллюзорна, лежит в основе бизнес-модели ряда компаний и подтверждается исходным кодом некоторых сервисов (однако, читать обзорные статьи надо внимательно, есть шанс, что под отпечатками в том конкретном случае подразумевается не собранные на уровне приложения измерения свойств окружения, а информация сетевого и транспортного уровней). Отсюда становится не вполне понятной необходимость и ценность дополнительной реализации защиты от сбора отпечатков.
- Включение системы по умолчанию приведёт к росту доли пользователей, у которых она активна, вследствие этого – падению доходов от торговли данными, что будет подталкивать владельцев сервисов к дискриминации пользователей, у которых защита включена, с акцентом на то, чтобы вынудить пользователя отключить защиту для их сервиса.
Трудноопределяемая безопасная симуляция уязвимых для сбора отпечатка систем – сложная задача, которую, тем не менее, скорее всего можно успешно решить с использованием генеративных моделей и повторного задействования существующих компонентов ПО. Кроме того, реализация недетектируемости не является приоритетом для разработчиков браузеров, поэтому скорее всего эту “гонку вооружений” разработчики браузеров проиграют, и пользователям ничего не останется, кроме как выполнить условия ультиматума. Даже если предположить, что технологическую гонку разработчики браузеров выиграют, у владельцев сайтов всё равно останется возможность запретить неугодные браузеры на своём сайте через Web Environment Integrity.