Отпечатки пальцев

Снятие отпечатков пальцев означает попытку идентифицировать пользователя, когда он возвращается на ваш веб-сайт, или идентифицировать одного и того же пользователя на разных веб-сайтах. Многие характеристики вашей установки и чужой могут отличаться. Например, вы можете использовать другой тип устройства и другой браузер, у вас другой размер экрана и установлены другие шрифты. Если у меня установлен шрифт «Dejavu Sans», а у вас нет, то любой веб-сайт сможет отличить вас от меня, проверив этот шрифт. Вот как работает отпечаток пальца; вы создаете коллекцию этих точек данных, и каждая из них предоставляет больше способов различать пользователей.

Более формальное определение может выглядеть так: «Отпечатки пальцев» — это действие по использованию очевидных и неочевидных долговременных характеристик настроек пользователя, чтобы попытаться отличить его от как можно большего числа других пользователей.

Почему снятие отпечатков пальцев мешает конфиденциальности пользователей

Есть некоторые крайние случаи, когда важно снять отпечатки пальцев пользователя: например, обнаружение мошенничества. Но снятие отпечатков пальцев также может использоваться для отслеживания пользователей на разных сайтах, и это отслеживание часто осуществляется без согласия пользователей или, в некоторых случаях, на основе недействительного согласия, которое не информирует пользователя должным образом. Когда это будет сделано, эти пользователи часто будут находить это несколько тревожным и чувствовать себя преданными.

Снятие отпечатков пальцев означает поиск способов скрытно отличить одного пользователя от другого. Отпечатки пальцев можно использовать для распознавания того, что это все еще один и тот же пользователь на том же веб-сайте, или для распознавания одного и того же пользователя в двух разных профилях браузера одновременно. Это означает, что снятие отпечатков пальцев можно использовать для отслеживания пользователей на разных сайтах. Детерминированные и явные методы отслеживания, такие как хранение файлов cookie с уникальным идентификатором пользователя, могут в некоторой степени наблюдаться и контролироваться пользователями (некоторые из этих подходов были объяснены в предыдущем модуле). Но избежать снятия отпечатков пальцев труднее именно потому, что он является тайным; оно опирается на неизменные характеристики и, скорее всего, происходит незаметно. Вот почему это называется «отпечатками пальцев». Изменить отпечаток пальца, будь то цифровой или тот, что на кончиках пальцев, в лучшем случае сложно.

Производители браузеров знают , что пользователи не любят, когда их отслеживают, и постоянно внедряют функции, ограничивающие использование отпечатков пальцев (некоторые из которых мы видели в предыдущем модуле). Здесь мы рассмотрим, как эти функции могут повлиять на ваши бизнес-требования и как по-прежнему делать то, что вы хотите, с защитой конфиденциальности. Речь идет больше о том, как защита браузера от снятия отпечатков пальцев повлияет на то, что и как вы делаете, а не о том, как она помешает вам снимать отпечатки пальцев.

На практике большинству разработчиков и большинству предприятий нет необходимости снимать отпечатки пальцев пользователей. Если ваше приложение требует от пользователей входа в систему, то ваши пользователи идентифицируют себя перед вами со своего согласия и таким образом, что они могут в одностороннем порядке отказаться от участия в любое время по своему выбору. Это метод защиты конфиденциальности, позволяющий понять, какие пользователи вошли в систему. Ваше приложение может вообще не требовать от пользователей входа в систему, что еще более защищает конфиденциальность ваших пользователей (и тогда вы собираете только те данные, которые вам нужны ).

Делать

Оцените своих третьих лиц на предмет снятия отпечатков пальцев. В рамках модуля третьих сторон у вас уже может быть список всех сторонних сервисов, которые вы включаете, и веб-запросов, которые они делают. Возможно, удастся проверить эти запросы, чтобы увидеть, какие данные передаются обратно отправителю, если таковые имеются. Однако это часто бывает сложно; Снятие отпечатков пальцев по своей природе является скрытым процессом, который включает в себя запрос данных, не подлежащих одобрению пользователя.

Также стоит прочитать политику конфиденциальности ваших сторонних служб и зависимостей, чтобы найти признаки использования отпечатков пальцев. Иногда его называют «вероятностным сопоставлением» или частью набора методов вероятностного сопоставления, в отличие от «детерминистического сопоставления».

Как работает отпечаток пальца

