Инструкции по тестированию сторонних наборов

Последняя версия собственных наборов готова к тестированию флагов функций разработчиками из Chrome 108. Мы активно работаем над собственными наборами с целью перехода к их поставке, поэтому мы будем учитывать отзывы на этом этапе тестирования разработчиками. до выхода Chrome 111 в начале марта (7 марта 2023 г.).

Отзывы экосистемы выявили случаи межсайтового использования, на которые повлияет прекращение поддержки сторонних файлов cookie в Chrome. Предложение «Первые наборы» рассматривает и рассматривает класс вариантов межсайтового использования, в которых взаимозависимые сайты имеют отношения, которые могут быть выражены браузеру, так что браузер может предпринять соответствующие действия от имени пользователя и/или эффективно представить эту информацию пользователю.

В обновленном предложении используются два API (API доступа к хранилищу и новый API с предварительным названием requestStorageAccessForOrigin ) для предоставления сайтам активного метода запроса межсайтового доступа для их файлов cookie в собственном наборе. Приведенные ниже инструкции позволят вам протестировать и проверить, какие наборы вы можете создать для своих сайтов, а также правильные точки для вызова двух разных API.

Обзор собственных наборов

Первичные наборы (FPS) — это механизм веб-платформы, позволяющий разработчикам объявлять связи между сайтами, чтобы браузеры могли использовать эту информацию для обеспечения ограниченного доступа к межсайтовым файлам cookie для конкретных целей, ориентированных на пользователя. Chrome будет использовать эти заявленные отношения, чтобы решить, когда разрешить или запретить сайту доступ к своим файлам cookie в стороннем контексте.

На высоком уровне собственный набор представляет собой набор доменов, для которых существует один «основной набор» и потенциально несколько «членов набора». Только авторы сайтов могут добавлять свои домены в набор, и они должны будут объявить связь между каждым «членом набора» и его «основным набором». Члены набора могут включать в себя диапазон различных типов доменов с подмножествами в зависимости от вариантов использования .

Чтобы облегчить обработку браузером каждого подмножества в соответствии с последствиями для конфиденциальности каждого подмножества, мы предлагаем использовать API доступа к хранилищу (SAA) и requestStorageAccessForOrigin для включения доступа к файлам cookie в FPS.

Благодаря SAA сайты могут активно запрашивать доступ к межсайтовым файлам cookie. Chrome автоматически удовлетворит запрос, если запрашивающий сайт и веб-сайт верхнего уровня имеют один и тот же FPS. Дополнительную информацию о том, как вызовы SAA обрабатываются другими браузерами, см. в документации по API доступа к хранилищу (SAA) .

В настоящее время SAA требует, чтобы документ получил пользовательскую активацию перед вызовом методов API.

Это может затруднить внедрение FPS для сайтов верхнего уровня, которые используют межсайтовые изображения или теги сценариев, требующие файлов cookie. Чтобы решить некоторые из этих проблем, мы предложили новый API requestStorageAccessForOrigin , чтобы разработчикам было проще принять это изменение. Этот API также доступен для тестирования.

Установить отправку

Канонический список FPS будет общедоступным списком в формате JSON, размещенным в новом репозитории FPS GitHub , который будет служить источником достоверной информации для всех наборов. Chrome будет использовать этот файл, чтобы применить его к своему поведению.

Чтобы узнать больше о предлагаемом процессе и требованиях к отправке наборов, ознакомьтесь с правилами подачи . Вы также можете попробовать отправить набор для проверки различных технических проверок, которые проверят отправленные материалы. Обратите внимание, что все отправленные данные будут удалены до того, как FPS станет доступен в стабильных версиях Chrome.

Поскольку процесс отправки наборов все еще находится в активной разработке, для локального тестирования вы можете создавать наборы только в командной строке и передавать их непосредственно в браузер. Для локального тестирования не требуется отправлять набор в репозиторий GitHub для тестирования с флагами функций.

Как протестировать локально

Предварительные условия

Для локального тестирования FPS используйте Chrome 108 или более поздней версии, запускаемый из командной строки.

Чтобы просмотреть будущие функции Chrome до их выпуска, загрузите бета-версию или Canary- версию Chrome.

Пример

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

Узнайте больше о том, как запустить Chromium с флагами .

Шаги

