신뢰 토큰 시작하기

신뢰 토큰은 웹사이트가 한 탐색 컨텍스트 (예: 사이트 간)로 제한된 양의 정보를 전달하여 수동 추적 없이 사기 방지를 지원하는 새로운 API입니다.

Sam Dutton



요약

신뢰 토큰을 사용하면 출처에서 신뢰할 수 있는 사용자에게 암호화 토큰을 발급할 수 있습니다. 토큰은 사용자의 브라우저에 저장됩니다. 그러면 브라우저가 다른 컨텍스트의 토큰을 사용하여 사용자의 신뢰성을 평가할 수 있습니다.

Trust Token API를 사용하면 사용자를 식별하거나 두 ID를 연결하지 않고도 한 컨텍스트에서 사용자의 신뢰를 다른 컨텍스트로 전달할 수 있습니다.

데모로 API를 사용해 볼 수 있으며 Chrome DevTools의 네트워크 및 애플리케이션 탭에서 토큰 검사를 수행할 수 있습니다.

Chrome DevTools Network 탭의 Trust Tokens를 보여주는 스크린샷
Chrome DevTools의 네트워크 탭에서 신뢰 토큰으로 이동합니다.
Chrome DevTools Application 탭의 Trust Tokens를 보여주는 스크린샷입니다.
Chrome DevTools의 애플리케이션 탭의 신뢰 토큰

신뢰 토큰이 필요한 이유는 무엇인가요?

웹에는 사람인 척하는 봇이나 실제 사람 또는 서비스를 사취하는 악의적인 서드 파티가 아닌, 사용자가 정체를 밝히는 신뢰 신호를 설정할 방법이 필요합니다. 사기 방지는 광고주, 광고 제공업체, CDN에 특히 중요합니다.

안타깝게도 신뢰도를 측정하고 전파하는 많은 기존 메커니즘(예: 사이트와의 상호작용이 실제 사람으로부터 발생했는지 확인)에서는 디지털 지문 수집에도 사용할 수 있는 기술을 활용합니다.

API는 개인 정보를 보호하여 개별 사용자 추적 없이 사이트 간에 신뢰를 전파할 수 있어야 합니다.

신뢰 토큰 제안서의 내용은 무엇인가요?

웹은 신뢰 신호를 구축하여 사기와 스팸을 감지합니다. 이를 위한 한 가지 방법은 전역 크로스 사이트별 사용자별 식별자로 탐색을 추적하는 것입니다. 개인 정보 보호 API의 경우 허용되지 않습니다.

제안서 설명서에서 다음 단계를 따르세요.

이 API는 서드 파티 컨텍스트에서 액세스할 수 있는 '개인 정보 보호 패스' 스타일 암호화 토큰을 위한 새로운 출처별 스토리지 영역을 제안합니다. 이러한 토큰은 맞춤설정되지 않고 사용자를 추적하는 데 사용할 수 없지만 암호화 서명이 되어 있으므로 위조할 수 없습니다.

출처가 사용자를 신뢰하는 컨텍스트에 있는 경우 사용자는 브라우저에게 토큰 배치를 발급할 수 있습니다. 이 일괄 토큰은 사용자를 알 수 없거나 신뢰도가 낮은 컨텍스트에서 나중에 '사용'할 수 있습니다. 결정적으로 토큰을 서로 구분할 수 없어 웹사이트에서 토큰을 통해 사용자를 추적할 수 없습니다.

또한 브라우저에서 특정 토큰 사용에 바인딩된 키를 사용하여 발신 요청에 서명할 수 있는 확장 메커니즘을 제안합니다.

샘플 API 사용

다음 내용은 API 설명의 샘플 코드에서 발췌한 것입니다.

사용자가 서드 파티 광고 네트워크 (foo.example)의 광고가 삽입된 뉴스 웹사이트 (publisher.example)를 방문한다고 가정해 보겠습니다. 이 사용자는 이전에 신뢰 토큰을 발급하는 소셜 미디어 사이트 (issuer.example)를 사용한 적이 있습니다.

아래 시퀀스는 신뢰 토큰의 작동 방식을 보여줍니다.

1.사용자가 issuer.example을 방문하여 계정 활동기록 또는 보안문자 확인 통과와 같이 사이트에서 실제 사람으로 간주하도록 유도하는 작업을 실행합니다.