Часто ваша личная комбинация всех этих качеств уникальна для вас или, по крайней мере, для небольшой группы похожих людей; это может быть использовано для тайного слежения за вами.

Дополнительно: пассивный и активный снятие отпечатков пальцев

Здесь следует провести полезное различие между пассивными и активными методами снятия отпечатков пальцев. Метод пассивного снятия отпечатков пальцев — это метод, который использует информацию, предоставленную веб-сайту по умолчанию; метод активного снятия отпечатков пальцев — это метод, который явно запрашивает браузер для получения дополнительной информации. Причина, по которой это различие важно, заключается в том, что браузеры могут попытаться обнаружить и перехватить или смягчить активные методы. API-интерфейсы могут быть ограничены или скрыты за диалоговым окном, запрашивающим разрешение пользователя (и, следовательно, предупреждающим пользователя о том, что они используются, или позволяющим пользователю отклонять их по умолчанию). Пассивный метод — это тот, который использует данные, которые уже были предоставлены веб-сайту, часто потому, что исторически, во времена зарождения информационной супермагистрали, эта информация была предоставлена ​​всем сайтам. Строка пользовательского агента является примером этого, и далее мы рассмотрим это более подробно. Это считалось полезным для предоставления довольно большого количества информации о браузере, версии и операционной системе пользователя, чтобы веб-сайт мог выбирать на основе этого различные данные. Однако это также увеличивает объем доступной отличительной информации, информации, которая помогает идентифицировать одного пользователя от другого; и поэтому такая информация становится все более недоступной или, по крайней мере, заморожена, чтобы ее больше нельзя было различать. Если то, что вы делаете, зависит от этой информации — например, если вы используете разные ветки кода в зависимости от пользовательского агента — тогда этот код может сломаться, поскольку браузеры все чаще зависают или останавливают эту информацию. Тестирование — лучшая защита в этом случае (см. ниже).

Кроме того: измерение отпечатков пальцев

Техническая мера того, сколько информации предоставляет каждая из этих точек данных, называется энтропией и измеряется в битах. Функция, в которой существует множество различных возможных значений (например, список установленных шрифтов), может внести большой вклад в общую сумму, при этом что-то без особой различительной способности (например, какую операционную систему вы используете) может добавить лишь несколько битов. . В HTTP-альманахе описывается, как существующие библиотеки снятия отпечатков пальцев автоматизируют этот процесс объединения ответов от множества различных API в «хеш», который может идентифицировать только небольшую группу пользователей, возможно, даже только одного. Мод Налпас подробно рассказывает об этом в этом видео на YouTube , но, короче говоря, представьте, что вы видите список своих друзей с указанием их любимой музыки, любимой еды и языков, на которых они говорят… но без их имен. Вполне вероятно, что список любого человека однозначно определит его среди ваших друзей или, по крайней мере, сузит список до нескольких человек. Вот как работает отпечаток пальца; список вещей, которые вам нравятся, становится «хешем». Благодаря этому хэшу становится проще идентифицировать пользователя как одного и того же человека на двух разных несвязанных сайтах, что и является целью отслеживания: обойти стремление пользователя к конфиденциальности.

Что делают браузеры против снятия отпечатков пальцев?

Важно отметить, что поставщики браузеров хорошо осведомлены о множестве различных способов, которыми веб-сайт (или третья сторона, включенная в веб-сайт) вычисляет отличительный отпечаток пальца пользователя или использует различные биты информации, чтобы внести вклад в уникальность этого отпечатка пальца. Некоторые из этих способов являются явными и преднамеренными, например строка пользовательского агента браузера, которая часто идентифицирует используемый браузер, операционную систему и версию (и, таким образом, помогает отличить вас от меня, если мы с вами используем разные браузеры). . Некоторые из способов не созданы намеренно для считывания отпечатков пальцев, но в любом случае остаются таковыми, например список шрифтов или видео- и аудиоустройств, доступных браузеру. (Браузеру не обязательно использовать эти устройства, просто получите их список по имени.) Было установлено, что некоторые из них способствуют созданию отпечатков пальцев уже после выпуска, например , точная пиксельная визуализация сглаживания шрифтов на холсте. элемент . Их гораздо больше, и каждое отличие вашего браузера от моего добавляет энтропии и, таким образом, потенциально способствует выявлению разницы между вами и мной и максимально уникальной идентификации отдельного человека на разных веб-сайтах. https://amiunique.org имеет длинный (но определенно не полный) список потенциальных функций, способствующих использованию отпечатков пальцев, и этот список постоянно растет (поскольку существует серьезный финансовый интерес в возможности снимать отпечатки пальцев пользователей, даже если пользователи этого не делают). не хочу этого или, возможно, не ожидаю этого).