Чтобы включить FPS локально, вам необходимо использовать параметр Chrome --enable-features со списком флагов, разделенных запятыми, которые описаны в этом разделе, и объявить набор связанных сайтов как объект JSON для передачи --use-first-party-set .

Включить ФПС

FirstPartySets включает FPS в Chrome.

FirstPartySets

Включить API доступа к хранилищу

StorageAccessAPI

Включает API доступа к хранилищу (SAA) в Chrome, который позволяет встроенным iframe использовать requestStorageAccess() для запроса доступа к файлам cookie в межсайтовом контексте, даже если сторонние файлы cookie блокируются браузером.

Обратите внимание, что при вызове requestStorageAccess() для разрешения требуется жест пользователя. Будущие версии Chrome могут предъявлять другие наборы требований, поскольку спецификация SAA все еще развивается. Здесь вы найдете список запланированных улучшений реализации SAA в Chrome.

StorageAccessAPIForOriginExtension

Позволяет сайтам верхнего уровня использовать requestStorageAccessForOrigin() для запроса доступа к хранилищу от имени определенных источников. Это полезно для сайтов верхнего уровня, которые используют межсайтовые изображения или теги сценариев, требующие файлов cookie, и решает некоторые проблемы при внедрении SAA.

Объявить набор локально

Первичный набор — это набор доменов, для которых существует один «основной набор» и потенциально несколько «членов набора». Члены набора могут включать в себя диапазон различных типов доменов с подмножествами в зависимости от вариантов использования .

Создайте объект JSON, содержащий URL-адреса, являющиеся членами набора, и передайте его в --use-first-party-set .

В приведенном ниже примере в поле primary указан основной домен, а associatedSites перечислены домены, соответствующие требованиям связанного подмножества .

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

Пример:

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

Для локального тестирования вы можете создавать наборы только в командной строке и передавать их непосредственно в браузер. Для целей локального тестирования проверка наборов проводиться не будет, но когда FPS будет поставляться в стабильных версиях, все наборы необходимо будет отправить в репозиторий FPS GitHub и подвергнуть критериям проверки.

Включить интерфейс FPS

PageInfoCookiesSubpage

Включает отображение FPS в разделе PageInfo, доступном из строки URL. 

PrivacySandboxFirstPartySetsUI

Включает опцию пользовательского интерфейса FPS «Разрешить связанным сайтам видеть вашу активность в группе» в настройках Chrome в разделе «Конфиденциальность и безопасность» → «Файлы cookie и другие данные сайтов» (chrome://settings/cookies).

Убедитесь, что сторонние файлы cookie заблокированы.

  1. В настройках Chrome перейдите в раздел Конфиденциальность и безопасность → Файлы cookie и другие данные сайта или chrome://settings/cookies.
  2. В разделе «Общие настройки» убедитесь, что включен параметр «Блокировать сторонние файлы cookie».
  3. Убедитесь, что подопция «Разрешить связанным сайтам видеть вашу активность в группе» также включена.

Соображения безопасности

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

Планируемые улучшения

Чтобы улучшить эту ситуацию, в будущих выпусках Chrome потребуются дополнительные меры безопасности с целью обеспечения явного согласия встроенных пользователей. Предлагаемые улучшения будут: предоставлять доступ только для каждого кадра, требовать CORS для запросов с учетными данными и сохранять область доступа только к источнику. Вы можете прочитать больше в недавнем анализе безопасности .

Ознакомьтесь со списком запланированных улучшений реализации SAA в Chrome.

Обратите внимание, что Chrome отправляет файлы cookie с пометкой SameSite=None только во встроенных межсайтовых контекстах, где важен API доступа к хранилищу. Однако до тех пор, пока все браузеры не прекратят доступ по умолчанию к этим файлам cookie, нельзя делать никаких предположений о том, где файлы cookie могут быть использованы. Небезопасно предполагать, что доступ будет разрешен только внутри FPS, и сайтам следует продолжать использовать стандартные передовые методы обеспечения безопасности.

Привлекайте и делитесь отзывами

Локальное тестирование — это возможность опробовать механизм Storage Access API для включения FPS и поделиться отзывами или любыми проблемами, с которыми вы столкнулись. Кроме того, тестирование процесса отправки набора на GitHub — это возможность поделиться своим опытом работы с процессом и этапами проверки. Чтобы привлечь внимание и поделиться отзывами об обновленном предложении: