Связанные наборы веб-сайтов — новое название собственных наборов в Chrome 117.

Многие API-интерфейсы Privacy Sandbox переходят в общедоступную версию (GA) в стабильной версии Chrome в рамках подготовки к прекращению поддержки сторонних файлов cookie, начиная с 2024 года. Некоторые из этих API-интерфейсов помогут сохранить важные сценарии использования межсайтовых файлов cookie, например CHIPS , и API, который в настоящее время используется. известные как собственные наборы (FPS) . В этом посте мы представляем наборы связанных веб-сайтов (RWS) — наше новое название для FPS, которое лучше отражает его назначение — и даем обновленную информацию об основных вариантах использования, а также обновленную информацию об ограничении связанного подмножества домена.

Сохранение важных пользовательских маршрутов

RWS предназначен для минимизации сбоев в работе определенных функций пользователя, когда Chrome по умолчанию начинает ограничивать доступ к сторонним файлам cookie. Наша цель — позволить пользователям просматривать веб-страницы с минимальными помехами, сохраняя при этом цели конфиденциальности Privacy Sandbox. Чтобы достичь этого баланса, RWS ориентируется на конкретные варианты использования, связанные с функциональностью веб-сайта:

  • Вариант использования ccTLD устраняет неисправности, подобные примеру входа в систему , представленному в нашем общедоступном трекере. Такие случаи часто рассматриваются в экосистеме с помощью исключений на основе эвристики (см. ссылку 1 ).
  • Вариант использования домена службы соответствует общепринятой практике разработчиков по изоляции конфиденциальных функций (например, поддержки потока аутентификации) от доменов, ориентированных на пользователя. Такие случаи могут быть рассмотрены в экосистеме посредством целевых исключений (см. ссылку 2 ).
  • Связанный вариант использования домена обеспечивает большую гибкость для типов доменов, которым может потребоваться доступ к сторонним файлам cookie для критически важных действий пользователя (см. ссылку 3 ). В то время как сценарии использования ccTLD и сервисного домена предусматривают строгие технические проверки, основанные на характеристиках домена, чтобы минимизировать злоупотребления, связанный домен использует числовой предел. Подробнее об этом читайте в следующем разделе.

Лимит связанных доменов увеличен до пяти доменов

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

Мы решили увеличить лимит связанного домена до пяти доменов (плюс один основной домен), что лучше всего соответствует наиболее сопоставимой реализации, предлагаемой другим крупным браузером (см. ссылку 4 ). Это вступит в силу начиная с Chrome 117.

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

У пользователей есть выбор расширенных вариантов использования, помимо пяти связанных доменов.

Для взаимодействия с пользователем, которое не поддерживается этим ограничением, Chrome работает над потоком запросов пользователя , который также использует API доступа к хранилищу (SAA), стандарт, принятый другими браузерами. В случаях использования, требующих более пяти связанных доменов, мы рекомендуем разработчикам оценить, как SAA может поддерживаться в контекстах, отличных от RWS. Мы отдельно следим за процессом запуска Blink для этой функции , которая будет реализована в Chrome Desktop, начиная с Chrome 117.

Следующие шаги

Мы благодарны за отзывы экосистемы, которые на данный момент помогли сформировать API. Мы инвестировали в RWS как в метод, обеспечивающий разработчикам предсказуемость, контроль и свободу действий в сохранении удобства для конечных пользователей создаваемых ими веб-сайтов. Мы рады видеть, как разработчики внедряют и используют RWS по мере нашего расширения. Процесс отправки в настоящее время запущен, и инструмент генератора RWS JSON является отличной отправной точкой для помощи с отправкой.

Следите за веткой «Намерение отправить», чтобы отслеживать прогресс, и ознакомьтесь с этими материалами , чтобы получить рекомендации по реализации.

Рекомендации

  1. В браузерах существует общее мнение, что эти варианты использования межсайтовых файлов cookie необходимы, но они используют разные подходы к их включению. Firefox ( code ) и Safari ( code ) реализовали эвристику всплывающих окон, которая устраняет наблюдаемые нарушения, например, в процессе входа в систему Nintendo .
  2. Есть также несколько примеров, когда браузеры жестко исключают исключения из кода, чтобы минимизировать неудобства для пользователей. Firefox предоставляет доступ к хранилищу при потоках перенаправления между Microsoft Teams и login.microsoftonline.us .
  3. Firefox предоставляет «прокладку», которая будет вызывать requestStorageAccessForOrigin от имени facebook.com, когда пользователь входит в систему на instagram.com. Пример группировки сайтов также можно увидеть в жестко запрограммированных исключениях Safari для группировки запросов на доступ к хранилищу для нескольких доменов.
  4. Firefox автоматически разрешает первые 5 вызовов requestStorageAccess, сделанных сторонним сайтом ( кодом ), который пользователь посещал ранее. В Chrome первые пять доменов, перечисленных в связанном подмножестве, в дополнение к основному домену того же набора, будут иметь автоматический доступ к сторонним файлам cookie через RWS.