Отсутствие поддержки некоторых мощных API.

Ответ производителей браузеров на все эти подходы к вычислению отпечатков пальцев пользователя заключается в поиске способов уменьшения количества энтропии, доступной от этих API. Самый ограничительный вариант — вообще не реализовывать их. Это было сделано некоторыми крупными браузерами для различных API-интерфейсов оборудования и устройств (таких как доступ NFC и Bluetooth из клиентских веб-приложений), при этом проблемы снятия отпечатков пальцев и конфиденциальности были названы причинами, по которым они не были реализованы. Это, очевидно, может повлиять на ваши приложения и сервисы: вы вообще не можете использовать API в браузере, который его не реализует, и это может ограничить или полностью исключить из рассмотрения некоторые аппаратные подходы.

Шлюз разрешений пользователей

Второй подход, используемый поставщиками браузеров, заключается в предотвращении доступа к API или данным без какого-либо явного разрешения пользователя. Этот подход часто используется также из соображений безопасности: веб-сайт не должен иметь возможности делать снимки с помощью вашей веб-камеры без вашего разрешения! Но здесь конфиденциальность и безопасность могут иметь схожие интересы. Определение чьего-либо местоположения, конечно, само по себе является нарушением конфиденциальности, но оно также способствует уникальности отпечатка пальца. Требование разрешения на просмотр геолокации не уменьшает дополнительную энтропию, которую местоположение добавляет к уникальности этого отпечатка пальца, но по сути исключает использование геолокации для снятия отпечатков пальцев, поскольку это больше не делается незаметно. Весь смысл снятия отпечатков пальцев состоит в том, чтобы незаметно отличить пользователей друг от друга. Если вы готовы к тому, что пользователь узнает, что вы пытаетесь его идентифицировать, вам не нужны методы снятия отпечатков пальцев: попросите пользователя создать учетную запись и войти с ней в систему.

Добавление непредсказуемости

Третий подход, применяемый в некоторых случаях, заключается в том, что производители браузеров «модифицируют» ответы API, чтобы сделать их менее детализированными и, следовательно, менее идентифицирующими. Это было описано как часть механизма рандомизированного ответа в модуле данных, как то, что вы можете сделать при сборе данных от пользователей, чтобы избежать непреднамеренного сбора идентифицирующих данных. Поставщики браузеров могут применять этот подход к данным API, которые также доступны веб-приложениям и третьим лицам. Примером этого являются очень точные API-интерфейсы синхронизации, используемые для измерения производительности страницы с помощью window.performance.now() . Браузер знает эти значения с точностью до микросекунды, но возвращаемые значения намеренно уменьшаются в точности путем округления до ближайшей границы в 20 микросекунд, чтобы избежать их использования при снятии отпечатков пальцев (а также в целях безопасности, чтобы избежать атак по времени). Целью здесь является обеспечение того, чтобы API оставались полезными, но при этом ответы были менее идентифицирующими: по сути, обеспечить «коллективный иммунитет», делая ваше устройство более похожим на устройства всех остальных, а не уникальным для вас. Именно по этой причине Safari представляет упрощенную версию конфигурации системы .

Обеспечение соблюдения бюджета конфиденциальности

Бюджет конфиденциальности — это предложение, которое предполагает, что браузеры оценивают информацию, предоставляемую каждой поверхностью для снятия отпечатков пальцев. Это еще не реализовано в браузерах. Цель — предоставить мощные API, сохраняя при этом конфиденциальность пользователей. Узнайте больше о предложении по бюджету на конфиденциальность .

Используйте широкую среду тестирования

Все это повлияет на то, как вы создаете приложения и сервисы. В частности, в этой области существует большое разнообразие ответов и подходов в разных браузерах и платформах. Это означает, что тестирование вашей работы в различных средах имеет решающее значение . Это, конечно, всегда важно, но можно разумно предположить, что рендеринг HTML или CSS будет постоянным для данного механизма рендеринга, независимо от того, в каком браузере или платформе он находится (и поэтому может возникнуть соблазн протестировать его в например, только один браузер на базе Blink). Это категорически не относится к использованию API именно потому, что браузеры, использующие общий механизм рендеринга, могут существенно различаться в том, как они защищают свою поверхность API от отпечатков пальцев.

