Многие организации имеют связанные сайты с разными доменными именами, например brandx.site
и fly-brandx.site
, или доменами для разных стран, например example.com
, example.rs
, example.co.uk
и т. д.
Браузеры стремятся сделать сторонние файлы cookie устаревшими, чтобы улучшить конфиденциальность в Интернете, но сайты, подобные этим, часто полагаются на файлы cookie для функций, требующих поддержания и доступа к состоянию в разных доменах (например, единого входа и управления согласием).
![](https://developers.google.com/static/privacy-sandbox/assets/images/blog/JNtmMZl7o44LwUk7mE5G.png?hl=ru)
Первичные наборы могут позволить рассматривать связанные доменные имена, которые принадлежат и управляются одной и той же организацией, как собственные в ситуациях, когда первая и третья стороны в противном случае рассматриваются по-разному. Доменные имена в собственном наборе считаются односторонними и могут указывать, какие файлы cookie предназначены для установки или отправки в одностороннем контексте. Цель состоит в том, чтобы найти баланс между предотвращением межсайтового отслеживания третьими сторонами и сохранением пути, который не нарушает допустимые варианты использования.
Предложение «Собственные наборы» в настоящее время находится на этапе тестирования . Читайте дальше, чтобы узнать, как оно работает и как его можно опробовать.
В чем разница между основными и сторонними файлами cookie?
Файлы cookie по своей сути не являются собственными или сторонними; это зависит от текущего контекста, в который включен файл cookie. Это либо по запросу в заголовке cookie
, либо через document.cookie
в JavaScript.
Если, например, у video.site
есть файл cookie theme=dark
, когда вы просматриваете video.site
и делаете запрос к video.site
, это контекст того же сайта , а включенный файл cookie является основным .
Однако, если вы находитесь на my-blog.site
, в котором встроен проигрыватель iframe для video.site
, когда запрос делается с my-blog.site
на video.site
, это межсайтовый контекст, а файл cookie theme
является сторонним. .
![Диаграмма, показывающая файл cookie с сайта video.site в двух контекстах. Файл cookie относится к тому же сайту, если контекст верхнего уровня также является video.site. Файл cookie является межсайтовым, если контекстом верхнего уровня является my-blog.site с video.site в iframe.](https://developers.google.com/static/privacy-sandbox/assets/images/blog/diagram-showing-cookie-dfe8e53e69db5.png?hl=ru)
Включение файлов cookie определяется атрибутом SameSite
файла cookie:
- Контекст того же сайта с
SameSite=Lax
,Strict
илиNone
делает файл cookie основным . - Межсайтовый контекст с
SameSite=None
делает файл cookie сторонним .
Однако не всегда все так однозначно. Представьте себе, что brandx.site
— это сайт бронирования путешествий, и они также используют fly-brandx.site
и drive-brandx.site
для разделения рейсов и аренды автомобилей. В ходе бронирования одной поездки посетители перемещаются между этими сайтами, чтобы выбрать различные варианты — они ожидают, что их «корзина» с выбором сохранится на всех этих сайтах. brandx.site
управляет сеансом пользователя с помощью файла cookie SameSite=None
чтобы разрешить его в межсайтовом контексте. Обратной стороной является то, что теперь файл cookie не имеет защиты от подделки межсайтовых запросов (CSRF). Если evil.site
включает запрос к brandx.site
, то он будет включать и этот файл cookie!
Файл cookie является межсайтовым, но все эти сайты принадлежат и управляются одной и той же организацией. Посетители также понимают, что это одна и та же организация, и хотят одного и того же сеанса, другими словами, — общей идентичности для всех.
![Диаграмма, показывающая, как файл cookie может быть включен в межсайтовый контекст, если сайты входят в один и тот же собственный набор, но будет отклонен для межсайтовых контекстов за пределами набора.](https://developers.google.com/static/privacy-sandbox/assets/images/blog/diagram-showing-a-cookie-f72b9dd07e136.png?hl=ru)
Политика в отношении собственных наборов
First-Party Sets предлагает метод явного определения этих отношений между несколькими сайтами, которые принадлежат и управляются одной и той же стороной . Это позволит brandx.site
определить свои собственные отношения с fly-brandx.site
, drive-brandx.site
и т. д.
Модель конфиденциальности , лежащая в основе различных предложений Privacy Sandbox, основана на концепции разделения личности для предотвращения межсайтового отслеживания — прорисовке границы между сайтами, которая ограничивает доступ к любой информации, которая может использоваться для идентификации пользователей.
![Диаграмма, показывающая несекционированное состояние, когда один и тот же сторонний файл cookie доступен в нескольких межсайтовых контекстах, в отличие от разделенной модели, где каждый контекст верхнего уровня имеет отдельный экземпляр межсайтового файла cookie, предотвращающий связывание действий между этими сайтами.](https://developers.google.com/static/privacy-sandbox/assets/images/blog/diagram-showing-unpartit-d586a384ed41c.png?hl=ru)
Хотя параметром по умолчанию является разделение по сайтам, что решает многие случаи использования собственных сайтов, пример brandx.site
показывает, что собственный сайт может быть больше, чем один сайт.
![Диаграмма, показывающая, как один и тот же экземпляр файла cookie для одного набора может быть включен в межсайтовый контекст, когда все эти сайты являются частью одного и того же набора.](https://developers.google.com/static/privacy-sandbox/assets/images/blog/diagram-showing-the-same-732d9ccccf6ca.png?hl=ru)
Важной частью предложения по собственным наборам является обеспечение того, чтобы политика всех браузеров предотвращала злоупотребления или неправильное использование. Например, собственные наборы не должны обеспечивать обмен пользовательской информацией между несвязанными сайтами или группировку сайтов, не принадлежащих одной и той же организации. Идея состоит в том, чтобы гарантировать, что First-Party Set сопоставляется с чем-то, что человек понимает как «первый участник», и не используется как способ обмена идентичностью между различными сторонами.
Одним из возможных способов регистрации на сайте собственного набора может быть отправка предложенной группы доменов общедоступному трекеру (например, выделенному репозиторию GitHub) вместе с информацией, необходимой для соблюдения политики браузера.
После проверки утверждения основного набора в соответствии с политикой браузеры могут получать списки наборов посредством процесса обновления.
Испытание происхождения имеет определенную политику, которая не является окончательной, но принципы, вероятно, останутся прежними:
- Домены в собственном наборе должны принадлежать и управляться одной и той же организацией.
- Домены должны быть узнаваемы пользователями как группа.
- Домены должны иметь общую политику конфиденциальности.
Как определить собственный набор
После того как вы определите участников и владельца собственного набора вашей организации, важным шагом станет отправка предлагаемого набора на утверждение. Точный процесс все еще обсуждается.
Чтобы объявить собственный набор, статические ресурсы JSON, в которых перечислены участники и владельцы, должны размещаться по адресу /.well-known/first-party-set
на верхнем уровне каждого включенного домена.
В примере с собственным набором brandx
домен владельца размещает следующее по адресу https://brandx.site/.well-known/first-party-set
:
{
"owner": "brandx.site",
"version": 1,
"members": ["fly-brandx.site", "drive-brandx.site"]
}
Каждый член набора также содержит статический ресурс JSON, указывающий на владельца набора. На https://fly-brandx.site/.well-known/first-party-set
у нас есть:
{ "owner": "brandx.site" }
И на https://drive-brandx.site/.well-known/first-party-set
:
{ "owner": "brandx.site" }
Для собственных наборов существует несколько ограничений:
- У набора может быть только один владелец.
- Член может принадлежать только к одному набору, без дублирования или смешивания.
- Список участников должен оставаться относительно удобочитаемым и не слишком большим.
Как собственные наборы влияют на файлы cookie?
Соответствующим компонентом для файлов cookie является предлагаемый атрибут SameParty
. Указание SameParty
сообщает браузеру о необходимости включения файла cookie, если его контекст является частью того же основного набора, что и контекст верхнего уровня.
Это означает, что если brandx.site
установит этот файл cookie:
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
Затем, когда посетитель находится на fly-brandx.site
и запрос поступает на brandx.site
, в этот запрос будет включен файл cookie session
. Если какой-либо другой сайт, не входящий в основной набор, например hotel.xyz
, отправляет запрос на brandx.site
, файл cookie не будет включен.
![Диаграмма, показывающая, как файл cookie Brandx.site разрешен или заблокирован в межсайтовом контексте, как описано.](https://developers.google.com/static/privacy-sandbox/assets/images/blog/diagram-showing-brandxs-4a8e910c2d1cc.png?hl=ru)
Пока SameParty
не получит широкую поддержку, используйте вместе с ним атрибут SameSite
, чтобы определить резервное поведение для файлов cookie. Вы можете думать об атрибуте SameParty
как о настройке между SameSite=Lax
и SameSite=None
.
-
SameSite=Lax; SameParty
расширит функциональностьLax
, включив в нее односторонние контексты, где это поддерживается, но в противном случае вернется к ограничениямLax
. -
SameSite=None; SameParty
ограничит функциональностьNone
только односторонними контекстами, где это поддерживается, но в противном случае вернется к более широким разрешениямNone
.
Есть некоторые дополнительные требования:
- Файлы cookie
SameParty
должны включатьSecure
. - Файлы cookie
SameParty
не должны включатьSameSite=Strict
.
Secure
обязательна, поскольку это по-прежнему межсайтовое соединение, и вам следует снизить эти риски, обеспечив безопасные (HTTPS) соединения. Аналогичным образом, поскольку это межсайтовая связь, SameSite=Strict
недействителен, поскольку он по-прежнему обеспечивает строгую защиту CSRF на основе сайта внутри набора.
Какие варианты использования подходят для собственных наборов?
Первичные наборы хорошо подходят для случаев, когда организации требуется форма общего удостоверения на разных сайтах верхнего уровня. Общая идентификация в этом случае означает что угодно: от полного решения единого входа до просто необходимости общих предпочтений между сайтами.
Ваша организация может иметь разные домены верхнего уровня для:
- Домены приложений :
office.com
,live.com
,microsoft.com
- Брендовые домены :
amazon.com
,audible.com
,pixar.com
disney.com
- Домены конкретной страны для включения локализации:
google.co.in
,google.co.uk
- Домены служб , с которыми пользователи никогда напрямую не взаимодействуют, но предоставляют услуги на сайтах одной и той же организации:
gstatic.com
,githubassets.com
,fbcdn.net
- Домены-песочницы , с которыми пользователи никогда не взаимодействуют напрямую, но существуют по соображениям безопасности:
googleusercontent.com
,githubusercontent.com
Как принять участие?
Если у вас есть несколько сайтов, соответствующих приведенным выше критериям, есть несколько вариантов участия. Самое легкое вложение — прочитать и присоединиться к обсуждению двух предложений:
- Обсуждение в группе сообщества по обеспечению конфиденциальности собственных наборов данных
- Обсуждение атрибутов файлов cookie SameParty
На этапе тестирования вы можете опробовать эту функциональность, используя флаг командной строки --use-first-party-set
и предоставив список сайтов, разделенных запятыми.
Вы можете попробовать это на демонстрационном сайте https://fps-member1.glitch.me/ после запуска Chrome со следующим флагом:
--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me
Это полезно, если вы хотите провести тестирование в своей среде разработки или попробовать добавить атрибут SameParty
в действующую среду, чтобы увидеть, как собственный набор повлияет на файлы cookie.
Если у вас есть возможность экспериментировать и получать отзывы, вы также можете подписаться на пробную версию Origin для собственных наборов и SameParty, которая доступна в Chrome с версии 89 по 93.
Как обновить файлы cookie для пробной версии Origin
Если вы присоединяетесь к пробной версии Origin и тестируете атрибут SameParty
в своих файлах cookie, следует учитывать два шаблона.
Вариант 1
Во-первых, если у вас есть файлы cookie, которые вы пометили как SameSite=None
, но вы хотите ограничить их собственными контекстами, вы можете добавить к ним атрибут SameParty
. В браузерах, где активна пробная версия источника, файлы cookie не будут отправляться в межсайтовом контексте за пределами набора.
Однако для большинства браузеров, не входящих в исходную пробную версию, файлы cookie будут продолжать отправляться между сайтами, как обычно. Считайте это прогрессивным подходом к улучшению.
До: set-cookie: cname=cval; SameSite=None; Secure
После: set-cookie: cname=cval; SameSite=None; Secure; SameParty
Вариант 2
Второй вариант требует больше работы, но позволяет полностью отделить исходную пробную версию от существующей функциональности и, в частности, позволяет тестировать SameSite=Lax; SameParty
Комбинация SameSite=Lax; SameParty
.
До: set-cookie: cname=cval; SameSite=None; Secure
После:
set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty
При проверке файла cookie во входящих запросах вам следует ожидать появления файла cookie cname-fps
в межсайтовом запросе только в том случае, если задействованные сайты входят в набор, а браузер находится в пробной версии источника. Рассматривайте этот подход как одновременный запуск обновленной функции перед отказом от предыдущей версии.
Почему вам может не понадобиться собственный набор?
Для большинства сайтов граница сайта является приемлемым местом для обозначения раздела или границы конфиденциальности. Это маршрут, который предлагается с помощью CHIPS (файлы cookie с независимым разделенным состоянием), который предоставит сайтам возможность выбора через атрибут Partitioned
, чтобы по-прежнему иметь эти важные межсайтовые встраивания, ресурсы, API и службы, предотвращая при этом утечку идентификация информации на сайтах.
Еще несколько вещей, которые следует учитывать, означают, что с вашим сайтом все будет в порядке и без необходимости установки:
- Вы размещаете хостинг на разных источниках, а не на разных сайтах. В приведенном выше примере, если у
brandx.site
естьfly.brandx.site
иdrive.brandx.site
, то это разные поддомены на одном сайте. Файлы cookie могут использоватьSameSite=Lax
, и установка не требуется. - Вы предоставляете сторонние встраивания на другие сайты. Во вступлении пример видео с
video.site
, встроенного вmy-blog.site
, является явным разделением между третьими сторонами. Сайты управляются разными организациями, и пользователи видят их как отдельные объекты. Эти два сайта не должны быть в одном наборе. - Вы предоставляете сторонние службы входа в социальные сети. Поставщики удостоверений, использующие такие вещи, как OAuth или OpenId Connect, часто полагаются на сторонние файлы cookie для более удобного входа в систему для пользователей. Это допустимый вариант использования, но он не подходит для собственных наборов, поскольку между организациями существует явная разница. Ранние предложения, такие как WebID, изучают способы реализации этих вариантов использования.