Около года назад, Apple опубликовала список API для веба, которые они не собираются внедрять в Safari из соображений приватности и безопасности. Они беспокоились, что эти API позволят создавать цифровой след пользователей и отслеживать их. И это конечно же большое табу с точки зрения современной приватности. Звучит разумно, верно?
Что за API оказались в том списке? Среди прочих, аппаратные API, которые появились в браузерах Chrome и Edge за последние пару лет:
- WebBluetooth
- WebHID
- WebMidi
- WebNFC
- WebSerial
- WebUSB
Звучит ну прямо очень опасно, да?
Я понимаю некоторые сомнения по поводу появления этих возможностей в вебе. Они мощные и поэтому кажутся потенциально опасными. Никто не хочет, чтобы случайный сайт захватил контроль над устройствами в вашем доме, доставлял вредоносный код, шпионил за вами или чего хуже. Я понимаю эти сомнения.
Но нам следует взглянуть на фактическую опасность, рассмотреть её должным образом и не верить всяким «нутром чую» или страшилкам из того эпизода «Чёрного зеркала», что мы однажды видели…
Реальность такова, что для каждой возможности, что предлагает веб-платформа, существует баланс между пользой, безопасностью и приватностью. И эти API определённо полезны. И, что более важно, они также относительно безопасны. Я думаю, что добавление этих API в веб-платформу даже увеличит безопасность пользователей.
Любой API, потенциально влияющий на безопасность и приватность, не может использоваться на сайте без согласия пользователя. Такой сайт должен запросить разрешение у пользователя, чтобы использовать веб-камеру — аналогично и для использование Bluetooth-устройства или USB-устройства. И разрешение получает не API целиком — оно даётся отдельно взятому устройству. Сайт не знает, какие есть устройства, и не может получить их список. Сайт может только попросить разрешение для доступа к определённому типу устройств. Он его либо получит, либо нет.
Пользователи всегда контролируют происходящее, и их действие необходимо, чтобы разрешить доступ к определённому устройству.
Проблемы с безопасностьюСкопировать ссылку
Главная проблема здесь не техническая, проблема в социальной инженерии. Вы можете вынудить пользователя сделать что-то, что ему навредит.
Например, вставьте на сайт вредоносный код. Он сообщит пользователю о якобы-проблеме и подскажет как подключиться к устройству, чтобы установить драйверы, которые скомпрометируют устройство или смогут извлечь ценную информацию с устройства каким-то другим образом. Для такого вам всегда придётся обмануть пользователя — ведь мы поняли, что пользователю придётся вручную выбрать устройство, прежде чем вредоносный код сможет получить к нему доступ.
Я бы рад сказать, что это невозможно, но, к сожалению, это существующая проблема. Социальная инженерия — это общая проблема, которая не ограничивается лишь использованием API.
Но даже если это теоретически возможно, то кажется маловероятным для использования в больших масштабах.
Во-первых, необходимо найти уязвимое устройство, которое принимает драйверы или код, не подписанный производителем. У большинства устройств такой проблемы не будет, но не у всех. Во-вторых, у пользователей, на которых направлена атака, должно быть это устройство. У большинства, скорее всего, его не окажется. И, в-третьих, ещё нужно обмануть пользователей, чтобы они выбрали это устройство. Скорее всего, большинство засомневаются и откажутся. И наконец, запрашивать доступ к устройству — довольно подозрительное дело, которое легко заметить. Я не думаю, что такого рода атаку можно будет поддерживать длительное время.
Но когда речь заходит о достаточно большой группе пользователей, число устройств, которые можно скомпрометировать, не будет равно нулю.
Есть простые действия, которые производители браузеров уже используют для дальнейшего уменьшения такого риска:
- Блокировка доступа к отдельным устройствам, у которых известны уязвимости.
- Запрет доступа к целому классу устройств с проблемами.
- Удалённое прекращение работы API, когда его активно используют для эксплуатации уязвимости в устройстве.
Несмотря на это, риск всё ещё не нулевой.
Насколько мне известно, удалённое выключение API использовалось лишь однажды. И не потому что API активно эксплуатировалось, а потому что исследователи безопасности сообщили об уязвимости. Тем не менее, этого хватило, чтобы применить «рубильник».
В 2018 году оказалось возможным извлечь ключ из устройства двухфакторной авторизации Yubico U2F, используя WebUSB в обход проверки происхождения запроса, которую обычно делают браузеры. После того, как это стало известно, Google сразу отключил WebUSB и следом выпустил обновление, которое снова включало WebUSB, но добавляло все устройства Yubico в чёрный список.
Мне кажется, что причина, по которой мы не видели подобных атак, состоит в том, что намного проще загрузить нативное приложение и выполнить его на устройстве пользователя, чем найти тот самый вариант один-из-миллиона, в котором сойдутся все составляющее: доверчивый пользователь и уязвимое устройство. Проще говоря, игра не стоит свеч.
Не только Google думает, что эти API достаточно безопасны, чтобы предлагать их реальным пользователям. Так же думают Microsoft и Samsung. В действительности, эти API поставляются на 70% мобильных браузеров и 78% десктопных браузеров по всему миру. И поставляются уже достаточно давно.
Но я думаю, что настоящий безопасный выбор лежит не между браузерами с API и браузерами без API.
Для специфичной задачи, которую пытается решить пользователь, обычно стоит выбор между браузером и нативным приложением. Выбор между ограниченным API, построенным вокруг пользовательского согласия в изолированной среде, и нативным приложением, которое может делать что угодно, без проверок на приватность или безопасность. Вы бы загрузили какое-то сомнительное приложение, созданное неизвестным разработчиком из магазина приложений, которое делает кто-знает-что с вашими данными в фоновом режиме?
Ограничивая доступ к API устройств нативными приложениями, вы заставляете людей пользоваться нативными приложениями для таких задач. И это плохо для безопасности.
Самое опасное, что умеют браузеры — это не доступ к API устройств. Это возможность ссылаться на нативные приложения и загружать их.
Именно эта способность активнее всего используется сейчас и с самого первого момента, когда браузер попал в руки широкой публики. И время доказало, что нет почти ничего, что могло бы снизить риски.
Приватность и цифровой следСкопировать ссылку
Что насчёт цифрового следа? Возможно ли проследить цифровой след пользователя, используя эти API?
По правде говоря, в этом нет много смысла. Использование цифрового следа в качестве аргумента против этих API всего лишь демонстрирует нехватку понимания, как эти API вообще работают.
Цель создания цифрового следа — идентифицировать уникального пользователя. Этого можно добиться, используя уникальные опорные точки для больших групп пользователей. Каждый набор таких точек не может идентифицировать конкретного пользователя, но его можно отследить, если у вас будет достаточно опорных точек, чтобы их скомбинировать.
Такие точки могут быть ничем не примечательны сами по себе с точки зрения приватности. Это могут быть даже вещи, которые по иронии были предназначены для улучшения приватности. Например, HTTP-заголовок «Do Not Track». Он выключен по умолчанию, поэтому это идеальная опорная точка для отслеживания пользователей. Например, если у вас есть набор из 1 миллиона пользователей и один из сотни включил этот заголовок. Теперь вы уже можете наблюдать за 1 из 10 000 пользователей вместо одного из миллиона. Теперь попробуйте скомбинировать это с ещё хотя бы 30 типами вполне невинных опорных точек и вы можете отслеживать конкретных пользователей на разных сайтах — святой грааль отслеживания пользователя.
HTTP-заголовок «Do Not Track» был удалён из Safari как раз из соображений выше. Ну и правильно.
Вопрос вот в чём: добавляют ли эти API опорные точки для отслеживания конечных пользователей?
Теоретически, да. Простая поддержка таких API уже может считаться опорной точкой. Но на практике — нет. Возьмём, например, WebBluetooth. Он был доступен во всех версиях Chrome, начиная с 56-й. Поэтому единственное, о чём это говорит, так это то, старше ли Chrome 56-й версии или нет. И эту информацию можно добыть, просто заглянув в строку User-Agent, которая всегда есть в HTTP-запросе. Поэтому эти точки выглядят крайне бесполезными для создания цифрового следа.
Для цифрового следа нужны API, дающее разные результаты на разных устройствах. Например, установленные шрифты или GL-расширения, поддерживаемые графической картой. Эти параметры могут отличаться на устройствах с одинаковыми версиями браузеров. Такие опорные точки добавляют энтропии в цифровой след.
И что же эти API? Дают ли они какую-то дополнительную информацию для цифрового следа? Если браузер знает, какие USB-устройства подключены к вашей ОС или какие Bluetooth-устройства доступны поблизости, я бы сказал: «да, конечно». Но эти API работают не так. Их проектировали, зная о цифровом следе, поэтому они не могут использоваться для этого напрямую.
Возьмём для примера снова WebBluetooth как представителя аппаратных API.
Давайте проговорим это ещё раз. Вы не можете получить список устройств поблизости. Так нельзя сделать ни с помощью WebBluetooth, ни с помощью каких-либо других API устройства. Эта информация не доступна сайтам. Вы можете не переживать, что сайты увидят ваши устройства и смогут идентифицировать вас через них. Потому что они не смогут.
Что сайты смогут сделать, так это сказать браузеру, с какими устройствами они бы хотели взаимодействовать. Обычно вы даёте API набор фильтров, основанных либо на имени устройства, либо на его сервисах. И тогда вы просите у браузера разрешение подключиться к устройству.
Затем браузер показывает попап, спрашивающий разрешение. В нём перечислен список устройств, соответствующий фильтрам, которые вы запросили. Этот список доступен только самому пользователю, ни один скрипт на сайте его не видит. Дальше пользователь может дать доступ к определённому устройству или отказать в доступе в целом.
Этот попап устроен так, что он бесполезен для создания цифрового следа, поскольку это должно происходить в фоне, незаметно для пользователя. Также это делает опорные точки ненадёжными, ведь нет гарантии, что пользователь каждый раз разрешит доступ.
API устройств просто не подходят для создания цифрового следа. Они слишком ненадёжны и очевидны, когда используются.
Так что там с Safari…Скопировать ссылку
Вполне нормально сомневаться в безопасности аппаратных API. Лично я думаю, что риски относительно малы и с ними можно справиться. Нет ничего плохого в том, чтобы дискутировать об этом и не соглашаться. Но использование цифрового следа и отслеживания в качестве аргументов говорит о том, что у вас нет достаточной информации по вопросу.
Я даже не против, если Safari не будет внедрять эти возможности. Каждый производитель браузеров должен самостоятельно оценивать баланс между пользой, безопасностью, приватностью, и решать, стоит ли оно того. Apple подумала и решила, что не стоит. Я считаю иначе, но это ничего.
Я уверен, что они игнорируют опасность перевода пользователей на нативные приложения, но понимаю, почему для Apple это не выглядит так.
Но я против последствий этого выбора. Из-за того, что Safari — единственный настоящий браузер на iOS, пользователи не могут выбрать другой браузер, поддерживающий аппаратные API. Это большая проблема. Выбор Safari сказывается не только на самом Safari, но и на всех браузерах на этой крайне важной платформе. И это сказывается на мне, как на пользователе.