Делать

  • Проверьте свою собственную аналитику и аудиторию, чтобы определить набор браузеров, которым следует отдать приоритет при тестировании.
  • Хорошим набором браузеров для тестирования являются Firefox, Chrome, Edge, Safari для настольных компьютеров, Chrome и Samsung Internet для Android и Safari для iOS. Это гарантирует, что вы сможете протестировать три основных механизма рендеринга (Gecko в Firefox, различные версии Blink в Chrome, Edge и Samsung Internet и Webkit в Safari), а также на мобильных и настольных платформах.
  • Если ваш сайт также можно использовать на менее распространенных устройствах, таких как планшеты, умные часы или игровые консоли, протестируйте и их. Некоторые аппаратные платформы могут отставать от мобильных и настольных компьютеров в обновлении браузеров, а это означает, что некоторые API-интерфейсы могут быть нереализованы или недоступны в браузерах на этих платформах.
  • Протестируйте с одним или несколькими браузерами, которые считают конфиденциальность пользователей мотивацией. Включите предстоящие предварительные и тестовые версии наиболее распространенных браузеров там, где это возможно и если они вам доступны: предварительная версия технологии Safari, Chrome Canary , бета-канал Firefox. Это дает вам наилучшие шансы выявить неисправности API и изменения, которые влияют на ваши сайты, прежде чем эти изменения повлияют на ваших пользователей. Аналогичным образом, учитывайте среду ваших пользователей в отношении любой имеющейся у вас аналитики. Если в вашей пользовательской базе много старых телефонов Android, обязательно включите их в свои тесты. У большинства людей нет такого быстрого оборудования и последних версий, которые есть у команды разработчиков.
  • Протестируйте, используя чистый профиль и режим инкогнито/приватного просмотра; вполне вероятно, что вы уже предоставили разрешения, необходимые в вашем личном профиле. Проверьте, что произойдет, если вы откажете сайту в разрешении на любой вопрос.
  • Явно проверяйте свои страницы в режиме защиты от отпечатков пальцев Firefox. При этом отобразятся диалоговые окна разрешений, если ваша страница пытается снять отпечатки пальцев, или будут возвращены нечеткие данные для некоторых API. Это поможет вам убедиться, что третьи стороны, включенные в ваш сервис, используют данные, позволяющие получить отпечатки пальцев, или от этого зависит ваш собственный сервис. Затем вы можете подумать, не усложняет ли преднамеренный фаззинг выполнение того, что вам нужно. Рассмотрите возможность внесения соответствующих исправлений, чтобы получить эти данные из другого источника, обойдитесь без них или используйте менее подробные данные.
  • Как обсуждалось ранее в модуле сторонних разработчиков , также важно проверять сторонние зависимости, чтобы увидеть, используют ли они методы снятия отпечатков пальцев. Пассивный сбор отпечатков пальцев трудно обнаружить (и невозможно, если третья сторона делает это на своем сервере), но режим снятия отпечатков пальцев может помечать некоторые методы снятия отпечатков пальцев, а поиск случаев использования navigator.userAgent или неожиданного создания объектов <canvas> также может выявить некоторые подходы, которые заслуживают дальнейшего рассмотрения. Также стоит поискать использование термина «вероятностное сопоставление» в маркетинговых или технических материалах, описывающих третью сторону; иногда это может указывать на использование методов снятия отпечатков пальцев.

Инструменты кроссбраузерного тестирования

Тестирование вашего кода в целях конфиденциальности сложно автоматизировать, и на что следует обращать внимание при тестировании вручную, описано ранее. Что происходит, когда вы отказываете сайту в разрешении, например, для любых API, к которым он пытается получить доступ, и как это представляется пользователю? Автоматизированный тест не может определить, действует ли сайт так, чтобы помочь пользователю доверять ему, или, наоборот, побуждает пользователя не доверять ему или думать, что что-то скрывается.

