[УСТАРЕЛО] Собственные наборы и атрибут SameParty

Предупреждение. Предложение по собственным наборам было обновлено, и эта статья больше не актуальна. Для получения последней информации обратитесь к пояснителю и инструкциям по тестированию .

Многие организации имеют связанные сайты с разными доменными именами, например brandx.site и fly-brandx.site , или доменами для разных стран, например example.com , example.rs , example.co.uk и т. д.

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

Первичные наборы могут позволить рассматривать связанные доменные имена, которые принадлежат и управляются одной и той же организацией, как собственные в ситуациях, когда первая и третья стороны в противном случае рассматриваются по-разному. Доменные имена в собственном наборе считаются односторонними и могут указывать, какие файлы 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 определяется атрибутом 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 может быть включен в основной набор и исключен из стороннего контекста.

Политика в отношении собственных наборов

First-Party Sets предлагает метод явного определения этих отношений между несколькими сайтами, которые принадлежат и управляются одной и той же стороной . Это позволит brandx.site определить свои собственные отношения с fly-brandx.site , drive-brandx.site и т. д.

Модель конфиденциальности , лежащая в основе различных предложений Privacy Sandbox, основана на концепции разделения личности для предотвращения межсайтового отслеживания — прорисовке границы между сайтами, которая ограничивает доступ к любой информации, которая может использоваться для идентификации пользователей.

Хотя параметром по умолчанию является разделение по сайтам, что решает многие случаи использования собственных сайтов, пример brandx.site показывает, что собственный сайт может быть больше, чем один сайт.

Важной частью предложения по собственным наборам является обеспечение того, чтобы политика всех браузеров предотвращала злоупотребления или неправильное использование. Например, собственные наборы не должны обеспечивать обмен пользовательской информацией между несвязанными сайтами или группировку сайтов, не принадлежащих одной и той же организации. Идея состоит в том, чтобы гарантировать, что First-Party Set сопоставляется с чем-то, что человек понимает как «первый участник», и не используется как способ обмена идентичностью между различными сторонами.

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

Примечание. Процесс принятия нового собственного набора обсуждается с W3C, и одним из рассматриваемых вариантов является проведение проверки независимой организацией, а не компанией-разработчиком браузера.

После проверки утверждения основного набора в соответствии с политикой браузеры могут получать списки наборов посредством процесса обновления.

Испытание происхождения имеет определенную политику, которая не является окончательной, но принципы, вероятно, останутся прежними:

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

Примечание. Узнайте больше о предлагаемой политике в отношении собственных наборов .

Как определить собственный набор

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

Внимание! Собственный набор не должен представлять собой исчерпывающий список сайтов, принадлежащих одной организации. Вам нужно создать набор между сайтами только в том случае, если вам явно требуется, чтобы между ними был разрешен межсайтовый файл cookie. Обязательно ознакомьтесь со статьей «Какие варианты использования подходят для пробной версии сторонних наборов Origin?» ниже.

Чтобы объявить собственный набор, статические ресурсы 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" }

Для собственных наборов существует несколько ограничений:

• У набора может быть только один владелец.
• Член может принадлежать только к одному набору, без дублирования или смешивания.
• Список участников должен оставаться относительно удобочитаемым и не слишком большим.

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

Как собственные наборы влияют на файлы 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 не будет включен.

Пока 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 на основе сайта внутри набора.

Ключевой момент: атрибут SameParty влияет только на контексты, в которые может быть отправлен файл cookie, но не создает общий jar-файл cookie. Файл cookie с brandx.site доступен только для запросов или документов для brandx.site Файл cookie никогда не доступен напрямую для fly-brandx.site . Это может сбить с толку, поскольку вы можете увидеть, что это называется общей идентификацией, но это означает, что смягченная граница между сайтами позволяет им устанавливать или отправлять файлы cookie в одностороннем межсайтовом контексте, а не в том, что файлы cookie передаются напрямую.

Какие варианты использования подходят для собственных наборов?

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

Примечание. Вы можете определить возможных кандидатов для этих вариантов использования, поскольку это будут случаи, когда вы уже пометили файл cookie как SameSite=None даже если это касается только межсайтового контекста, где вы владеете всеми задействованными сайтами.

Ваша организация может иметь разные домены верхнего уровня для:

• Домены приложений : 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.

Ключевой термин: испытания rigin — это способ Chrome, позволяющий внешним разработчикам тестировать ранние предложения в реальных сценариях, чтобы обеспечить обратную связь, необходимую для развития и итераций в направлении чего-то, что соответствует потребностям веб-платформы. Дополнительную информацию см. в статье «Начало работы с пробными версиями Chrome Origin» .

Как обновить файлы 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, изучают способы реализации этих вариантов использования.