Первичные наборы (FPS) предназначены для поддержки пользователей при просмотре веб-страниц после прекращения поддержки сторонних файлов cookie в Chrome. Предложение значительно развилось на открытых веб-форумах во время инкубации FPS , сначала в группе сообщества конфиденциальности W3C, а теперь и в группе сообщества веб-инкубатора .
В этом сообщении блога мы подведем итоги процесса эволюции, выделим ключевые изменения и обсудим, почему мы считаем, что такие изменения улучшают конфиденциальность в Интернете, продолжая при этом поддерживать экосистему.
Фон
Сайты часто полагаются на доступ к своим файлам cookie в контексте третьих лиц, чтобы обеспечить пользователям удобный и индивидуальный подход. В дополнение к API-интерфейсам рекламы, сохраняющим конфиденциальность (темы, API защищенной аудитории и атрибуция) , команда Chrome стремилась понять масштаб сценариев, в которых используются сторонние файлы cookie, помимо целей персонализации или измерения рекламы, чтобы обеспечить улучшенные возможности просмотра. для пользователей.
Мы обнаружили, что организации могут полагаться на сторонние файлы cookie, поскольку их веб-архитектура рассчитана на использование нескольких доменов. Например, у организации может быть один домен для блога о походах и другой для магазина кемпинга, и она хочет поддерживать переходы пользователей по этим сайтам. Организация также может поддерживать несколько доменов с кодом страны с общей инфраструктурой для своего веб-сервиса. Для подобных случаев мы намеревались создать решение, соответствующее потребностям таких организаций, сохраняя при этом ожидания пользователей в отношении их конфиденциальности в Интернете.
С чего мы начали
Поскольку в настоящее время браузер использует границу на уровне сайта для интерпретации «собственного» и «стороннего» для учета диапазона доменов, которыми может управлять организация, казалось целесообразным заменить эту техническую границу более детальным определением. .
В 2021 году Chrome первоначально предложил атрибут cookie SameParty для собственных наборов, чтобы сайты могли определять файлы cookie, исходящие от сайтов «одной и той же стороны». Мы использовали политику пользовательского агента , чтобы определить, что будет считаться «одной и той же стороной». В этом определении политики была предпринята попытка опираться на существующие концепции «стороны» (например, из спецификации W3C DNT ) и включить рекомендации из соответствующего дискурса о конфиденциальности (например, отчет Федеральной торговой комиссии 2012 года под названием «Защита конфиденциальности потребителей в эпоху быстрых изменений»). " ).
В то время мы считали, что этот подход обеспечивает достаточную гибкость для различных типов организаций в разных отраслях, а также соответствует нашей основной цели — свести к минимуму широкое распространение отслеживания с помощью сторонних файлов cookie.
Отзыв о первоначальном предложении
В результате многочисленных бесед с заинтересованными сторонами веб-экосистемы мы обнаружили, что этот первоначальный дизайн имел ограничения.
Проблемы конфиденциальности при пассивном доступе к файлам cookie через атрибут SameParty
Другие поставщики браузеров предпочли активный подход к доступу к сторонним файлам cookie, требующий явного вызова API, а не установлению границ, в пределах которых можно было бы поддерживать пассивный доступ к файлам cookie. Активные запросы на доступ к файлам cookie обеспечивают видимость и контроль браузера, что позволяет снизить риск скрытого отслеживания с помощью сторонних файлов cookie. Кроме того, эта видимость позволит браузерам предоставлять пользователям возможность разрешить или заблокировать доступ к таким файлам cookie.
В интересах обеспечения совместимости веб-браузеров, а также улучшения конфиденциальности мы решили двигаться в этом направлении.
Проблемы реализации предлагаемой политики
Первоначальная политика предлагала три требования к доменам, которые должны быть в одном наборе: «общее владение», «общая политика конфиденциальности» и «общая групповая идентичность».
В более широкой экосистеме мы обнаружили, что полученные нами отзывы о политике соответствуют четырем основным темам.
Общая собственность слишком ограничительна
Что касается требования об «общей собственности», мы получили отзывы о том, что определение FPS, ориентированное исключительно на корпоративную собственность, даст более крупным компаниям больше возможностей объединять данные по широкому спектру доменов и услуг, ориентированных на пользователей, по сравнению с меньшими компаниями. Поскольку наша цель — создать «песочницу конфиденциальности» для экосистемы в целом, мы серьезно отнеслись к этому отзыву и отдали предпочтение более инклюзивному решению.
Единая политика ограничивает расширяемость сценариями использования.
Хотя идея целостной политики управления границами была призвана обеспечить гибкость для различных типов доменов, которые должны были присутствовать в FPS организации, мы обнаружили, что некоторые критические варианты использования не могут соответствовать этой политике. Например, домены услуг (например, те, которые размещают пользовательский контент) могут потребовать доступ к своим файлам cookie в стороннем контексте для аутентификации или идентификации пользователей. Такие домены редко имеют домашнюю страницу, доступную пользователю, поэтому требования «общей групповой идентификации» или «общей политики конфиденциальности» с другими доменами в том же FPS не могут быть выполнены.
Восприятие и понимание групповой идентичности пользователями могут различаться.
Первоначально мы предложили ограничения для определения «общей групповой идентичности» как попытку ограничить домены внутри одного набора теми, которые можно легко связать с общей групповой идентичностью. Однако мы не смогли определить технические средства для измерения и оценки того, может ли общая групповая идентичность «легко обнаруживаться пользователями». Это оставило потенциал для злоупотреблений и вопросов о правоприменении.
Мы также получили отзывы о том, что понимание значения границ «общей собственности» может варьироваться от пользователя к пользователю, что затрудняет создание правил, применимых ко всем сайтам.
Субъективную политику трудно проводить в жизнь в больших масштабах.
Мы получили много запросов на более подробные рекомендации, учитывая субъективный характер некоторых требований (например, «общая групповая идентичность») и необходимость охватить исключения или крайние случаи для других ( относительно «общей политики конфиденциальности» ).
Чтобы обеспечить справедливое и последовательное применение политики, Chrome пришлось бы предоставить авторам сайтов гораздо более конкретные рекомендации. Мы определили, что попытки создать более строгие правила могут нанести ущерб экосистеме.
Хотя изначально мы предлагали, чтобы независимый правоохранительный орган взял на себя роль расследования и обеспечения соблюдения политики, в нынешней экосистеме найти независимый правоохранительный орган с соответствующим опытом для беспристрастного выполнения этих обязанностей было непросто. Вместо этого мы стремились перейти к политике, которая могла бы быть технически реализована, чтобы обеспечить последовательное и объективное применение.
Эволюция
В ответ на отзывы мы переработали FPS. Мы вернулись к конкретным проблемам, которые пытались решить, и решили более четко сформулировать предложение вокруг конкретных случаев использования, которые мы решали.
Решение ключевых случаев использования
Chrome разработал три различных специально созданных «подмножества» для удовлетворения ключевых случаев использования в Интернете. Подход на основе подмножеств усовершенствовал старый подход, поскольку он стал более конфиденциальным, более конкретным и его легче последовательно применять.
- «ccTLD» (домены верхнего уровня с кодом страны). Организации могут поддерживать сайты с разными ccTLD для локализованного опыта, и этим сайтам по-прежнему может требоваться доступ к общим службам и инфраструктуре.
- «Служебные» домены. Сайты могут использовать отдельные домены в целях безопасности или производительности, и этим сайтам может потребоваться доступ к личности пользователя для выполнения своих функций.
- «Связанные» домены. Организации могут поддерживать несколько сайтов для разных связанных брендов или продуктов. Им может потребоваться доступ к межсайтовым файлам cookie для таких случаев использования, как анализ перемещений пользователей по связанным сайтам, чтобы лучше понять, как база пользователей организации взаимодействует с их сайтами, или для запоминания состояния входа пользователя на связанный сайт, полагаясь на тот же самый сайт. инфраструктура входа.
Для каждого из этих вариантов использования существуют отдельные требования политики, соответствующие технические проверки и особое поведение браузера (подробнее см. в разделе «Рекомендации по отправке» ). Эти изменения устраняют ограничения исходного предложения, отказываясь от «единого размера, подходящего всем» и отдавая предпочтение разделенной структуре, основанной на сценариях использования.
Возможность взаимодействия посредством активных запросов на доступ к сторонним файлам cookie.
Chrome стремится обеспечить совместимость с другими браузерами для поддержания работоспособности веб-платформы. Поскольку другие браузеры, такие как Safari, Firefox и Edge, в настоящее время используют API доступа к хранилищу (SAA) для облегчения активных запросов файлов cookie, мы решили использовать SAA в Chrome не только для того, чтобы помочь ответить на ключевые отзывы, которые мы получили, но и для поддержки веб-совместимости.
Чтобы обеспечить большую гибкость для разработчиков и устранить известные ограничения SAA, мы также предложили API requestStorageAccessForOrigin .
Возможность использовать Storage Access API и FPS вместе.
При реализации API доступа к хранилищу (SAA) браузеры могут запрашивать разрешение у пользователей напрямую, а другие могут разрешить ограниченное количество запросов без запроса разрешения.
Chrome считает, что FPS может обеспечить прозрачный уровень над SAA, ограничивая взаимодействие с пользователем и предотвращая быстрое утомление в ключевых, ограниченных случаях использования. FPS также предоставляет браузерам возможность предоставлять пользователям дополнительный контекст о членстве в наборе, если они захотят запрашивать у пользователей разрешение.
Благодаря FPS разработчики имеют возможность идентифицировать свои собственные затронутые сайты, которые служат ключевым сценариям использования. Это дает разработчикам возможность предвидеть, как их сайты будут функционировать для пользователей, и принимать меры для ограничения воздействия на взаимодействие с пользователем, используя FPS или альтернативу сторонним файлам cookie. Кроме того, FPS обеспечивает разработчикам предсказуемость платформы, в отличие от эвристики, которая может меняться со временем или приводить к различному поведению разных пользователей.
Наконец, разработчики, реализующие SAA для работы с FPS в Chrome, также смогут использовать SAA для повышения производительности своих сайтов в других браузерах, даже в тех, которые не поддерживают FPS .
Продолжение обсуждения
Мы считаем, что наше последнее предложение обеспечивает правильный баланс в непростой сфере компромиссов, учитывающей потребности пользователей и разработчиков. Мы ценим отзывы заинтересованных сторон веб-экосистемы, которые помогли нам развить предложение FPS.
Мы понимаем, что заинтересованные стороны веб-экосистемы все еще знакомятся с обновленным предложением. Пожалуйста, сотрудничайте с нами, чтобы мы могли продолжать улучшать дизайн таким образом, чтобы это было более полезно для разработчиков, и продолжало улучшать конфиденциальность в Интернете. Google также продолжит сотрудничать с Управлением по конкуренции и рынкам Великобритании (CMA) для обеспечения соблюдения обязательств .
Для участия посетите следующие ресурсы:
- Инкубация в WICG
- Инструкция по тестированию FPS
- Первичные наборы: руководство по интеграции
- Рекомендации по отправке FPS
Работаем с экосистемой
Приятно видеть, что такие компании, как Salesforce и CafeMedia, участвуют в обратной связи и разрабатывают собственные наборы. Они сыграли важную роль в развитии технологий. Несколько других также поделились своими мыслями о собственных наборах и усилиях Chrome по работе с веб-экосистемой:
«Chrome разрабатывает собственные наборы, соответствующие многим нашим сценариям использования, например, сохранению пути пользователя. Это демонстрирует нам, что команда Google работает над пониманием различных типов потребностей владельцев сайтов в Интернете». - Меркадо Либре
«В VWO мы ценим усилия Google по повышению стандартов конфиденциальности, обеспечивая при этом обработку реальных сценариев использования. Замечательно, что команда сотрудничает с экосистемой разработчиков и постоянно совершенствует реализацию предложений сторонних наборов на основе отзывы от заинтересованных сторон в Интернете. Мы рады принять участие в тестировании этого предложения и с нетерпением ждем его включения в браузер». - Нитиш Миттал, технический директор, VWO
,Первичные наборы (FPS) предназначены для поддержки пользователей при просмотре веб-страниц после прекращения поддержки сторонних файлов cookie в Chrome. Предложение значительно развилось на открытых веб-форумах во время инкубации FPS , сначала в группе сообщества конфиденциальности W3C, а теперь и в группе сообщества веб-инкубатора .
В этом сообщении блога мы подведем итоги процесса эволюции, выделим ключевые изменения и обсудим, почему мы считаем, что такие изменения улучшают конфиденциальность в Интернете, продолжая при этом поддерживать экосистему.
Фон
Сайты часто полагаются на доступ к своим файлам cookie в контексте третьих лиц, чтобы обеспечить пользователям удобный и индивидуальный подход. В дополнение к API-интерфейсам рекламы, сохраняющим конфиденциальность (темы, API защищенной аудитории и атрибуция) , команда Chrome стремилась понять масштаб сценариев, в которых используются сторонние файлы cookie, помимо целей персонализации или измерения рекламы, чтобы обеспечить улучшенные возможности просмотра. для пользователей.
Мы обнаружили, что организации могут полагаться на сторонние файлы cookie, поскольку их веб-архитектура рассчитана на использование нескольких доменов. Например, у организации может быть один домен для блога о походах и другой для магазина кемпинга, и она хочет поддерживать переходы пользователей по этим сайтам. Организация также может поддерживать несколько доменов с кодом страны с общей инфраструктурой для своего веб-сервиса. Для подобных случаев мы намеревались создать решение, соответствующее потребностям таких организаций, сохраняя при этом ожидания пользователей в отношении их конфиденциальности в Интернете.
С чего мы начали
Поскольку в настоящее время браузер использует границу на уровне сайта для интерпретации «собственного» и «стороннего» для учета диапазона доменов, которыми может управлять организация, казалось целесообразным заменить эту техническую границу более детальным определением. .
В 2021 году Chrome первоначально предложил атрибут cookie SameParty для собственных наборов, чтобы сайты могли определять файлы cookie, исходящие от сайтов «одной и той же стороны». Мы использовали политику пользовательского агента , чтобы определить, что будет считаться «одной и той же стороной». В этом определении политики была предпринята попытка опираться на существующие концепции «стороны» (например, из спецификации W3C DNT ) и включить рекомендации из соответствующего дискурса о конфиденциальности (например, отчет Федеральной торговой комиссии 2012 года под названием «Защита конфиденциальности потребителей в эпоху быстрых изменений»). " ).
В то время мы считали, что этот подход обеспечивает достаточную гибкость для различных типов организаций в разных отраслях, а также соответствует нашей основной цели — свести к минимуму широкое распространение отслеживания с помощью сторонних файлов cookie.
Отзыв о первоначальном предложении
В результате многочисленных бесед с заинтересованными сторонами веб-экосистемы мы обнаружили, что этот первоначальный дизайн имел ограничения.
Проблемы конфиденциальности при пассивном доступе к файлам cookie через атрибут SameParty
Другие поставщики браузеров предпочли активный подход к доступу к сторонним файлам cookie, требующий явного вызова API, а не установлению границ, в пределах которых можно было бы поддерживать пассивный доступ к файлам cookie. Активные запросы на доступ к файлам cookie обеспечивают видимость и контроль браузера, что позволяет снизить риск скрытого отслеживания с помощью сторонних файлов cookie. Кроме того, эта видимость позволит браузерам предоставлять пользователям возможность разрешить или заблокировать доступ к таким файлам cookie.
В интересах обеспечения совместимости веб-браузеров, а также улучшения конфиденциальности мы решили двигаться в этом направлении.
Проблемы реализации предлагаемой политики
Первоначальная политика предлагала три требования к доменам, которые должны быть в одном наборе: «общее владение», «общая политика конфиденциальности» и «общая групповая идентичность».
В более широкой экосистеме мы обнаружили, что полученные нами отзывы о политике соответствуют четырем основным темам.
Общая собственность слишком ограничительна
Что касается требования об «общей собственности», мы получили отзывы о том, что определение FPS, ориентированное исключительно на корпоративную собственность, даст более крупным компаниям больше возможностей объединять данные по широкому спектру доменов и услуг, ориентированных на пользователей, по сравнению с меньшими компаниями. Поскольку наша цель — создать «песочницу конфиденциальности» для экосистемы в целом, мы серьезно отнеслись к этому отзыву и отдали предпочтение более инклюзивному решению.
Единая политика ограничивает расширяемость сценариями использования.
Хотя идея целостной политики управления границами была призвана обеспечить гибкость для различных типов доменов, которые должны были присутствовать в FPS организации, мы обнаружили, что некоторые критические варианты использования не могут соответствовать этой политике. Например, домены услуг (например, те, которые размещают пользовательский контент) могут потребовать доступ к своим файлам cookie в стороннем контексте для аутентификации или идентификации пользователей. Такие домены редко имеют домашнюю страницу, доступную пользователю, поэтому требования «общей групповой идентификации» или «общей политики конфиденциальности» с другими доменами в том же FPS не могут быть выполнены.
Восприятие и понимание групповой идентичности пользователями могут различаться.
Первоначально мы предложили ограничения для определения «общей групповой идентичности» как попытку ограничить домены внутри одного набора теми, которые можно легко связать с общей групповой идентичностью. Однако мы не смогли определить технические средства для измерения и оценки того, может ли общая групповая идентичность «легко обнаруживаться пользователями». Это оставило потенциал для злоупотреблений и вопросов о правоприменении.
Мы также получили отзывы о том, что понимание значения границ «общей собственности» может варьироваться от пользователя к пользователю, что затрудняет создание правил, применимых ко всем сайтам.
Субъективную политику трудно проводить в жизнь в больших масштабах.
Мы получили много запросов на более подробные рекомендации, учитывая субъективный характер некоторых требований (например, «общая групповая идентичность») и необходимость охватить исключения или крайние случаи для других ( относительно «общей политики конфиденциальности» ).
Чтобы обеспечить справедливое и последовательное применение политики, Chrome пришлось бы предоставить авторам сайтов гораздо более конкретные рекомендации. Мы определили, что попытки создать более строгие правила могут нанести ущерб экосистеме.
Хотя изначально мы предлагали, чтобы независимый правоохранительный орган взял на себя роль расследования и обеспечения соблюдения политики, в нынешней экосистеме найти независимый правоохранительный орган с соответствующим опытом для беспристрастного выполнения этих обязанностей было непросто. Вместо этого мы стремились перейти к политике, которая могла бы быть технически реализована, чтобы обеспечить последовательное и объективное применение.
Эволюция
В ответ на отзывы мы переработали FPS. Мы вернулись к конкретным проблемам, которые пытались решить, и решили более четко сформулировать предложение вокруг конкретных случаев использования, которые мы решали.
Решение ключевых случаев использования
Chrome разработал три различных специально созданных «подмножества» для удовлетворения ключевых случаев использования в Интернете. Подход на основе подмножеств усовершенствовал старый подход, поскольку он стал более конфиденциальным, более конкретным и его легче последовательно применять.
- «ccTLD» (домены верхнего уровня с кодом страны). Организации могут поддерживать сайты с разными ccTLD для локализованного опыта, и этим сайтам по-прежнему может требоваться доступ к общим службам и инфраструктуре.
- «Служебные» домены. Сайты могут использовать отдельные домены в целях безопасности или производительности, и этим сайтам может потребоваться доступ к личности пользователя для выполнения своих функций.
- «Связанные» домены. Организации могут поддерживать несколько сайтов для разных связанных брендов или продуктов. Им может потребоваться доступ к межсайтовым файлам cookie для таких случаев использования, как анализ перемещений пользователей по связанным сайтам, чтобы лучше понять, как база пользователей организации взаимодействует с их сайтами, или для запоминания состояния входа пользователя на связанный сайт, полагаясь на тот же самый сайт. инфраструктура входа.
Для каждого из этих вариантов использования существуют отдельные требования политики, соответствующие технические проверки и особое поведение браузера (подробнее см. в разделе «Рекомендации по отправке» ). Эти изменения устраняют ограничения исходного предложения, отказываясь от «единого размера, подходящего всем» и отдавая предпочтение разделенной структуре, основанной на сценариях использования.
Возможность взаимодействия посредством активных запросов на доступ к сторонним файлам cookie.
Chrome стремится обеспечить совместимость с другими браузерами для поддержания работоспособности веб-платформы. Поскольку другие браузеры, такие как Safari, Firefox и Edge, в настоящее время используют API доступа к хранилищу (SAA) для облегчения активных запросов файлов cookie, мы решили использовать SAA в Chrome не только для того, чтобы помочь ответить на ключевые отзывы, которые мы получили, но и для поддержки веб-совместимости.
Чтобы обеспечить большую гибкость для разработчиков и устранить известные ограничения SAA, мы также предложили API requestStorageAccessForOrigin .
Возможность использовать Storage Access API и FPS вместе.
При реализации API доступа к хранилищу (SAA) браузеры могут запрашивать разрешение у пользователей напрямую, а другие могут разрешить ограниченное количество запросов без запроса разрешения.
Chrome считает, что FPS может обеспечить прозрачный уровень над SAA, ограничивая взаимодействие с пользователем и предотвращая быстрое утомление в ключевых, ограниченных случаях использования. FPS также предоставляет браузерам возможность предоставлять пользователям дополнительный контекст о членстве в наборе, если они захотят запрашивать у пользователей разрешение.
Благодаря FPS разработчики имеют возможность идентифицировать свои собственные затронутые сайты, которые служат ключевым сценариям использования. Это дает разработчикам возможность предвидеть, как их сайты будут функционировать для пользователей, и принимать меры для ограничения воздействия на взаимодействие с пользователем, используя FPS или альтернативу сторонним файлам cookie. Кроме того, FPS обеспечивает разработчикам предсказуемость платформы, в отличие от эвристики, которая может меняться со временем или приводить к различному поведению разных пользователей.
Наконец, разработчики, реализующие SAA для работы с FPS в Chrome, также смогут использовать SAA для повышения производительности своих сайтов в других браузерах, даже в тех, которые не поддерживают FPS .
Продолжение обсуждения
Мы считаем, что наше последнее предложение обеспечивает правильный баланс в непростой сфере компромиссов, учитывающей потребности пользователей и разработчиков. Мы ценим отзывы заинтересованных сторон веб-экосистемы, которые помогли нам развить предложение FPS.
Мы понимаем, что заинтересованные стороны веб-экосистемы все еще знакомятся с обновленным предложением. Пожалуйста, сотрудничайте с нами, чтобы мы могли продолжать улучшать дизайн таким образом, чтобы это было более полезно для разработчиков, и продолжало улучшать конфиденциальность в Интернете. Google также продолжит сотрудничать с Управлением по конкуренции и рынкам Великобритании (CMA) для обеспечения соблюдения обязательств .
Для участия посетите следующие ресурсы:
- Инкубация в WICG
- Инструкция по тестированию FPS
- Первичные наборы: руководство по интеграции
- Рекомендации по отправке FPS
Работаем с экосистемой
Приятно видеть, что такие компании, как Salesforce и CafeMedia, участвуют в обратной связи и разрабатывают собственные наборы. Они сыграли важную роль в развитии технологий. Несколько других также поделились своими мыслями о собственных наборах и усилиях Chrome по работе с веб-экосистемой:
«Chrome разрабатывает собственные наборы, соответствующие многим нашим сценариям использования, например, сохранению пути пользователя. Это демонстрирует нам, что команда Google работает над пониманием различных типов потребностей владельцев сайтов в Интернете». - Меркадо Либре
«В VWO мы ценим усилия Google по повышению стандартов конфиденциальности, обеспечивая при этом обработку реальных сценариев использования. Замечательно, что команда сотрудничает с экосистемой разработчиков и постоянно совершенствует реализацию предложений сторонних наборов на основе отзывы от заинтересованных сторон в Интернете. Мы рады принять участие в тестировании этого предложения и с нетерпением ждем его включения в браузер». - Нитиш Миттал, технический директор, VWO
,Первичные наборы (FPS) предназначены для поддержки пользователей при просмотре веб-страниц после прекращения поддержки сторонних файлов cookie в Chrome. Предложение значительно развилось на открытых веб-форумах во время инкубации FPS , сначала в группе сообщества конфиденциальности W3C, а теперь и в группе сообщества веб-инкубатора .
В этом сообщении блога мы подведем итоги процесса эволюции, выделим ключевые изменения и обсудим, почему мы считаем, что такие изменения улучшают конфиденциальность в Интернете, продолжая при этом поддерживать экосистему.
Фон
Сайты часто полагаются на доступ к своим файлам cookie в контексте третьих лиц, чтобы обеспечить пользователям удобный и индивидуальный подход. В дополнение к API-интерфейсам рекламы, сохраняющим конфиденциальность (темы, API защищенной аудитории и атрибуция) , команда Chrome стремилась понять масштаб сценариев, в которых используются сторонние файлы cookie, помимо целей персонализации или измерения рекламы, чтобы обеспечить улучшенные возможности просмотра. для пользователей.
Мы обнаружили, что организации могут полагаться на сторонние файлы cookie, поскольку их веб-архитектура рассчитана на использование нескольких доменов. Например, у организации может быть один домен для блога о походах и другой для магазина кемпинга, и она хочет поддерживать переходы пользователей по этим сайтам. Организация также может поддерживать несколько доменов с кодом страны с общей инфраструктурой для своего веб-сервиса. Для подобных случаев мы намеревались создать решение, соответствующее потребностям таких организаций, сохраняя при этом ожидания пользователей в отношении их конфиденциальности в Интернете.
С чего мы начали
Поскольку в настоящее время браузер использует границу на уровне сайта для интерпретации «собственного» и «стороннего» для учета диапазона доменов, которыми может управлять организация, казалось целесообразным заменить эту техническую границу более детальным определением. .
В 2021 году Chrome первоначально предложил атрибут cookie SameParty для собственных наборов, чтобы сайты могли определять файлы cookie, исходящие от сайтов «одной и той же стороны». Мы использовали политику пользовательского агента , чтобы определить, что будет считаться «одной и той же стороной». В этом определении политики была предпринята попытка опираться на существующие концепции «стороны» (например, из спецификации W3C DNT ) и включить рекомендации из соответствующего дискурса о конфиденциальности (например, отчет Федеральной торговой комиссии 2012 года под названием «Защита конфиденциальности потребителей в эпоху быстрых изменений»). " ).
В то время мы считали, что этот подход обеспечивает достаточную гибкость для различных типов организаций в разных отраслях, а также соответствует нашей основной цели — свести к минимуму широкое распространение отслеживания с помощью сторонних файлов cookie.
Отзыв о первоначальном предложении
В результате многочисленных бесед с заинтересованными сторонами веб-экосистемы мы обнаружили, что этот первоначальный дизайн имел ограничения.
Проблемы конфиденциальности при пассивном доступе к файлам cookie через атрибут SameParty
Другие поставщики браузеров предпочли активный подход к доступу к сторонним файлам cookie, требующий явного вызова API, а не установлению границ, в пределах которых можно было бы поддерживать пассивный доступ к файлам cookie. Активные запросы на доступ к файлам cookie обеспечивают видимость и контроль браузера, что позволяет снизить риск скрытого отслеживания с помощью сторонних файлов cookie. Кроме того, эта видимость позволит браузерам предоставлять пользователям возможность разрешить или заблокировать доступ к таким файлам cookie.
В интересах обеспечения совместимости веб-браузеров, а также улучшения конфиденциальности мы решили двигаться в этом направлении.
Проблемы реализации предлагаемой политики
Первоначальная политика предлагала три требования к доменам, которые должны быть в одном наборе: «общее владение», «общая политика конфиденциальности» и «общая групповая идентичность».
В более широкой экосистеме мы обнаружили, что полученные нами отзывы о политике соответствуют четырем основным темам.
Общая собственность слишком ограничительна
Что касается требования об «общей собственности», мы получили отзывы о том, что определение FPS, ориентированное исключительно на корпоративную собственность, даст более крупным компаниям больше возможностей объединять данные по широкому спектру доменов и услуг, ориентированных на пользователей, по сравнению с меньшими компаниями. Поскольку наша цель — создать «песочницу конфиденциальности» для экосистемы в целом, мы серьезно отнеслись к этому отзыву и отдали предпочтение более инклюзивному решению.
Единая политика ограничивает расширяемость сценариями использования.
Хотя идея целостной политики управления границами была призвана обеспечить гибкость для различных типов доменов, которые должны были присутствовать в FPS организации, мы обнаружили, что некоторые критические варианты использования не могут соответствовать этой политике. Например, домены услуг (например, те, которые размещают пользовательский контент) могут потребовать доступ к своим файлам cookie в стороннем контексте для аутентификации или идентификации пользователей. Такие домены редко имеют домашнюю страницу, доступную пользователю, поэтому требования «общей групповой идентификации» или «общей политики конфиденциальности» с другими доменами в том же FPS не могут быть выполнены.
Восприятие и понимание групповой идентичности пользователями могут различаться.
Первоначально мы предложили ограничения для определения «общей групповой идентичности» как попытку ограничить домены внутри одного набора теми, которые можно легко связать с общей групповой идентичностью. Однако мы не смогли определить технические средства для измерения и оценки того, может ли общая групповая идентичность «легко обнаруживаться пользователями». Это оставило потенциал для злоупотреблений и вопросов о правоприменении.
Мы также получили отзывы о том, что понимание значения границ «общей собственности» может варьироваться от пользователя к пользователю, что затрудняет создание правил, применимых ко всем сайтам.
Субъективную политику трудно проводить в жизнь в больших масштабах.
Мы получили много запросов на более подробные рекомендации, учитывая субъективный характер некоторых требований (например, «общая групповая идентичность») и необходимость охватить исключения или крайние случаи для других ( относительно «общей политики конфиденциальности» ).
Чтобы обеспечить справедливое и последовательное применение политики, Chrome пришлось бы предоставить авторам сайтов гораздо более конкретные рекомендации. Мы определили, что попытки создать более строгие правила могут нанести ущерб экосистеме.
Хотя изначально мы предлагали, чтобы независимый правоохранительный орган взял на себя роль расследования и обеспечения соблюдения политики, в нынешней экосистеме найти независимый правоохранительный орган с соответствующим опытом для беспристрастного выполнения этих обязанностей было непросто. Вместо этого мы стремились перейти к политике, которая могла бы быть технически реализована, чтобы обеспечить последовательное и объективное применение.
Эволюция
В ответ на отзывы мы переработали FPS. Мы вернулись к конкретным проблемам, которые пытались решить, и решили более четко сформулировать предложение вокруг конкретных случаев использования, которые мы решали.
Решение ключевых случаев использования
Chrome разработал три различных специально созданных «подмножества» для удовлетворения ключевых случаев использования в Интернете. Подход на основе подмножеств усовершенствовал старый подход, поскольку он стал более конфиденциальным, более конкретным и его легче последовательно применять.
- «ccTLD» (домены верхнего уровня с кодом страны). Организации могут поддерживать сайты с разными ccTLD для локализованного опыта, и этим сайтам по-прежнему может требоваться доступ к общим службам и инфраструктуре.
- «Служебные» домены. Сайты могут использовать отдельные домены в целях безопасности или производительности, и этим сайтам может потребоваться доступ к личности пользователя для выполнения своих функций.
- «Связанные» домены. Организации могут поддерживать несколько сайтов для разных связанных брендов или продуктов. Им может потребоваться доступ к межсайтовым файлам cookie для таких случаев использования, как анализ перемещений пользователей по связанным сайтам, чтобы лучше понять, как база пользователей организации взаимодействует с их сайтами, или для запоминания состояния входа пользователя на связанный сайт, полагаясь на тот же самый сайт. инфраструктура входа.
Для каждого из этих вариантов использования существуют отдельные требования политики, соответствующие технические проверки и особое поведение браузера (подробнее см. в разделе «Рекомендации по отправке» ). Эти изменения устраняют ограничения исходного предложения, отказываясь от «единого размера, подходящего всем» и отдавая предпочтение разделенной структуре, основанной на сценариях использования.
Возможность взаимодействия посредством активных запросов на доступ к сторонним файлам cookie.
Chrome стремится обеспечить совместимость с другими браузерами для поддержания работоспособности веб-платформы. Поскольку другие браузеры, такие как Safari, Firefox и Edge, в настоящее время используют API доступа к хранилищу (SAA) для облегчения активных запросов файлов cookie, мы решили использовать SAA в Chrome не только для того, чтобы помочь ответить на ключевые отзывы, которые мы получили, но и для поддержки веб-совместимости.
Чтобы обеспечить большую гибкость для разработчиков и устранить известные ограничения SAA, мы также предложили API requestStorageAccessForOrigin .
Возможность использовать Storage Access API и FPS вместе.
При реализации API доступа к хранилищу (SAA) браузеры могут запрашивать разрешение у пользователей напрямую, а другие могут разрешить ограниченное количество запросов без запроса разрешения.
Chrome считает, что FPS может обеспечить прозрачный уровень над SAA, ограничивая взаимодействие с пользователем и предотвращая быстрое утомление в ключевых, ограниченных случаях использования. FPS также предоставляет браузерам возможность предоставлять пользователям дополнительный контекст о членстве в наборе, если они захотят запрашивать у пользователей разрешение.
Благодаря FPS разработчики имеют возможность идентифицировать свои собственные затронутые сайты, которые служат ключевым сценариям использования. Это дает разработчикам возможность предвидеть, как их сайты будут функционировать для пользователей, и принимать меры для ограничения воздействия на взаимодействие с пользователем, используя FPS или альтернативу сторонним файлам cookie. Кроме того, FPS обеспечивает разработчикам предсказуемость платформы, в отличие от эвристики, которая может меняться со временем или приводить к различному поведению разных пользователей.
Наконец, разработчики, реализующие SAA для работы с FPS в Chrome, также смогут использовать SAA для повышения производительности своих сайтов в других браузерах, даже в тех, которые не поддерживают FPS .
Продолжение обсуждения
Мы считаем, что наше последнее предложение обеспечивает правильный баланс в непростой сфере компромиссов, учитывающей потребности пользователей и разработчиков. Мы ценим отзывы заинтересованных сторон веб-экосистемы, которые помогли нам развить предложение FPS.
Мы понимаем, что заинтересованные стороны веб-экосистемы все еще знакомятся с обновленным предложением. Пожалуйста, сотрудничайте с нами, чтобы мы могли продолжать улучшать дизайн таким образом, чтобы это было более полезно для разработчиков, и продолжало улучшать конфиденциальность в Интернете. Google также продолжит сотрудничать с Управлением по конкуренции и рынкам Великобритании (CMA) для обеспечения соблюдения обязательств .
Для участия посетите следующие ресурсы:
- Инкубация в WICG
- Инструкция по тестированию FPS
- Первичные наборы: руководство по интеграции
- Рекомендации по отправке FPS
Работаем с экосистемой
Приятно видеть, что такие компании, как Salesforce и CafeMedia, участвуют в обратной связи и разрабатывают собственные наборы. Они сыграли важную роль в развитии технологий. Несколько других также поделились своими мыслями о собственных наборах и усилиях Chrome по работе с веб-экосистемой:
«Chrome разрабатывает собственные наборы, соответствующие многим нашим сценариям использования, например, сохранению пути пользователя. Это демонстрирует нам, что команда Google работает над пониманием различных типов потребностей владельцев сайтов в Интернете». - Меркадо Либре
«В VWO мы ценим усилия Google по повышению стандартов конфиденциальности, обеспечивая при этом обработку реальных сценариев использования. Замечательно, что команда сотрудничает с экосистемой разработчиков и постоянно совершенствует реализацию предложений сторонних наборов на основе отзывы от заинтересованных сторон в Интернете. Мы рады принять участие в тестировании этого предложения и с нетерпением ждем его включения в браузер». - Нитиш Миттал, технический директор, VWO