Однако после проверки сайта тестирование API для подтверждения того, что в новых версиях браузера (или в будущих «бета-версиях» и «предварительных» версиях) ничего не сломалось, может быть автоматизировано и в основном должно быть частью существующего теста. люкс. При использовании инструментов автоматического тестирования при работе с поверхностным покрытием API следует учитывать, что большинство браузеров допускают определенный уровень контроля над тем, какие API и функции доступны. Chrome делает это с помощью переключателей командной строки , как и Firefox , и доступ к ним в настройке инструмента тестирования позволит вам запускать определенные тесты с отключенными или включенными API. (См., например, плагин запуска браузера Cypress и параметр launch.args nd puppeteer, чтобы узнать, как добавлять флаги браузера при запуске.)

Для получения грубой информации полагайтесь только на строку пользовательского агента.

Другой пример: с самого начала существования Интернета браузеры отправляли свое описание с каждым запросом в заголовке HTTP User-Agent. Почти столько же времени люди призывали веб-разработчиков не использовать содержимое заголовка пользовательского агента для предоставления разного контента в разные браузеры, и все это время веб-разработчики все равно делали это, с определенной долей оправдания в некоторых случаях. (но не во всех) случаях. Поскольку браузеры не хотят, чтобы веб-сайты выделяли их из-за неоптимальной работы, это приводит к тому, что каждый браузер притворяется любым другим браузером, а строка пользовательского агента выглядит примерно так:

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36 .

В нем, среди прочего, утверждается, что это Mozilla/5.0, браузер, который был выпущен в то же время, когда более двух десятилетий назад первые астронавты поднялись на борт Международной космической станции. Строка user-agent, конечно, является богатым источником энтропии для снятия отпечатков пальцев, и чтобы смягчить эту возможность, производители браузеров либо уже заморозили заголовок user-agent, либо работают над этим. Это еще один пример изменения данных, предоставляемых API, без обязательного полного удаления API. Отправка пустого заголовка пользовательского агента приведет к поломке бесчисленного количества веб-сайтов, которые предполагают, что он присутствует. Итак, в целом браузеры удаляют из него некоторые детали, а затем сохраняют его практически без изменений. (Вы можете видеть, как это происходит в Safari , Chrome и Firefox .) Эта защита от подробного снятия отпечатков пальцев по сути означает, что вы больше не можете полагаться на точность заголовка пользовательского агента, и если вы это делаете, то важно найти альтернативные источники данных. .

Чтобы внести ясность, данные в пользовательском агенте не исчезают полностью, но они доступны с более низкой степенью детализации или иногда являются неточными, поскольку может быть сообщено более старое, но неизменное число. Например, Firefox, Safari и Chrome ограничивают заявленный номер версии macOS до десяти (дополнительную информацию см. в разделе Обновление по сокращению строки пользовательского агента здесь). Точные сведения о том, как Chrome планирует сократить количество данных в строке пользовательского агента, доступны на странице User-Agent Reduction , но, короче говоря, вы можете ожидать, что сообщаемый номер версии браузера будет содержать только основную версию (поэтому номер версии будет выглядеть например 123.0.0.0, даже если браузер имеет версию 123.10.45.108), а версия ОС будет без подробностей и будет привязана к одному из небольшого числа неизменных вариантов. Таким образом, воображаемая версия Chrome 123.45.67.89, работающая на воображаемой «Windows 20», сообщит номер своей версии как:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Основная информация, которая вам нужна (версия браузера), по-прежнему доступна: это Chrome 123 для Windows. Но вспомогательная информация (архитектура чипа, какая версия Windows, какую версию Safari он имитирует, дополнительная версия браузера) после заморозки больше не будет доступна.

Сравните это с «текущим» пользовательским агентом Chrome на другой платформе:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36 ,

и видно, что единственное, что отличается, это номер версии Chrome (104) и идентификатор платформы.

Аналогичным образом, строка пользовательского агента Safari показывает платформу и номер версии Safari, а также указывает версию ОС для iOS, но все остальное заморожено. Таким образом, воображаемый Safari версии 1234.5.67, работающий на воображаемой macOS 20, может указать свой пользовательский агент как:

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15 ,

а на воображаемой iOS 20 это может быть:

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15** .

Опять же, основная информация (это Safari, он на iOS или macOS) доступна, а iOS Safari по-прежнему предоставляет номер версии iOS; но большая часть вспомогательной информации, которая была доступна в прошлом, с тех пор была заморожена. Важно отметить, что сюда входит номер версии Safari, который не обязательно доступен.

