Что такое третья сторона?
Довольно редко веб-сайт является полностью автономным. Веб-альманах 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-файл для конкретной страницы, выполните следующие действия:
Хром
Откройте инструменты разработчика браузера ( Меню > Дополнительные инструменты > Инструменты разработчика ), перейдите на панель «Сеть», загрузите (или обновите) страницу и выберите символ сохранения со стрелкой вниз в правом верхнем углу рядом с раскрывающимся меню «Без регулирования».
Fire Fox
Откройте инструменты разработчика браузера ( Меню > Дополнительные инструменты > Инструменты веб-разработчика ), перейдите на панель «Сеть», загрузите (или обновите) страницу и выберите символ шестеренки в правом верхнем углу рядом с раскрывающимся меню регулирования. В его меню выберите «Сохранить все как 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 имеет ряд функций конфиденциальности OPT-In (следовательно, по умолчанию) , многие из которых могут быть полезны для соблюдения локальных законов о защите данных. Некоторые параметры, которые следует учитывать при настройке Google Analytics, включают в себя установку периода хранения на собранных данных (ADMIN> Информация о отслеживании> Хранение данных) ниже, чем 26-месячный дефолт, и включение некоторых из более технических решений, таких как частичная IP-анонимность (см. HTTPS : //support.google.com/analytics/answer/9019185 для более подробной информации).
Использование третьих лиц по конфиденциальности
До сих пор мы обсуждали, как защитить ваших пользователей от третьих лиц на этапе проектирования вашего приложения, в то время как вы планируете, что это приложение будет делать. Решение не использовать конкретную третью сторону вообще является частью этого планирования, и аудит вашего использования также подходит в эту категорию: речь идет о принятии решений о вашей позиции конфиденциальности. Однако эти решения по своей природе не очень детализируют; Выбор использования конкретной третьей стороны или выбора не является тонким решением. В гораздо более вероятно, что вам захочется что-то между ними: нужно или планировать использовать конкретное стороннее предложение, но смягчить любые тенденции, обладающие конфиденциальностью, (будь то преднамеренные или случайные). Это задача защиты пользователей в «Time Build»: добавление гарантий, чтобы уменьшить вред, который вы не ожидали. Все это новые заголовки HTTP, которые вы можете предоставить при обслуживании страниц и которые будут намекать или командовать пользовательским агентом, чтобы он занял определенную конфиденциальность или позиции безопасности.
Рефератель-политика
Делать
Установите политику strict-origin-when-cross-origin или noreferrer , чтобы предотвратить получение заголовка реферала, когда вы ссылаетесь на них или когда они загружаются как подреставники на странице:
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'}));
При необходимости установите политику Laxer по конкретным элементам или запросам.
Почему это защищает конфиденциальность пользователей
По умолчанию каждый http -запрос, который браузер делает пропуски на заголовке Referer , который содержит URL -адрес страницы, инициирующий запрос, будь то ссылка, встроенное изображение или сценарий. Это может быть проблемой конфиденциальности, потому что URL -адреса могут содержать частную информацию, и эти URL -адреса, доступные третьим лицам, передают им эту личную информацию. Web.dev перечисляет несколько примеров URL -адресов, содержащих частные данные - зная, что пользователь пришел на ваш сайт с https://social.example.com/user/me@example.com сообщает вам, кто этот пользователь, что является определенной утечкой . Но даже URL -адрес, который сам по себе не раскрывает личную информацию, показывает, что этот конкретный пользователь (которого вы, возможно, знаете, если он вошел в систему), пришел сюда с другого сайта, и поэтому это показывает, что этот пользователь посетил этот другой сайт. Это само по себе, предоставляя информацию, которую вы, возможно, не должны знать об истории просмотра вашего пользователя.
Предоставление заголовка Referrer-Policy (с правильным написанием!) Позволяет изменить это, так что какой-то или ни один из ссылочных URL-адресов передается. MDN перечисляет полную информацию, но большинство браузеров в настоящее время по умолчанию приняли https://web.dev ценность strict-origin-when-cross-origin Вместо 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», диктует, откуда можно загрузить внешние ресурсы. Он используется в первую очередь для целей безопасности, предотвращая атаки сценариев поперечного сайта и впрыскивание сценариев, но при использовании вместе с вашими обычными аудитами это также может ограничивать, где выбранные вами третьи стороны могут передавать данные.
Это потенциально менее чем здоровый пользовательский опыт; Если один из ваших сторонних сценариев начнет загружать зависимость из происхождения, не в вашем списке, то этот запрос будет заблокирован, сценарий потерпит неудачу, и ваше приложение может свести в срок (или, по крайней мере. запасная версия). Это полезно, когда CSP реализован для безопасности, которая является его обычной целью: защита от проблем с перекрестными сценариями (и для этого, используйте строгий CSP ). После того, как вы узнаете все встроенные сценарии, которые использует ваша страница, вы можете составить их список, рассчитать значение хэш -значения или добавить случайное значение (называемое «nonce») для каждого, а затем добавьте список хеш в безопасность вашего контента Политика. Это предотвратит любой сценарий, который нет в списке, загружается. Это должно быть выпечено в производственном процессе для сайта: сценарии на ваших страницах должны включать в себя 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, выявление Windows разрешений и т. Д.). Это определяется целевой моделью угроз конфиденциальности как «вторжение» .
Заголовок Permissions-Policy указан в виде списка (функции, разрешенных источников), таким образом:
Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*
Этот пример позволяет этой странице ("self") и <iframe> s из Origin example.com использовать API navigator.geolocation из JavaScript; Это позволяет этой странице и всем подфрам использовать API полноэкранного API, и запрещает любую страницу, включенную эту страницу, от использования камеры для чтения видео информации. Здесь гораздо больше подробно и список потенциальных примеров .
Список функций, которые обрабатываются заголовком разрешений-политики, большой и может быть в движении. В настоящее время этот список поддерживается по адресу 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.
Хром
- Сторонние печенья предназначены для блокировки в будущем. На момент написания написания они не заблокированы по умолчанию (но это может быть включено пользователем): https://support.google.com/chrome/answer/95647 объясняет детали.
- Функции конфиденциальности Chrome, и, в частности, функции Chrome, которые общаются с Google и сторонними услугами, описаны на PrivacysAndbox.com/ .
Край
- Сторонние файлы cookie не заблокированы по умолчанию (но пользователь может быть включен).
- Профилактика отслеживания Edge, отслеживающие блоки, от не посещаемых сайтов и известных вредных трекеров блокируются по умолчанию.
Fire Fox
- Сторонние файлы cookie не заблокированы по умолчанию (но пользователь может быть включен).
- Усовершенствованные блоки защиты от Firefox по умолчанию по умолчанию печенья, сценарии отпечатков пальцев, сценарии криптоминера и известные трекеры. ( https://support.mozilla.org/kb/trackers-and-scripts-firefox-clocks-enhanced-track предоставляет более подробную информацию).
- Сторонние печенья ограничены на участке, поэтому каждый сайт по сути имеет отдельную банку с печеньем и не может быть связан между сайтами (Mozilla называет эту « полную защиту печенья ».
Чтобы получить некоторое представление о том, что может быть заблокировано, и для того, чтобы помочь отладки, щелкните значок Shield в адресной панели или посетите 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 вытекают и смягчаются снятием спечатков пальцев, разработчикам нужны специально построенные API, которые соответствуют вариантам использования (которые не ушли), но разработаны в конфиденциальности. Цель состоит в том, чтобы спроектировать и построить API, которые нельзя использовать для перекрестного отслеживания. В отличие от особенностей браузера, описанных в предыдущем разделе, эти технологии стремятся стать API-интерфейсом междона.
Примеры предложений API
Следующий список не является всеобъемлющим - это аромат некоторых из того, что обсуждается.
Примеры предложений API для замены технологий, построенных на сторонних печеньях:
- Примеры использования личности: FEDCM
- Акции использования рекламы: частное измерение клика , совместимая личная атрибуция , отчет о атрибуции , темы , окантовка , попугай .
Примеры предложений API для замены технологий, построенных на пассивном отслеживании:
- Примеры использования мошенничества: токены доверия .
Примеры других предложений, которые другие API могут построить в будущем без сторонних печеньев:
Кроме того, появляется еще один тип предложения API, чтобы попытаться иметь смягчения смягчения в браузере, специфичных для браузера. Одним из примеров является бюджет конфиденциальности . В этих различных вариантах использования API, которые первоначально были предложены Chrome Live под зонтичным термином песочницей конфиденциальности .
Global-Privacy-Control -это заголовок, который намеревается сообщить на сайт, который пользователь хотел бы, чтобы любые собранные персональные данные не были переданы на другие сайты. Его намерение похоже на то, чтобы не отслеживать, что было прекращено.
Статус предложений API
Большинство из этих предложений API еще не развернуты или развернуты только за флагами или в ограниченных средах для экспериментов.
Эта публичная инкубационная фаза важна: поставщики и разработчики браузеров собирают обсуждение и опыт работы с тем, полезны ли эти API и делают ли они на самом деле то, для чего они разработаны. Разработчики, поставщики браузеров и другие участники экосистемы используют этот этап для итерации по дизайну API.
Лучшее место, чтобы не отставать от предлагаемых новых API, в настоящее время - это список предложений группы конфиденциальности на GitHub .
Вам нужно использовать эти API?
Если ваш продукт напрямую построен в верхней части сторонних файлов cookie или таких методов, как снятие отпечатков пальцев, вы должны принять участие в этих новых API, экспериментировать с ними и внести свой собственный опыт в дискуссии и дизайн API. Во всех других случаях вам не обязательно нужно знать все детали этих новых API на момент написания, но хорошо знать, что будет.