2.issuer.example는 사용자가 사람인지 확인하고 다음 자바스크립트를 실행하여 사용자의 브라우저에 신뢰 토큰을 발급합니다.

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는 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에서 이에 따라 응답합니다.
웹사이트는 내 비즈니스를 신뢰하는지 어떻게 판단할 수 있나요?

전자상거래 사이트의 쇼핑 기록, 위치 플랫폼에서의 체크인 또는 은행 계좌 기록이 있을 수 있습니다. 또한 발급기관은 계정 보유 기간, 실제 사람일 가능성에 대한 발급기관의 신뢰를 높이는 기타 상호작용 (예: 보안문자 또는 양식 제출)과 같은 다른 요인도 고려할 수 있습니다.

신뢰 토큰 발급

issuer.example과 같은 신뢰 토큰 발급기관에서 사용자를 신뢰할 수 있다고 판단되면 발급기관은 trustToken 매개변수를 사용하여 fetch() 요청을 하여 사용자의 신뢰 토큰을 가져올 수 있습니다.

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

그러면 새로운 암호화 프리미티브를 사용하여 개인 정보 보호 패스 발급 프로토콜의 확장이 호출됩니다.

  1. nonce라고 하는 의사 난수 집합을 생성합니다.

  2. nonce를 블라인드하고 (발급기관이 콘텐츠를 볼 수 없도록 인코딩) Sec-Trust-Token 헤더의 요청에 연결합니다.

  3. 제공된 엔드포인트로 POST 요청을 보냅니다.

엔드포인트가 블라인드된 토큰(블라인드 nonce의 서명)으로 응답하면 토큰은 블라인드가 해제되고 브라우저에 의해 연결된 nonce와 함께 신뢰 토큰으로 내부적으로 저장됩니다.

신뢰 토큰 사용

게시자 사이트 (예: 위 예시의 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 요청 헤더로 포함됩니다.

개인정보 보호 고려사항

토큰은 '연결할 수 없도록' 설계되어 있습니다. 발급기관은 사용자가 방문하는 사이트에 대한 집계 정보를 알 수 있지만 발급과 사용은 연결할 수 없습니다. 사용자가 토큰을 사용할 때 발급기관은 토큰을 자신이 생성한 다른 토큰과 구분할 수 없습니다. 그러나 신뢰 토큰은 현재 외부와 단절된 상태로 존재하지 않습니다. 서드 파티 쿠키, 은밀한 추적 기술 등 발급기관이 이론적으로 여러 사이트에서 사용자의 ID에 조인할 수 있는 다른 방법이 있습니다. 사이트는 지원을 계획할 때 이러한 생태계 전환을 이해하는 것이 중요합니다. 이는 많은 개인 정보 보호 샌드박스 API 전환의 일반적인 측면이므로 여기서는 자세히 설명하지 않습니다.

보안 고려사항

트러스트 토큰 소진: 악성 사이트는 특정 발급기관에서 사용자가 공급하는 토큰을 의도적으로 고갈시킬 수 있습니다. 발급기관이 한 번에 많은 토큰을 제공할 수 있도록 하는 등, 이러한 유형의 공격을 완화할 수 있는 몇 가지 방법이 있습니다. 따라서 사용자는 브라우저가 최상위 페이지 조회당 하나의 토큰만 사용하도록 할 수 있습니다.

이중 결제 방지: 멀웨어가 사용자의 모든 신뢰 토큰에 액세스하려고 시도할 수 있습니다. 하지만 모든 사용 내역이 동일한 토큰 발급기관으로 전송되어 각 토큰이 한 번만 사용되었는지 확인할 수 있으므로 시간이 지남에 따라 토큰이 소진됩니다. 위험을 완화하기 위해 발급기관이 더 적은 수의 토큰에 서명할 수도 있습니다.

요청 메커니즘

내비게이션 요청과 같이 fetch() 외부로 사용 레코드를 전송하는 것이 가능할 수도 있습니다. 사이트에서는 페이지 로드와 동시에 토큰 사용을 설정하기 위해 HTTP 응답 헤더에 발급기관 데이터를 포함할 수도 있습니다.

다시 한번 강조하지만, 이 제안에 여러분의 의견이 필요합니다. 의견이 있는 경우 신뢰 토큰 설명 저장소에서 문제를 생성하세요.

자세히 알아보기

이 게시물을 작성하고 검토하는 데 도움을 주신 모든 분께 감사드립니다.

사진: ZSun Fu(Unsplash 제공)