First-Party Sets (FPS) разработан для поддержки пользовательского опыта веб-браузинга после прекращения поддержки сторонних файлов cookie в Chrome. Предложение значительно развилось на форумах открытого веба во время инкубации FPS , сначала в группе сообщества Privacy Community Group консорциума W3C, а теперь в группе сообщества Web Incubator Community Group .
В этой записи блога мы подведем итоги процесса эволюции, выделим ключевые изменения и обсудим, почему мы считаем, что такие изменения улучшают конфиденциальность в Интернете, продолжая при этом поддерживать экосистему.
Фон
Сайты часто полагаются на доступ к своим файлам cookie в стороннем контексте, чтобы предоставлять пользователям бесперебойный и индивидуальный опыт. В дополнение к API-интерфейсам Privacy Preserving Ads (Topics, Protected Audience API и Attribution) команда Chrome стремилась понять масштаб сценариев, в которых использовались сторонние файлы cookie, помимо персонализации рекламы или целей измерения, чтобы предоставить пользователям улучшенные возможности просмотра.
Мы обнаружили, что организации могут полагаться на сторонние файлы cookie, поскольку их веб-архитектура рассчитана на использование нескольких доменов. Например, у организации может быть один домен для блога о походах и другой для магазина товаров для кемпинга, и она хочет поддерживать перемещения пользователей по этим сайтам. Организация может также поддерживать несколько доменов с кодом страны с общей инфраструктурой для своего веб-сервиса. Для таких случаев мы решили создать решение, которое соответствовало бы потребностям таких организаций, сохраняя при этом ожидания пользователей относительно их конфиденциальности в Интернете.
С чего мы начали
Поскольку браузер в настоящее время использует границу на уровне сайта для интерпретации «основной» и «сторонний», чтобы учесть диапазон доменов, которыми может управлять организация, показалось целесообразным заменить эту техническую границу более детализированным определением.
В 2021 году Chrome изначально предложил атрибут cookie SameParty для First-Party Sets, чтобы сайты могли определять файлы cookie, происходящие с сайтов в пределах «одной стороны». Мы использовали политику User-Agent , чтобы определить, что будет составлять «одну сторону». Это определение политики попыталось построить на существующих структурах «стороны» (например, из спецификации W3C DNT ) и включило рекомендации из соответствующего дискурса конфиденциальности (например, отчет Федеральной торговой комиссии 2012 года под названием «Защита конфиденциальности потребителей в эпоху быстрых изменений» ).
В то время мы считали, что такой подход обеспечивает достаточную гибкость для различных типов организаций в разных отраслях, а также соответствует нашей основополагающей цели — минимизации широкомасштабного отслеживания с помощью сторонних файлов cookie.
Отзыв о первоначальном предложении
В ходе многочисленных бесед с заинтересованными сторонами в веб-экосистеме мы обнаружили, что этот первоначальный проект имел свои ограничения.
Проблемы конфиденциальности при пассивном доступе к cookie-файлам через атрибут SameParty
Другие поставщики браузеров предпочли активный подход к доступу к сторонним файлам cookie, требующий явного вызова API, а не установление границы, в пределах которой может поддерживаться пассивный доступ к файлам cookie. Активные запросы на доступ к файлам cookie обеспечивают видимость и контроль браузера, так что риск скрытого отслеживания через сторонние файлы cookie может быть снижен. Кроме того, эта видимость позволит браузерам предоставлять пользователям выбор разрешать или блокировать такой доступ к файлам cookie.
В целях обеспечения веб-совместимости между браузерами, а также повышения конфиденциальности мы решили двигаться в этом направлении.
Проблемы реализации предлагаемой политики
Первоначальная политика предлагала три требования к доменам, которые должны были быть в одном наборе: «общее владение», «общая политика конфиденциальности» и «общая групповая идентичность».
В более широкой экосистеме мы обнаружили, что отзывы, которые мы получили по поводу политики, следуют четырем основным темам.
Общая собственность слишком ограничительна
Что касается требования «общего владения», мы получили обратную связь о том, что определение FPS, которое сосредоточено исключительно на корпоративном владении, даст более крупным компаниям большую возможность объединять данные в широком спектре доменов и пользовательских сервисов по сравнению с более мелкими компаниями. Поскольку наша цель — построить Privacy Sandbox для экосистемы в целом, мы серьезно отнеслись к этой обратной связи и отдали приоритет решению, которое было бы более инклюзивным.
Единая политика ограничивает возможности расширения вариантов использования
Хотя идея целостной политики для управления границей была направлена на обеспечение гибкости для различных типов доменов, которые должны были бы быть в FPS организации, мы обнаружили, что некоторые критические случаи использования не могли соответствовать этой разработке политики. Например, домены служб (например, те, которые размещают пользовательский контент) могут требовать доступ к своим файлам cookie в стороннем контексте для аутентификации или идентификации пользователей. Такие домены редко имеют доступную пользователю домашнюю страницу, поэтому требования «общей групповой идентификации» или «общей политики конфиденциальности» с другими доменами в том же FPS не могли быть выполнены.
Восприятие и понимание пользователями групповой идентичности может различаться
Первоначально мы предложили ограничения для определения «общей групповой идентичности» как попытку ограничить домены в пределах одного набора теми, которые можно было бы легко связать с общей групповой идентичностью. Однако мы не смогли определить технические средства для измерения и оценки того, может ли общая групповая идентичность быть «легко обнаруживаемой пользователями». Это оставило потенциал для злоупотреблений и вопросов о принудительном исполнении.
Мы также получили отзывы о том, что понимание значения границ «общей собственности» может различаться у разных пользователей, что затрудняет создание рекомендаций, которые можно было бы применить ко всем сайтам.
Субъективную политику трудно реализовать в больших масштабах
Мы получили много запросов на более подробные рекомендации, учитывая субъективный характер некоторых требований (например, «общая групповая идентичность»), а также необходимость предусмотреть исключения или пограничные случаи для других ( касательно «общей политики конфиденциальности» ).
Чтобы обеспечить справедливое и последовательное применение политики, Chrome пришлось бы предоставить авторам сайтов гораздо более конкретные указания. Мы определили, что попытка создания более строгих указаний может быть исключительной в ущерб экосистеме.
Хотя изначально мы предлагали, чтобы независимый орган по обеспечению соблюдения взял на себя роль расследования и обеспечения соблюдения политики, в текущей экосистеме поиск независимого органа по обеспечению соблюдения с соответствующим опытом для выполнения этих обязанностей беспристрастным образом был сложной задачей. Вместо этого мы стремились перейти к политике, которую можно было бы технически обеспечить, чтобы гарантировать, что реализация может применяться последовательно и объективно.
Эволюция
В ответ на отзывы мы перепроектировали FPS. Мы вернулись к конкретным проблемам, которые мы пытались решить, и решили более прямо сформулировать предложение вокруг конкретных вариантов использования, которые мы решали.
Решение ключевых вариантов использования
Chrome разработал три различных специально созданных «подмножества» для удовлетворения ключевых вариантов использования в Интернете. Подход подмножеств улучшил старый подход, став более частным, более конкретным и более простым для последовательного применения.
- «ccTLD» (домены верхнего уровня с кодом страны) — организации могут поддерживать сайты с различными ccTLD для локализованного опыта, и этим сайтам по-прежнему может потребоваться доступ к общим сервисам и инфраструктуре.
- «Служебные» домены — сайты могут использовать отдельные домены в целях безопасности или производительности, и этим сайтам может потребоваться доступ к идентификационным данным пользователя для выполнения своих функций.
- «Связанные» домены — организации могут поддерживать несколько сайтов для разных связанных брендов или продуктов. Им может потребоваться межсайтовый доступ к cookie для таких случаев использования, как аналитика пользовательских путешествий по связанным сайтам, чтобы лучше понять, как база пользователей организации взаимодействует с их сайтами, или запомнить состояние входа пользователя на связанном сайте, полагаясь на ту же инфраструктуру входа.
Для каждого из этих вариантов использования существуют отдельные требования политики, соответствующие технические проверки валидности и определенное поведение обработки браузера (узнайте больше в Submission Guidelines ). Эти изменения устраняют ограничения в исходном предложении, отказываясь от дизайна «один размер подходит всем» и отдавая предпочтение раздельной структуре, ориентированной на варианты использования.
Возможность взаимодействия посредством активных запросов на доступ к сторонним файлам cookie
Chrome стремится содействовать взаимодействию с другими браузерами для поддержания работоспособности веб-платформы. Поскольку другие браузеры, такие как Safari, Firefox и Edge, в настоящее время используют Storage Access 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
- First-Party Sets: руководство по интеграции
- Правила подачи FPS
Работа с экосистемой
Приятно видеть, что такие компании, как Salesforce и CafeMedia, участвуют в ключевых отзывах и разработке First-Party Sets. Они сыграли важную роль в продвижении технологии. Несколько других также поделились своими мыслями о First-Party Sets и усилиях Chrome по работе с веб-экосистемой:
«Chrome разрабатывает собственные наборы для соответствия многим нашим вариантам использования, таким как сохранение пути пользователя. Это показывает нам, что команда Google работает над пониманием различных типов потребностей владельцев сайтов по всему Интернету». - Mercado Libre
«В VWO мы ценим усилия Google по повышению стандартов конфиденциальности, гарантируя при этом обработку реальных случаев использования. Замечательно, что команда сотрудничает с экосистемой разработчиков и постоянно совершенствует реализацию предложения по собственным наборам на основе отзывов заинтересованных сторон. Мы рады быть частью процесса тестирования предложения и с нетерпением ждем его внедрения в браузер». — Нитиш Миттал, директор по инжинирингу VWO