Что такое третья сторона?
Довольно редко веб-сайт является полностью автономным. Веб-альманах HTTP показывает, что большинство веб-сайтов (около 95%) содержат сторонний контент .
Альманах определяет сторонний контент как нечто, размещенное в общедоступном и общедоступном источнике, широко используемое различными сайтами и не подверженное влиянию отдельного владельца сайта. Это могут быть изображения или другие носители, такие как видео, шрифты или сценарии. Изображения и сценарии составляют больше, чем все остальное, вместе взятое. Сторонний контент не является обязательным для разработки сайта, но вполне может быть таковым; вы почти наверняка будете использовать что-то, загруженное с общедоступного сервера, будь то веб-шрифты, встроенные iframe видео, рекламные объявления или библиотеки JavaScript. Например, вы можете использовать веб-шрифты, предоставляемые Google Fonts, или измерять аналитику с помощью Google Analytics; возможно, вы добавили кнопки «Нравится» или «Войти с помощью» из социальных сетей; вы можете встраивать карты или видео или совершать покупки через сторонние сервисы; вы можете отслеживать ошибки и регистрироваться для своих собственных команд разработчиков с помощью сторонних инструментов мониторинга.
В целях конфиденциальности полезно рассмотреть немного другое и менее широкое определение: сторонний ресурс и, в частности, сторонний сценарий обслуживаются из общего и общедоступного источника и широко используются, как показано, но также являются авторами. кем-то, кроме владельца сайта. Аспект стороннего авторства является ключевым при рассмотрении вопроса о том, как защитить конфиденциальность ваших пользователей от других. Это заставит вас рассмотреть существующие риски, а затем решить, как и стоит ли использовать сторонний ресурс, исходя из этих рисков. Как уже обсуждалось, эти вещи помогут вам понять контекст и, следовательно, понять, на какие компромиссы вам нужно пойти и что они означают.
Это не совсем то, что имеется в виду при обсуждении «сторонних ресурсов» в целом: различие между собственными и сторонними на самом деле связано с контекстом, в котором что-то используется. Сценарий, загруженный с другого веб-сайта, является сторонним ресурсом, и HTTP-запрос, загружающий сценарий, может включать файлы cookie, но эти файлы cookie на самом деле не являются «сторонними файлами cookie»; это просто файлы cookie, и являются ли они «сторонними» или «собственными» зависит от того, загружается ли скрипт на страницу вашего сайта или на страницу сайта владельца скрипта.
Почему мы используем сторонние ресурсы?
Сторонние поставщики — отличный способ добавить функциональность вашему сайту. Это могут быть функции, доступные пользователям, или невидимые функции разработчика, такие как отслеживание ошибок, но они уменьшают вашу нагрузку на разработку, а сами сценарии поддерживаются кем-то другим: командой разработчиков службы, которую вы включаете. Все это работает благодаря возможности компоновки сети: возможности соединить части вместе, чтобы сформировать целое, которое больше, чем их сумма.
Веб-альманах HTTP Archive дает хорошее описание:
Третьи стороны предоставляют бесконечную коллекцию изображений, видео, шрифтов, инструментов, библиотек, виджетов, трекеров, рекламы и всего остального, что вы можете встроить в наши веб-страницы. Это позволяет даже самым нетехническим специалистам создавать и публиковать контент в Интернете. Без третьих сторон Интернет, скорее всего, был бы очень скучной текстовой академической средой, а не богатой, захватывающей и сложной платформой, которая сегодня так неотъемлема для жизни многих из нас.
Что могут сторонние ресурсы?
Доступ к некоторой информации
Когда вы используете сторонний ресурс на своем веб-сайте, независимо от того, что это такое, некоторая информация передается этой третьей стороне. Например, если вы включаете изображение с другого сайта, HTTP-запрос, который делает браузер пользователя, будет передавать заголовок Referer с URL-адресом вашей страницы, а также IP-адрес пользователя.
Межсайтовое отслеживание
Продолжая тот же пример: когда изображение загружается со стороннего сайта, оно может включать файл cookie, и этот файл cookie будет отправлен обратно третьей стороне, когда пользователь в следующий раз запросит это изображение. Это означает, что третья сторона может знать, что их сервис используется на вашем сайте, и может отправить обратно файл cookie, возможно, с уникальным идентификатором этого пользователя. Это означает, что в следующий раз, когда пользователь посетит ваш сайт или любой другой сайт, который содержит ресурс этой третьей стороны , этот уникальный идентификатор cookie будет отправлен снова. Это позволяет третьей стороне вести журнал посещений пользователя: вашего сайта, других сайтов, использующих тот же сторонний ресурс, по всей сети.
Это межсайтовое отслеживание : разрешение третьей стороне собирать журнал активности пользователя на многих веб-сайтах, если все эти веб-сайты используют ресурс, принадлежащий одной и той же третьей стороне. Это может быть шрифт, изображение или таблица стилей — все статические ресурсы. Это также может быть динамический ресурс: фрагмент сценария, кнопка социальной сети, реклама. Включенный скрипт может собирать еще больше информации, поскольку он динамичен: он может проверять браузер и среду пользователя и передавать эти данные обратно отправителю. В некоторой степени это может сделать любой скрипт, а также динамические ресурсы, которые не представлены как скрипт, такие как встраивание в социальные сети, реклама или кнопка «Поделиться». Если вы посмотрите на информацию о баннере файлов cookie на популярных веб-сайтах, вы увидите список организаций, которые могут добавлять файлы cookie отслеживания вашим пользователям, чтобы составить представление об их действиях и создать профиль этого пользователя. Их могут быть сотни. Если третья сторона предлагает услугу бесплатно, один из способов, которым это может быть для нее экономически целесообразно, — это сбор и последующая монетизация этих данных.
Полезным руководством по типам проблем конфиденциальности, от которых браузер должен защищать своих пользователей, является Модель угроз целевой конфиденциальности . На момент написания этот документ все еще обсуждался, но он дает некоторые общие классификации существующих видов угроз конфиденциальности. Риски, связанные со сторонними ресурсами, заключаются в первую очередь в «нежелательном межсайтовом распознавании», когда веб-сайт может идентифицировать одного и того же пользователя на нескольких сайтах, и в «раскрытии конфиденциальной информации», когда сайт может собирать информацию, которую пользователь считает конфиденциальной.
Это ключевое различие : нежелательное межсайтовое распознавание — это плохо, даже если третья сторона не получает от него дополнительную конфиденциальную информацию, поскольку оно лишает пользователя контроля над своей личностью. Получение доступа к рефереру пользователя, его IP-адресу и файлам cookie само по себе является нежелательным раскрытием информации. Использование сторонних ресурсов сопровождается компонентом планирования того, как вы будете использовать их с соблюдением конфиденциальности. Часть этой работы лежит на вас как разработчике сайта, а часть выполняется браузером в роли пользовательского агента; то есть агент работает от имени пользователя, чтобы избежать раскрытия конфиденциальной информации и нежелательного межсайтового распознавания, где это возможно. Ниже мы более подробно рассмотрим меры по снижению риска и подходы на уровне браузера и уровне разработки сайта.
Сторонний код на стороне сервера
Наше более раннее определение третьей стороны намеренно изменило клиентский подход HTTP Almanac (что соответствует их отчету!), Включив в него авторство третьей стороны, поскольку с точки зрения конфиденциальности третья сторона — это любой, кто знает что-либо о вашем пользователи, которые не вы.
Сюда входят третьи лица, предоставляющие услуги, которые вы используете на сервере, а также на клиенте. С точки зрения конфиденциальности также важно понимать стороннюю библиотеку (например, включенную в NPM, Composer или NuGet). Переносят ли ваши зависимости данные за пределы ваших границ? Если вы передаете данные в службу регистрации или в удаленно размещенную базу данных, если библиотеки, которые вы включаете, также «звонят домой» их авторам, то они могут быть в состоянии нарушить конфиденциальность ваших пользователей, и поэтому их необходимо проверять. Обычно вы передаете пользовательские данные третьей стороне, расположенной на сервере, а это означает, что данные, которым она подвергается, находятся в большей степени под вашим контролем. Напротив, третья сторона на основе клиента — сценарий или HTTP-ресурс, включенный в ваш веб-сайт и полученный браузером пользователя — может собирать некоторые данные непосредственно от пользователя без вашего посредника в этом процессе сбора. Большая часть этого модуля будет посвящена тому, как идентифицировать те третьи стороны на стороне клиента, которые вы решили включить и предоставить своим пользователям, именно потому, что с вашей стороны возможно меньше посредничества. Но стоит подумать о защите вашего серверного кода, чтобы вы могли понимать исходящие от него сообщения и иметь возможность регистрировать или блокировать любые неожиданные сообщения. Подробности о том, как именно это сделать, выходят за рамки нашей компетенции (и очень зависят от настроек вашего сервера), но это еще одна часть вашей политики безопасности и конфиденциальности.
Почему нужно быть осторожным с третьими лицами?
Сторонние скрипты и функции действительно важны, и наша цель как веб-разработчиков должна состоять в том, чтобы интегрировать такие вещи, а не отворачиваться от них! Но есть потенциальные проблемы. Сторонний контент может создавать проблемы с производительностью, а также проблемы с безопасностью, поскольку вы подключаете внешнюю службу внутри своей границы доверия. Но сторонний контент также может создавать проблемы с конфиденциальностью!
Когда мы говорим о сторонних ресурсах в сети, полезно подумать о проблемах безопасности, заключающихся (помимо прочего) в том, что третья сторона может украсть данные вашей компании, и сопоставить это с проблемами конфиденциальности, которые (среди прочего) другие вещи), когда третья сторона, которую вы включили, крадет данные ваших пользователей или получает доступ к ним без вашего (или их) согласия.
Примером проблемы безопасности является то, что «веб-скиммеры» крадут информацию о кредитной карте — сторонний ресурс, включенный в страницу, на которую пользователь вводит данные кредитной карты, потенциально может украсть эти данные кредитной карты и отправить их. злонамеренной третьей стороне. Те, кто создает эти сценарии скиммеров, очень изобретательно подходят к разработке мест, где их можно спрятать. В одном из обзоров описывается, как сценарии скиммера были скрыты в стороннем контенте, таком как изображения, используемые для логотипов сайтов, значков сайтов и сетей социальных сетей, в популярных библиотеках, таких как jQuery, Modernizr и Google Tag Manager, в виджетах сайта, таких как окна живого чата. и файлы CSS.
Вопросы конфиденциальности немного отличаются. Эти третьи стороны являются частью вашего предложения ; Чтобы сохранить доверие пользователей к вам, вы должны быть уверены, что пользователи могут им доверять. Если третья сторона, которую вы используете, собирает данные о ваших пользователях, а затем злоупотребляет ими, или затрудняет их удаление или обнаружение, или подвергается утечке данных, или нарушает ожидания ваших пользователей, то ваши пользователи, скорее всего, воспримут это как нарушение их доверие к вашим услугам, а не просто к третьей стороне. На кону ваша репутация и отношения. Вот почему важно спросить себя: доверяете ли вы третьим лицам, которых используете на своем сайте?
Каковы примеры третьих сторон?
Обычно мы говорим о «третьих лицах», но на самом деле они бывают разные, и они имеют доступ к разным объемам пользовательских данных. Например, добавление элемента <img> в ваш HTML, загруженного с другого сервера, предоставит этому серверу другую информацию о ваших пользователях, чем добавление элемента <iframe> или элемента <script> . Это примеры, а не полный список, но полезно понимать различия между различными типами сторонних элементов, которые может использовать ваш сайт.
Запрос межсайтового ресурса
Межсайтовый ресурс — это все на вашем сайте, которое загружается с другого сайта и не является <iframe> или <script> . Примеры включают <img> , <audio> , <video> , веб-шрифты, загружаемые CSS, и текстуры WebGL. Все они загружаются через HTTP-запрос, и, как описано ранее, эти HTTP-запросы будут включать в себя любые файлы cookie, ранее установленные другим сайтом, IP-адрес запрашивающего пользователя и URL-адрес текущей страницы в качестве источника перехода. Все сторонние запросы исторически включали эти данные по умолчанию, хотя предпринимаются попытки сократить или изолировать данные, передаваемые третьим лицам различными браузерами, как описано далее в разделе «Понимание защиты сторонних браузеров».
Встраивание межсайтового iframe
Полный документ, встроенный в ваши страницы через <iframe> , может запрашивать дополнительный доступ к API-интерфейсам браузера, в дополнение к тройке файлов cookie, IP-адресу и рефереру. Какие именно API доступны для страниц <iframe> d и как они запрашивают доступ, зависит от браузера и в настоящее время претерпевает изменения: см. «Политику разрешений» ниже, чтобы узнать о текущих усилиях по ограничению или мониторингу доступа к API во встроенных документах.
Выполнение межсайтового JavaScript
Включение элемента <script> загружает и запускает межсайтовый JavaScript в контексте верхнего уровня вашей страницы. Это означает, что выполняемый сценарий имеет полный доступ ко всему, что делают ваши собственные сценарии. Разрешения браузера по-прежнему управляют этими данными, поэтому для запроса местоположения пользователя (например) по-прежнему потребуется пользовательское соглашение. Но любая информация, присутствующая на странице или доступная в виде переменных JavaScript, может быть прочитана таким скриптом, и это включает в себя не только файлы cookie, которые передаются третьей стороне как часть запроса, но и файлы cookie, предназначенные только для вашего сайта. Точно так же сторонний скрипт, загруженный на вашу страницу, может выполнять те же HTTP-запросы, что и ваш собственный код, а это означает, что он может отправлять запросы fetch() к вашим серверным API для получения данных.
Включение сторонних библиотек в ваши зависимости
Как описано ранее, ваш серверный код, вероятно, также будет включать сторонние зависимости, и они по своей мощности неотличимы от вашего собственного кода; код, который вы включаете из репозитория GitHub или библиотеки вашего языка программирования (npm, PyPI, композитор и т. д.), может читать все те же данные, что и другой ваш код.
Знание ваших третьих лиц
Таким образом, для этого требуется некоторое понимание вашего списка сторонних поставщиков, а также их политики и политики конфиденциальности, сбора данных и взаимодействия с пользователем. Это понимание затем становится частью вашей серии компромиссов: насколько полезна и важна услуга, сбалансированная с тем, насколько навязчивы, неудобны или тревожны их требования для ваших пользователей. Сторонний контент приносит пользу, взяв на себя тяжелую работу как владельца сайта, и позволяет вам сосредоточиться на своих основных компетенциях; и поэтому есть смысл пойти на этот компромисс и пожертвовать некоторым пользовательским комфортом и конфиденциальностью ради лучшего пользовательского опыта. Однако важно не путать пользовательский опыт с опытом разработчиков : фраза «нашей команде разработчиков легче создать сервис» не является убедительной историей для пользователей.
То, как вы достигаете этого понимания, — это процесс аудита.
Проведите аудит третьих лиц
Понимание того, что делает третья сторона, является процессом аудита . Сделать это можно как технически, так и нетехнически, и для отдельного третьего лица, и для всей вашей коллекции.
Провести нетехнический аудит
Первый шаг нетехнический: прочтите политику конфиденциальности ваших поставщиков. Если вы включаете какие-либо сторонние ресурсы, ознакомьтесь с политикой конфиденциальности. Они будут длинными и насыщенными юридическим текстом, а в некоторых документах могут использоваться некоторые подходы, против которых конкретно предостерегалось в предыдущих модулях , например, слишком общие заявления и без каких-либо указаний на то, как и когда собранные данные будут удалены. Важно понимать, что с точки зрения пользователя все данные, собираемые на вашем сайте, в том числе третьими лицами, будут регулироваться настоящей политикой конфиденциальности. Даже если вы все сделаете правильно, если вы прозрачны в отношении своих целей и превосходите ожидания пользователей в отношении конфиденциальности и конфиденциальности данных, пользователи также могут возложить на вас ответственность за все, что делают выбранные вами третьи стороны. Если в их политике конфиденциальности есть что-то, что вы не хотели бы упоминать в своей политике, поскольку это может снизить доверие пользователей, подумайте, есть ли альтернативный поставщик.
Это то, что может с пользой идти рука об руку с техническим аудитом, обсуждаемым далее, поскольку они информируют друг друга. Вы должны знать сторонние ресурсы, которые вы используете по деловым причинам (например, рекламные сети или встроенный контент), поскольку между ними будут установлены деловые отношения. Это хорошее место для начала нетехнического аудита. Технический аудит также может выявить третьи стороны, особенно те, которые включены по техническим, а не деловым причинам (внешние компоненты, аналитика, служебные библиотеки), и этот список может присоединиться к списку третьих лиц, ориентированных на бизнес. Цель здесь состоит в том, чтобы вы, как владелец сайта, почувствовали, что понимаете, чем занимаются третьи стороны, которых вы добавляете на свой сайт, и чтобы вы, как компания, имели возможность предоставить своему юрисконсульту этот список третьих лиц, чтобы сделать убедитесь, что вы выполняете все необходимые обязательства.
Провести технический аудит
Для технического аудита важно использовать ресурсы на месте как часть веб-сайта; то есть не загружайте зависимость в тестовую среду и не проверяйте ее таким образом. Убедитесь, что вы видите, как ваши зависимости действуют как часть вашего реального веб-сайта, развернутого в общедоступном Интернете, а не в режиме тестирования или разработки. Очень поучительно просмотреть свой собственный веб-сайт новым пользователем. Откройте браузер в новом чистом профиле, чтобы вы не вошли в систему и не имели сохраненного соглашения, и попробуйте посетить свой сайт.
Зарегистрируйтесь на своем сайте для получения новой учетной записи, если вы предоставляете учетные записи пользователей. Ваша команда дизайнеров организует этот процесс привлечения новых пользователей с точки зрения UX, но может быть полезно подойти к нему с точки зрения конфиденциальности. Не нажимайте просто «Принять» в условиях использования, предупреждении о файлах cookie или политике конфиденциальности; поставьте себе задачу использовать свой собственный сервис, не раскрывая никакой личной информации и не имея никаких файлов cookie для отслеживания, и посмотрите, сможете ли вы это сделать и насколько сложно это сделать. Также может быть полезно заглянуть в инструменты разработчика браузера, чтобы узнать, к каким сайтам осуществляется доступ и какие данные передаются на эти сайты. Инструменты разработчика предоставляют список отдельных HTTP-запросов (обычно в разделе «Сеть»), и отсюда вы можете увидеть запросы, сгруппированные по типу (HTML, CSS, изображения, шрифты, JavaScript, запросы, инициированные JavaScript). Также можно добавить новый столбец, чтобы показать домен каждого запроса, который покажет, сколько разных мест связывается с вами, а также может быть установлен флажок «Запросы третьих лиц», чтобы отображать только третьи стороны. (Также может быть полезно использовать отчеты Content-Security-Policy для проведения постоянного аудита, о чем читайте дальше.)
Инструмент Саймона Хирна «Генератор карт запросов» также может быть полезным обзором всех подзапросов, которые создает общедоступная страница.
Это также момент, когда вы можете включить в нетехнический аудит третьи стороны, ориентированные на бизнес (то есть: список компаний, с которыми у вас есть финансовые отношения, чтобы использовать их ресурсы). Цель здесь — сопоставить список третьих сторон, которыми, по вашему мнению, вы пользуетесь (на основе финансовых и юридических записей), и список, который вы на самом деле используете (просматривая, какие сторонние HTTP-запросы отправляет ваш веб-сайт). У вас должна быть возможность определить для каждой третьей стороны, какие технические исходящие запросы сделаны. Если в ходе технического аудита вы не можете идентифицировать запросы третьей стороны, идентифицированной по деловым отношениям, важно выяснить, почему, и руководствоваться этим при тестировании: возможно, этот сторонний ресурс загружается только в определенной стране или на определенном тип устройства или для вошедших в систему пользователей. Это расширит список областей сайта, подлежащих аудиту, и гарантирует, что вы увидите все исходящие доступы. (Или, возможно, он определит сторонний ресурс, за который вы платите, но не используете, что всегда подбадривает финансовый отдел.)
После того как вы сузили список запросов к третьим лицам, которые вы хотели бы принять участие в аудите, нажатие на отдельный запрос покажет все его подробности и, в частности, какие данные были переданы в этот запрос. Также очень часто сторонний запрос, инициируемый вашим кодом, затем инициирует множество других сторонних запросов . Эти дополнительные третьи лица также «импортируются» в вашу собственную политику конфиденциальности. Эта задача трудоемкая, но ценная, и ее часто можно включить в существующие анализы; ваша команда разработчиков внешнего интерфейса уже должна проверять запросы на предмет производительности (возможно, с помощью существующих инструментов, таких как WebPageTest или Lighthouse), а включение аудита данных и конфиденциальности в этот процесс может облегчить его.
Делать
Откройте браузер с чистым новым профилем пользователя, чтобы вы не вошли в систему и не имели сохраненного соглашения; затем откройте панель «Сеть» инструментов разработки браузера, чтобы увидеть все исходящие запросы. Добавьте новый столбец, чтобы отображать домен каждого запроса, и установите флажок «сторонние запросы», чтобы отображать только третьи стороны, если они есть. Затем:
- Посетите ваш сайт.
- Зарегистрируйте новую учетную запись, если вы предоставляете учетные записи пользователей.
- Попробуйте удалить созданную учетную запись.
- Выполните одно или два обычных действия на сайте (что именно будет зависеть от того, что делает ваш сайт, но выберите общие действия, которые выполняет большинство пользователей).
- Выполните одно или два действия, которые, как вы знаете, связаны, в частности, со сторонними зависимостями. Это может включать в себя обмен контентом в социальных сетях, начало процесса оформления заказа или встраивание контента с другого сайта.
При выполнении каждой из этих задач записывайте ресурсы, запрошенные из чужих доменов, просматривая описанную панель «Сеть». Это некоторые из ваших третьих лиц. Хороший способ сделать это — использовать сетевые инструменты браузера для записи журналов сетевых запросов в файл HAR.
HAR-файлы и захват
Файл HAR представляет собой стандартизированный формат JSON всех сетевых запросов, выполняемых страницей. Чтобы получить HAR-файл для конкретной страницы, выполните следующие действия:
Хром
Откройте инструменты разработчика браузера ( Меню > Дополнительные инструменты > Инструменты разработчика ), перейдите на панель «Сеть», загрузите (или обновите) страницу и выберите символ сохранения со стрелкой вниз в правом верхнем углу рядом с раскрывающимся меню «Без регулирования».
Firefox
Откройте инструменты разработчика браузера ( Меню > Дополнительные инструменты > Инструменты веб-разработчика ), перейдите на панель «Сеть», загрузите (или обновите) страницу и выберите символ шестеренки в правом верхнем углу рядом с раскрывающимся меню регулирования. В его меню выберите «Сохранить все как HAR **».
Сафари
Откройте инструменты разработчика браузера ( Меню > Разработка > Показать веб-инспектор ; если у вас нет меню «Разработка», включите его в Меню > Safari > Настройки > Дополнительно > Показать меню «Разработка» в строке меню), перейдите на панель «Сеть», загрузите (или обновите) страницу и выберите «Экспорт» в правом верхнем углу (справа от «Сохранить журнал»; возможно, вам придется увеличить окно).
Для более подробной информации вы также можете записывать то, что передается третьим лицам (в разделе «Запрос»), хотя эти данные часто запутаны и не поддаются полезной интерпретации.
Лучшие практики при интеграции третьих сторон
Вы можете установить свои собственные политики в отношении того, какие третьи лица используются на вашем сайте: изменить поставщика рекламы, которого вы используете, в зависимости от его практики, или того, насколько раздражающим или навязчивым является всплывающее окно согласия на использование файлов cookie, или хотите ли вы использовать кнопки социальных сетей на своем сайте или отслеживание. ссылки в ваших электронных письмах или ссылки utm_campaign для отслеживания в Google Analytics в ваших твитах. Одним из аспектов, который следует учитывать при разработке сайта, является уровень конфиденциальности и безопасности вашей аналитической службы. Некоторые аналитические сервисы явно стремятся к защите конфиденциальности. Часто есть также способы использовать сторонний скрипт, который сам по себе добавляет защиту конфиденциальности: вы не первая команда, стремящаяся улучшить конфиденциальность своих пользователей и защитить их от сбора сторонних данных, и, возможно, уже есть решения. Наконец, многие сторонние поставщики сейчас более чувствительны к проблемам сбора данных, чем раньше, и часто вы можете добавить функции или параметры, которые обеспечивают более защищенный режим для пользователей. Вот несколько примеров.
При добавлении кнопки «Поделиться» в социальных сетях
Рассмотрите возможность встраивания HTML-кнопок напрямую: на сайте https://sharingbuttons.io/ есть несколько хорошо продуманных примеров. Или вы можете добавить простые HTML-ссылки. Компромисс здесь заключается в том, что вы теряете статистику «подсчета акций» и возможность классифицировать своих клиентов в аналитике Facebook. Это пример компромисса между использованием стороннего поставщика и получением меньшего количества аналитических данных.
В более общем смысле, когда вы встраиваете какой-либо интерактивный виджет от третьей стороны, часто вместо этого можно предоставить ссылку на эту третью сторону. Это означает, что на вашем сайте нет встроенного интерфейса, но это переносит решение о передаче данных третьей стороне от вас к вашему пользователю, который может выбирать, взаимодействовать или нет, по своему усмотрению.
Например, вы можете добавить ссылки для Twitter и Facebook, чтобы поделиться своим сервисом на mysite.example.com, вот так:
<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&url=https%3A%2F%2Fmysite.example.com"
rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>
Обратите внимание, что Facebook позволяет указать URL-адрес для публикации, а Twitter позволяет указать URL-адрес и некоторый текст.
При вставке видео
Когда вы встраиваете видео с видеохостингов, обратите внимание на параметры сохранения конфиденциальности в коде внедрения. Например, для YouTube замените youtube.com в URL-адресе внедрения на www.youtube-nocookie.com , чтобы избежать отслеживания файлов cookie, размещаемых пользователями, просматривающими страницу встраивания. Вы также можете установить флажок «Включить режим повышенной конфиденциальности» при создании ссылки «Поделиться/Встроить» на самом YouTube. Это хороший пример использования более защищенного для пользователя режима, предоставляемого третьей стороной. ( https://support.google.com/youtube/answer/171780 описывает это более подробно, а также другие варианты встраивания специально для YouTube.)
У других видеосайтов в этом отношении меньше возможностей: например, в TikTok на момент написания этой статьи нет возможности вставлять видео без отслеживания. Можно размещать видео самостоятельно (это альтернативный вариант), но это может потребовать гораздо больше работы, особенно для поддержки множества устройств.
Как и в случае с интерактивными виджетами, обсуждавшимися ранее, часто можно заменить встроенное видео ссылкой на веб-сайт, предоставляющий его. Это менее интерактивно, поскольку видео не будет воспроизводиться в режиме онлайн, но оставляет возможность выбора, смотреть ли его вместе с пользователем. Это можно использовать в качестве примера «шаблона фасада», названия для динамической замены интерактивного контента чем-то, требующим действия пользователя для его запуска. Встроенное видео TikTok можно заменить простой ссылкой на страницу видео TikTok, но, приложив немного усилий, можно получить и отобразить миниатюру видео и сделать из нее ссылку. Даже если выбранный поставщик видео не поддерживает простой способ встраивания видео без отслеживания, многие видеохосты поддерживают oEmbed , API, который при предоставлении ссылки на видео или встроенный контент возвращает для него программные подробности, включая миниатюру. и титул. TikTok поддерживает oEmbed (подробнее см. https://developers.tiktok.com/doc/embed-videos ), что означает, что вы можете (вручную или программно) включить ссылку на видео TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 в метаданные JSON об этом видео с помощью https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 и, следовательно, получите миниатюру для отображать. WordPress часто использует это, например, для запроса информации oEmbed для встроенного контента. Вы можете использовать это программно, чтобы показать «фасад», который выглядит интерактивным и переключается на встраивание или ссылку на интерактивное видео, когда пользователь решает щелкнуть по нему.
При встраивании скриптов аналитики
Аналитика предназначена для сбора информации о ваших пользователях для ее анализа: вот для чего она нужна. Системы аналитики — это, по сути, службы для сбора и отображения данных о доступе и пользователях, которые для простоты внедрения выполняются на стороннем сервере, таком как Google Analytics. Существуют также автономные аналитические системы, такие как https://matomo.org/ , хотя это требует больше усилий, чем использование для этого стороннего решения. Однако запуск такой системы в вашей собственной инфраструктуре поможет вам сократить сбор данных, поскольку она не выходит за пределы вашей собственной экосистемы. С другой стороны, управление этими данными, их удаление и установка политик для них становится вашей обязанностью. Большая часть проблем, связанных с межсайтовым отслеживанием, возникает, когда оно осуществляется тайно и секретно, или является побочным эффектом использования службы, которая вообще не требует сбора данных. Аналитическое программное обеспечение явно предназначено для сбора данных, чтобы информировать владельцев сайтов о своих пользователях.
Исторически существовал подход, заключающийся в сборе всех возможных данных обо всем, как в гигантской рыболовной сети, а затем их последующего анализа на предмет интересных закономерностей. Такое мышление в значительной степени создало чувство беспокойства и беспокойства по поводу сбора данных, которое обсуждалось в первой части этого курса. Сейчас многие сайты сначала решают, какие вопросы задавать, а затем собирают конкретные и ограниченные данные, чтобы ответить на эти вопросы.
Если какой-либо сторонний сервис используется вашим сайтом и другими сайтами, и он работает, если вы включаете их JavaScript на свой сайт, и устанавливает файлы cookie для каждого пользователя, то важно учитывать, что они могут выполнять нежелательные межсайтовые действия. признание; то есть отслеживание ваших пользователей на разных сайтах. Кто-то может, а кто-то нет, но позиция защиты конфиденциальности здесь заключается в том, чтобы предположить, что такая сторонняя служба на самом деле осуществляет межсайтовое отслеживание, если у вас нет веских причин думать или знать иное. Это само по себе не является причиной избегать таких услуг, но это следует учитывать при оценке компромиссов при их использовании.
Раньше компромисс в аналитике заключался исключительно в выборе, использовать ее или нет: собрать все данные и поставить под угрозу конфиденциальность в обмен на идеи и планирование или полностью отказаться от идей. Однако сейчас это уже не так, и между этими двумя крайностями часто можно найти золотую середину. Узнайте у своего поставщика аналитики параметры конфигурации, позволяющие ограничить собираемые данные и сократить объем и продолжительность их хранения. Поскольку у вас есть записи технического аудита, описанного ранее, вы можете повторно запустить соответствующие разделы этого аудита, чтобы убедиться, что изменение этих конфигураций действительно уменьшает объем собираемых данных. Если вы осуществляете этот переход на существующем сайте, это может дать вам некую количественную оценку, которую можно будет описать для ваших пользователей. Например, Google Analytics имеет ряд дополнительных функций конфиденциальности (поэтому отключенных по умолчанию) , многие из которых могут быть полезны для соблюдения местных законов о защите данных. Некоторые варианты, которые следует учитывать при настройке Google Analytics, включают установку периода хранения собранных данных («Администратор» > «Информация об отслеживании» > «Хранение данных») ниже, чем 26-месячный срок по умолчанию, а также включение некоторых более технических решений, таких как частичная анонимизация IP-адресов (см. https) . ://support.google.com/analytics/answer/9019185 для получения более подробной информации).
Использование третьих лиц с соблюдением конфиденциальности
До сих пор мы обсуждали, как защитить ваших пользователей от третьих лиц на этапе разработки вашего приложения, пока вы планируете, что это приложение будет делать. Решение вообще не использовать конкретную третью сторону является частью этого планирования, и аудит вашего использования также попадает в эту категорию: речь идет о принятии решений о вашей позиции конфиденциальности. Однако эти решения по своей сути не очень детализированы; Выбор использования конкретной третьей стороны или отказ от этого не является тонким решением. Гораздо более вероятно, что вам захочется чего-то среднего: вам нужно или вы планируете использовать конкретное стороннее предложение, но при этом смягчите любые тенденции к нарушению конфиденциальности (будь то преднамеренные или случайные). Это задача защиты пользователей во время «сборки»: добавление мер безопасности для уменьшения вреда, которого вы не ожидали. Все это новые HTTP-заголовки, которые вы можете предоставить при обслуживании страниц и которые будут подсказывать или приказывать пользовательскому агенту принять определенные меры конфиденциальности или безопасности.
Политика рефералов
Делать
Установите политику strict-origin-when-cross-origin или noreferrer , чтобы другие сайты не получали заголовок Referer, когда вы ссылаетесь на них или когда они загружаются страницей как подресурсы:
index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />
Или на стороне сервера, например в Express:
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
При необходимости установите более мягкую политику для конкретных элементов или запросов.
Почему это защищает конфиденциальность пользователей
По умолчанию каждый HTTP-запрос, который отправляет браузер, передает заголовок Referer , который содержит URL-адрес страницы, инициирующей запрос, будь то ссылка, встроенное изображение или скрипт. Это может быть проблемой конфиденциальности, поскольку URL-адреса могут содержать личную информацию, и те URL-адреса, доступные третьим лицам, передают им эту личную информацию. Web.dev перечисляет несколько примеров URL-адресов, содержащих личные данные: зная, что пользователь пришел на ваш сайт с https://social.example.com/user/me@example.com , вы узнаете, кто этот пользователь, что является явной утечкой. . Но даже URL-адрес, который сам по себе не раскрывает личную информацию, показывает, что этот конкретный пользователь (которого вы, возможно, знаете, если он вошел в систему) пришел сюда с другого сайта, и, следовательно, это показывает, что этот пользователь посетил этот другой сайт. Это само по себе раскрывает информацию, которую вам, возможно, не следует знать об истории просмотров вашего пользователя.
Предоставление заголовка Referrer-Policy (с правильным написанием!) позволяет изменить это, чтобы часть ссылающегося URL-адреса не передавалась или не передавалась вообще. MDN перечисляет полную информацию, но большинство браузеров теперь по умолчанию приняли предполагаемое значение strict-origin-when-cross-origin , что означает, что URL-адрес реферера теперь передается третьим лицам только как источник ( https://web.dev а не https://web.dev/learn/privacy ). Это полезная защита конфиденциальности, не требующая от вас никаких действий. Но вы можете еще больше усилить это, указав Referrer-Policy: same-origin , чтобы вообще не передавать какую-либо информацию о реферере третьим лицам (или Referrer-Policy: no-referrer чтобы избежать передачи кому-либо, включая ваше собственное происхождение). (Это хороший пример баланса между конфиденциальностью и полезностью; новое значение по умолчанию гораздо лучше сохраняет конфиденциальность, чем раньше, но оно по-прежнему предоставляет информацию высокого уровня третьим сторонам по вашему выбору, таким как ваш поставщик аналитических услуг.)
Также полезно явно указать этот заголовок , поскольку тогда вы точно будете знать, какова политика, а не полагаться на настройки браузера по умолчанию . Если вы не можете устанавливать заголовки, то можно установить политику реферера для всей HTML-страницы, используя мета-элемент в <head> : <meta name="referrer" content="same-origin"> ; а если вас беспокоят конкретные третьи стороны, также можно установить атрибут referrerpolicy для отдельных элементов, таких как <script> , <a> или <iframe> : <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">
Политика безопасности контента
Заголовок Content-Security-Policy , часто называемый «CSP», определяет, откуда можно загружать внешние ресурсы. Он в основном используется в целях безопасности, предотвращая атаки с использованием межсайтовых сценариев и внедрение сценариев, но при использовании вместе с вашими регулярными аудитами он также может ограничить то, куда выбранные вами третьи лица могут передавать данные.
Потенциально это не очень приятный пользовательский опыт; если один из ваших сторонних скриптов начнет загружать зависимость из источника, которого нет в вашем списке, то этот запрос будет заблокирован, скрипт завершится сбоем, и ваше приложение может выйти из строя из-за него (или, по крайней мере, его работа будет сведена к ошибке JavaScript). резервная версия). Это полезно, когда CSP реализуется для обеспечения безопасности, что является его обычной целью: защита от проблем с межсайтовым выполнением сценариев (и для этого используйте строгий CSP ). Как только вы узнаете все встроенные скрипты, которые использует ваша страница, вы можете составить их список, вычислить значение хеш-функции или добавить случайное значение (называемое «nonce») для каждого, а затем добавить список хэшей в свою систему безопасности контента. Политика. Это предотвратит загрузку любого сценария, которого нет в списке. Это необходимо внедрить в производственный процесс сайта: сценарии на ваших страницах должны включать одноразовый номер или рассчитывать хеш как часть сборки. Подробности смотрите в статье о strict-csp .
К счастью, браузеры поддерживают связанный заголовок Content-Security-Policy-Report-Only . Если указан этот заголовок, запросы, нарушающие указанную политику, не будут блокироваться, но отчет JSON будет отправлен на указанный URL-адрес. Такой заголовок может выглядеть следующим образом: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/ , и если браузер загружает скрипт из любого места, кроме 3p.example.com , этот запрос будет успешным, но отчет будет отправлен на предоставленный report-uri . Обычно это используется для экспериментирования с политикой перед ее реализацией, но здесь полезно использовать это как способ проведения «постоянного аудита». Помимо обычного аудита, описанного ранее, вы можете включить отчеты CSP, чтобы увидеть, появляются ли какие-либо неожиданные домены, что может означать, что ваши сторонние ресурсы загружают собственные сторонние ресурсы, и которые вам необходимо учитывать и оценивать. (Конечно, это также может быть признаком того, что некоторые эксплойты межсайтового скриптинга вышли за пределы вашей безопасности, о чем также важно знать!)
Content-Security-Policy — это сложный и неудобный в использовании API. Это известно, и ведется работа по созданию «следующего поколения» CSP, которое будет соответствовать тем же целям, но не будет таким сложным в использовании. Оно еще не готово, но если вы хотите посмотреть, где это заголовок (или примите участие и помогите в его разработке!), затем посетите https://github.com/WICG/csp-next для получения подробной информации.
Делать
Добавьте этот заголовок HTTP к обслуживаемым страницам: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control . Когда JSON будет отправлен на этот URL-адрес, сохраните его. Просмотрите эти сохраненные данные, чтобы получить коллекцию сторонних доменов, которые запрашивает ваш веб-сайт при посещении другими людьми. Обновите заголовок Content-Security-Policy-Report-Only чтобы указать ожидаемые домены, чтобы увидеть, когда этот список изменится:
Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control
Почему
Это является частью вашего постоянного технического аудита. В результате первоначального технического аудита вы получите список третьих лиц, которым ваш сайт делится или передает пользовательские данные. Этот заголовок затем приведет к тому, что запросы страниц сообщат, с какими третьими лицами сейчас связываются, и вы сможете отслеживать изменения с течением времени. Это не только предупреждает вас об изменениях, внесенных существующими третьими сторонами, но также помечает вновь добавленных третьих лиц, которые не были добавлены в технический аудит. Важно обновить заголовок, чтобы перестать сообщать о ожидаемых вами доменах, но также важно время от времени повторять ручной технический аудит (поскольку подход Content-Security-Policy не отмечает, какие данные передаются, а только то, что запрос был было сделано.)
Обратите внимание, что его не нужно добавлять к обслуживаемым страницам каждый раз или на каждой странице. Настройте количество ответов на страницы, получающих заголовок, чтобы вы получали репрезентативную выборку отчетов, не слишком большую по количеству.
Политика разрешений
Заголовок Permissions-Policy (который был представлен под названием Feature-Policy ) по своей концепции аналогичен Content-Security-Policy , но он ограничивает доступ к мощным функциям браузера. Например, можно ограничить использование аппаратного обеспечения устройства, такого как акселерометр, камера или USB-устройства, или ограничить неаппаратные функции, такие как разрешение на полноэкранный режим или использование синхронного XMLHTTPRequest . Эти ограничения могут быть применены к странице верхнего уровня (чтобы избежать попыток использования этих функций загруженными скриптами) или к страницам с подфреймом, загруженным через iframe. Это ограничение использования API на самом деле не связано со снятием отпечатков пальцев браузера; речь идет о запрете третьим лицам совершать навязчивые действия (например, использовать мощные API, открывать всплывающие окна разрешений и т. д.). В целевой модели угроз конфиденциальности это определяется как «вторжение» .
Заголовок Permissions-Policy указывается как список пар (функция, разрешенное происхождение), таким образом:
Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*
Этот пример позволяет этой странице («self») и <iframe> из исходного сайта example.com использовать API-интерфейсы navigator.geolocation из JavaScript; он позволяет этой странице и всем подкадрам использовать полноэкранный API и запрещает любой странице, включая эту страницу, использовать камеру для чтения видеоинформации. Гораздо больше деталей и список потенциальных примеров здесь .
Список функций, обрабатываемых заголовком Permissions-Policy, велик и может меняться. В настоящее время список хранится по адресу https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md .
Делать
Браузеры, поддерживающие Permissions-Policy по умолчанию запрещают мощные функции в подкадрах, и вам нужно действовать, чтобы их включить! Этот подход по умолчанию является частным. Если вы обнаружите, что подфреймы на вашем сайте требуют этих разрешений, вы можете выборочно добавить их. Однако по умолчанию к главной странице не применяется политика разрешений, поэтому скрипты (включая сторонние скрипты), загружаемые с главной страницы, не имеют ограничений в попытках использовать эти функции. По этой причине полезно применять ограничительную Permissions-Policy ко всем страницам по умолчанию, а затем постепенно добавлять обратно функции, которые требуются вашим страницам.
Примеры мощных функций, на которые влияет Permissions-Policy включают запрос местоположения пользователя, доступ к датчикам (включая акселерометр, гироскоп и магнитометр), разрешение на полноэкранный режим и запрос доступа к камере и микрофону пользователя. Полный (меняющийся) список функций приведен выше.
К сожалению, блокировка всех функций по умолчанию, а затем выборочное их повторное разрешение требует перечисления всех функций в заголовке, что может показаться довольно неэлегантным. Тем не менее, такой заголовок Permissions-Policy — хорошее начало. Permissionspolicy.com/ имеет удобный кликабельный генератор для создания такого заголовка: использование его для создания заголовка, который отключает все функции, приводит к следующему:
Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()
Понимание встроенных функций конфиденциальности в веб-браузерах
В дополнение к защите «во время сборки» и «времени разработки», существуют также меры защиты конфиденциальности, которые действуют во «время выполнения»: то есть функции конфиденциальности, реализованные в самих браузерах для защиты пользователей. Это не те функции, которые вы можете напрямую контролировать или использовать как разработчик сайта — это функции продукта, — но это функции, о которых вам следует знать, поскольку на ваши сайты могут повлиять эти решения по продуктам в браузерах. Чтобы привести пример того, как эти средства защиты браузера могут повлиять на ваш сайт, если у вас есть клиентский JavaScript, который ожидает загрузки сторонней зависимости, прежде чем продолжить настройку страницы, и эта сторонняя зависимость никогда не загружается вообще, тогда настройка вашей страницы может никогда не завершиться, и пользователю будет представлена наполовину загруженная страница.
Они включают интеллектуальное предотвращение отслеживания в Safari (и базовый движок WebKit) и улучшенную защиту от отслеживания в Firefox (и его движок Gecko). Все это затрудняет создание подробных профилей ваших пользователей третьими лицами.
Подходы браузеров к функциям конфиденциальности часто меняются, и важно оставаться в курсе событий; Следующий список средств защиты верен на момент написания. Браузеры также могут реализовывать другие меры защиты; эти списки не являются исчерпывающими. Ознакомьтесь с модулем по передовым практикам, чтобы узнать, как идти в ногу с изменениями, и обязательно протестируйте будущие версии браузера на предмет изменений, которые могут повлиять на ваши проекты. Имейте в виду, что в режимах инкогнито/приватного просмотра иногда используются настройки, отличные от настроек браузера по умолчанию (например, в таких режимах сторонние файлы cookie могут блокироваться по умолчанию). Таким образом, тестирование в режиме инкогнито не всегда может отражать типичный опыт работы в Интернете большинства пользователей, если они не используют приватный просмотр. Также имейте в виду, что блокировка файлов cookie в различных ситуациях может означать, что другие решения для хранения, такие как window.localStorage , также будут заблокированы, а не только файлы cookie.
Хром
- Сторонние файлы cookie предназначены для блокировки в будущем. На момент написания этой статьи они не заблокированы по умолчанию (но это может включить пользователь): https://support.google.com/chrome/answer/95647 объясняет подробности.
- Функции конфиденциальности Chrome, в частности функции Chrome, которые взаимодействуют с Google и сторонними службами, описаны на сайте Privacysandbox.com/ .
Край
- Сторонние файлы cookie по умолчанию не блокируются (но это может быть включено пользователем).
- Функция предотвращения отслеживания Edge блокирует трекеры на непосещаемых сайтах, а известные вредоносные трекеры блокируются по умолчанию.
Firefox
- Сторонние файлы cookie по умолчанию не блокируются (но это может быть включено пользователем).
- Расширенная защита от отслеживания Firefox по умолчанию блокирует файлы cookie отслеживания, скрипты снятия отпечатков пальцев, скрипты криптомайнеров и известные трекеры. ( https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track предоставляет дополнительную информацию).
- Сторонние файлы cookie ограничены сайтом, поэтому каждый сайт, по сути, имеет отдельную банку файлов cookie и не может коррелировать между сайтами (Mozilla называет это « Полной защитой файлов cookie ».
Чтобы получить представление о том, что может быть заблокировано, и помочь в устранении проблем, щелкните значок щита в адресной строке или посетите страницу about:protections в Firefox (на рабочем столе).
Сафари
- Сторонние файлы cookie по умолчанию блокируются.
- В рамках своей функции интеллектуального предотвращения отслеживания Safari уменьшает реферер, передаваемый на другие страницы, до сайта верхнего уровня, а не конкретной страницы: (
https://something.example.com, а неhttps://something.example.com/this/specific/page). - Данные
localStorageбраузера удаляются через семь дней.
( https://webkit.org/blog/10218/full- Third-party-cookie-blocking-and-more/ суммирует эти функции.)
Чтобы получить некоторое представление о том, что может быть заблокировано, и помочь устранить проблемы, включите «Режим отладки интеллектуального предотвращения отслеживания» в меню разработчика Safari (на рабочем столе). (Подробнее см. https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ .)
Предложения по API
Зачем нам нужны новые API?
Хотя новые функции и политики обеспечения конфиденциальности в браузерных продуктах помогают сохранить конфиденциальность пользователей, они также сопряжены с проблемами. Многие веб-технологии можно использовать для межсайтового отслеживания, несмотря на то, что они разработаны и используются для других целей. Например, многие системы федерации идентификационных данных, которые мы используем каждый день, полагаются на сторонние файлы cookie. Многочисленные рекламные решения, на которые сегодня полагаются издатели для получения дохода, построены на основе сторонних файлов cookie. Многие решения по обнаружению мошенничества основаны на снятии отпечатков пальцев. Что произойдет с этими вариантами использования, когда сторонние файлы cookie и снятие отпечатков пальцев исчезнут?
Браузерам будет сложно и подвержено ошибкам различать варианты использования и надежно отличать способы использования, нарушающие конфиденциальность, от других. Вот почему большинство основных браузеров заблокировали сторонние файлы cookie и снятие отпечатков пальцев или намерены это сделать, чтобы защитить конфиденциальность пользователей.
Необходим новый подход: поскольку сторонние файлы cookie постепенно выводятся из обращения и минимизируется использование отпечатков пальцев, разработчикам нужны специально созданные API, соответствующие сценариям использования (которые никуда не делись), но разработанные с учетом сохранения конфиденциальности. Цель – спроектировать и создать API, которые нельзя использовать для межсайтового отслеживания. В отличие от функций браузера, описанных в предыдущем разделе, эти технологии стремятся стать кроссбраузерными API.
Примеры предложений API
Следующий список не является исчерпывающим — это лишь часть того, что обсуждается.
Примеры предложений API по замене технологий, построенных на сторонних файлах cookie:
- Варианты использования удостоверений: FedCM
- Варианты использования рекламы: измерение частных кликов , совместимая частная атрибуция , отчеты по атрибуции , темы , FLEDGE , PARAKEET .
Примеры предложений API по замене технологий, построенных на пассивном отслеживании:
- Варианты использования для обнаружения мошенничества: токены доверия .
Примеры других предложений, которые другие API могут использовать в будущем без сторонних файлов cookie:
Кроме того, появляется еще один тип предложения API, призванный попытаться смягчить скрытое отслеживание, специфичное для браузера. Одним из примеров является бюджет конфиденциальности . В этих различных вариантах использования API, первоначально предложенные Chrome, действуют под общим термином Privacy Sandbox .
Global-Privacy-Control — это заголовок, который предназначен для сообщения сайту о том, что пользователь не хочет, чтобы любые собранные личные данные были переданы другим сайтам. Его цель аналогична Do Not Track, выпуск которого был прекращен.
Статус предложений API
Большинство этих предложений API еще не развернуты или развертываются только с флагами или в ограниченных средах для экспериментов.
Этот этап публичной инкубации важен: производители и разработчики браузеров собирают обсуждения и опыт того, полезны ли эти API и действительно ли они выполняют то, для чего предназначены. Разработчики, поставщики браузеров и другие участники экосистемы используют этот этап для доработки дизайна API.
Лучшее место, где можно быть в курсе новых предлагаемых API, — это список предложений Privacy Group на Github .
Вам нужно использовать эти API?
Если ваш продукт создан непосредственно на основе сторонних файлов cookie или таких методов, как снятие отпечатков пальцев, вам следует принять участие в работе с этими новыми API, поэкспериментировать с ними и поделиться своим собственным опытом в обсуждениях и разработке API. Во всех остальных случаях вам не обязательно знать все подробности об этих новых API на момент написания, но полезно знать, что будет дальше.