Изменения в пользовательском агенте, о котором сообщается, вызвали горячие споры. https://github.com/WICG/ua-client-hints#use-cases суммирует некоторые аргументы и причины изменений, а у Роуэна Меревуда есть слайд-шоу с некоторыми стратегиями перехода от использования пользовательского агента. для дифференциации в контексте предложения UA Client Hints, поясняемого далее.

Фаззинг

Фаззинг — это термин из практики безопасности, когда API-интерфейсы вызываются с неожиданными значениями в надежде, что они плохо обработают эти неожиданные значения и обнаружат проблему безопасности. Веб-разработчики должны быть знакомы с межсайтовым скриптингом (XSS) , который предполагает добавление вредоносного скрипта на страницу, часто потому, что страница неправильно экранирует внедренный HTML (поэтому вы выполняете поисковый запрос с текстом <script> в нем). . Разработчики серверной части будут знать о SQL-инъекции , когда запросы к базе данных, которые неправильно проверяют вводимые пользователем данные, создают проблемы безопасности (как это, в частности, показано на примере xkcd с Little Bobby Tables ). Фаззинг или фазз-тестирование более правильно используется для автоматизированных попыток предоставить множество различных недействительных или неожиданных входных данных в API и для проверки результатов на наличие утечек безопасности, сбоев или других неправильных действий. Все это примеры умышленного предоставления неточной информации. Здесь, однако, это делается браузерами упреждающе (путем создания пользовательского агента намеренно неверным), чтобы побудить разработчиков перестать полагаться на эти данные.

Делать

  • Проверьте свою кодовую базу на наличие зависимости от строки user-agent (поиск navigator.userAgent , скорее всего, обнаружит большинство вхождений в вашем клиентском коде, а ваш внутренний код, скорее всего, будет искать User-Agent в качестве заголовка), включая ваши зависимости.
  • Если вы обнаружите применение в своем собственном коде, выясните, что именно проверяет код, и найдите другой способ провести это различие (или найдите заменяющую зависимость, или работайте с вышестоящей зависимостью, сообщая о проблемах или проверяя их на наличие обновлений). Иногда дифференциация браузера необходима для устранения ошибок, но пользовательский агент все чаще становится неспособным сделать это после его заморозки.
  • Вы можете быть в безопасности. Если вы используете только основные значения бренда, основной версии и платформы, то они почти наверняка все равно будут доступны и будут правильными в строке пользовательского агента.
  • MDN описывает хорошие способы избежать зависимости от строки пользовательского агента («обнюхивание браузера») , основным из которых является обнаружение функций.
  • Если вы каким-то образом полагаетесь на строку пользовательского агента (даже при использовании нескольких основных значений, которые остаются полезными), рекомендуется протестировать будущие пользовательские агенты, которые будут в новых версиях браузера. Можно протестировать сами будущие версии браузера с помощью бета-версий или предварительных сборок технологии, но также можно установить собственную строку пользовательского агента для тестирования. Вы можете переопределить строку пользовательского агента в Chrome, Edge , Firefox и Safari при локальной разработке, чтобы проверить, как ваш код обрабатывает различные значения пользовательского агента, которые вы можете получить от пользователей.

Советы клиенту

Одним из основных предложений по предоставлению этой информации является User-Agent Client Hints , хотя это поддерживается не во всех браузерах. Поддерживающие браузеры передадут три заголовка: Sec-CH-UA , который указывает марку браузера и номер версии; Sec-CH-UA-Mobile , который указывает, исходит ли запрос с мобильного устройства; и Sec-CH-UA-Platform , который называет операционную систему. (Разбор этих заголовков не так прост, как кажется, потому что они представляют собой структурированные заголовки , а не простые строки, и это обеспечивается браузерами, отправляющими «хитрые» значения, которые будут обрабатываться неправильно, если их не проанализировать должным образом. Это, как и ранее, пример разработчик, использующий эти данные, должен обращаться с ними должным образом, поскольку данные спроектированы таким образом, что неправильный или ленивый анализ, скорее всего, приведет к плохим результатам, например, к показу несуществующих брендов, или строки, которые не закрываются должным образом.) К счастью, эти данные также доступны браузером для JavaScript напрямую как navigator.userAgentData , который в поддерживающем браузере может выглядеть примерно так:

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}