Начало работы с токенами доверия

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



Краткое содержание

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

API Trust Token позволяет передать доверие пользователя в одном контексте в другой контекст без идентификации пользователя или связывания двух удостоверений.

Вы можете опробовать API с помощью нашей демонстрации и проверить токены на вкладках « Сеть» и «Приложение» Chrome DevTools.

Снимок экрана, на котором показаны токены доверия на вкладке "Сеть Chrome DevTools".
Токены доверия на вкладке « Сеть Chrome DevTools».
Снимок экрана, на котором показаны токены доверия на вкладке "Приложение Chrome DevTools".
Токены доверия на вкладке « Приложение Chrome DevTools».

Зачем нам нужны токены доверия?

Сети нужны способы установления сигналов доверия, которые показывают, что пользователь — это тот, кем он себя называет, а не бот, притворяющийся человеком, или злонамеренная третья сторона, обманывающая реального человека или службу. Защита от мошенничества особенно важна для рекламодателей, поставщиков рекламы и CDN.

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

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

Что входит в предложение Trust Tokens?

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

Из пояснения к предложению:

Этот API предлагает новую область хранения для каждого источника для криптографических токенов в стиле «Privacy Pass», которые доступны в сторонних контекстах. Эти токены не персонализированы и не могут использоваться для отслеживания пользователей, но имеют криптографическую подпись, поэтому их невозможно подделать.

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

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

Пример использования API

Следующее адаптировано из примера кода в объяснителе API .

Представьте, что пользователь посещает новостной веб-сайт ( publisher.example ), на котором размещена реклама сторонней рекламной сети ( foo.example ). Пользователь ранее использовал сайт социальной сети, который выдает токены доверия ( issuer.example ).

В приведенной ниже последовательности показано, как работают токены доверия.

1. Пользователь посещает issuer.example и выполняет действия, которые заставляют сайт поверить в то, что он настоящий человек, например, активность учетной записи или прохождение проверки CAPTCHA.

2. issuer.example проверяет, является ли пользователь человеком, и запускает следующий код JavaScript для выдачи токена доверия браузеру пользователя:

fetch('https://issuer.example/trust-token', {
  trustToken: {
    type: 'token-request',
    issuer: 'https://issuer.example'
  }
}).then(...)

3. Браузер пользователя сохраняет токен доверия, связывая его с issuer.example .

4. Через некоторое время пользователь заходит на publisher.example .

5.Publisher.example хочет знать publisher.example является ли пользователь настоящим человеком. publisher.example доверяет issuer.example , поэтому они проверяют, есть ли в браузере пользователя действительные токены из этого источника:

document.hasTrustToken('https://issuer.example');

6. Если это возвращает обещание, которое разрешается как true , это означает, что у пользователя есть токены из issuer.example , поэтому publisher.example может попытаться выкупить токен:

fetch('https://issuer.example/trust-token', {
trustToken: {
  type: 'token-redemption',
  issuer: 'https://issuer.example',
  refreshPolicy: {none, refresh}
}
}).then(...)

С помощью этого кода:

  1. publisher.example запрашивает выкуп.
  2. Если погашение прошло успешно, эмитент issuer.example возвращает запись о погашении, которая указывает, что в какой-то момент он выдал этому браузеру действительный токен.

    7. Как только обещание, возвращенное функцией fetch() будет выполнено, запись о погашении можно будет использовать в последующих запросах ресурсов:

fetch('https://foo.example/get-content', {
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['https://issuer.example', ...]
  }
});

С помощью этого кода:

  1. Записи о погашении включаются в заголовок запроса Sec-Redemption-Record .
  2. foo.example получает запись о погашении и может проанализировать ее, чтобы определить, считает ли issuer.example , что этот пользователь — человек.
  3. foo.example отвечает соответствующим образом.
Как веб-сайт может определить, стоит ли вам доверять?

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

Выпуск доверительного токена

Если эмитент токенов доверия, такой как issuer.example , считает пользователя заслуживающим доверия, эмитент может получить токены доверия для пользователя, выполнив запрос fetch() с trustToken :

fetch('issuer.example/trust-token', {
  trustToken: {
    type: 'token-request'
  }
}).then(...)

Это вызывает расширение протокола выдачи Privacy Pass с использованием нового криптографического примитива :

  1. Сгенерируйте набор псевдослучайных чисел, известных как nonce .

  2. Слепите одноразовые номера (закодируйте их, чтобы эмитент не мог просмотреть их содержимое) и прикрепите их к запросу в заголовке Sec-Trust-Token .

  3. Отправьте запрос POST на указанную конечную точку.

Конечная точка отвечает слепыми токенами (подписями на слепых одноразовых номерах), затем токены разблокируются и сохраняются внутри браузера вместе со связанными одноразовыми номерами в качестве токенов доверия.

Погашение доверительного токена

Сайт издателя (например, publisher.example в приведенном выше примере) может проверить, доступны ли пользователю токены доверия:

const userHasTokens = await document.hasTrustToken('issuer.example/trust-token');

Если есть доступные токены, сайт издателя может выкупить их, чтобы получить запись о погашении:

fetch('issuer.example/trust-token', {
  ...
  trustToken: {
    type: 'token-redemption',
    refreshPolicy: 'none'
  }
  ...
}).then(...)

Издатель может включать записи о погашении в запросы, для которых требуется токен доверия (например, публикация комментария, отметка «Нравится» странице или голосование в опросе), используя вызов fetch() подобный следующему:

fetch('https://foo.example/post-comment', {
  ...
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['issuer.example/trust-token', ...]
  }
  ...
}).then(...);

Записи о погашении включаются в заголовок запроса Sec-Redemption-Record .

Соображения конфиденциальности

Токены спроектированы так, чтобы их нельзя было привязать. Эмитент может узнать совокупную информацию о том, какие сайты посещают его пользователи, но не может связать выпуск с погашением: когда пользователь выкупает токен, эмитент не может отличить этот токен от других токенов, которые он создал. Однако токены доверия в настоящее время существуют не в вакууме: в настоящее время эмитент может (теоретически) объединить личность пользователя на разных сайтах другими способами, например, сторонние файлы cookie и методы скрытого отслеживания. Сайтам важно понимать этот переход в экосистеме при планировании поддержки. Это общий аспект перехода для многих API Privacy Sandbox, поэтому здесь он не обсуждается далее.

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

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

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

Механизмы запроса

Возможно, можно разрешить отправку записей о погашении за пределы fetch() , например, с помощью навигационных запросов. Сайты также могут включать данные эмитента в заголовки ответов HTTP, чтобы обеспечить погашение токена параллельно с загрузкой страницы.

Еще раз повторю: это предложение нуждается в вашем отзыве! Если у вас есть комментарии, создайте проблему в репозитории объяснений токенов доверия.

Узнать больше


Спасибо всем, кто помог написать и просмотреть этот пост.

Фото ZSun Fu на Unsplash .