어트리뷰션 레벨 1

1. 소개

이 문서는 브라우저용 API를 정의하며, 집계된, 차등 개인정보 보호가 적용된 사이트 간 측정항목을 수집할 수 있게 한다.

이 API의 목적은 광고에 대한 기여도 측정을 가능하게 하는 것이다. 이러한 집계 측정항목은 API가 적절하게 사용되는 경우 광고 성과를 더 잘 이해하는 데 기여할 수 있다.

1.1. 어트리뷰션

광고에서, 어트리뷰션은 관심 있는 결과보다 앞서 발생한 동작을 식별하고, 그 동작에 가치를 할당하는 과정이다.

광고주가 관심을 가지는 동작은 주로 광고를 표시하는 것 (또한 노출이라고도 한다)이다. 다른 동작에는 광고 클릭(또는 다른 상호작용)과 사용되지 않은 광고 표시 기회가 포함된다.

광고에서 원하는 결과는 더 다양하다. 광고 표시를 통해 광고주가 개선하려는 모든 결과를 포함하기 때문이다. 바람직한 결과는 전환이라고도 할 수 있으며, 이는 잠재 고객을 고객으로 “전환”하는 것을 의미한다. 전환으로 간주되는 것은 판매, 구독, 페이지 방문 및 문의를 포함할 수 있다.

이 API에서, 동작과 결과는 모두 이벤트, 즉 한 번 발생하는 일이다. 광고를 위한 어트리뷰션의 고유한 점은 이러한 이벤트가 같은 사이트에서 발생하지 않을 수도 있다는 것이다. 광고는 광고주의 사이트가 아닌 다른 사이트에서 가장 자주 표시된다.

어트리뷰션의 주요 과제는 프라이버시를 유지하는 데 있다. 어트리뷰션은 서로 다른 사이트의 활동을 연결하는 일을 포함한다. 어트리뷰션의 목표는 전환이 발생하기 전에 같은 사람에게 표시된 노출을 찾는 것이다.

어트리뷰션 정보가 직접 공개된다면, 원치 않는 교차 컨텍스트 인식을 가능하게 하여, 그 결과 추적을 가능하게 할 것이다.

이 문서는 어트리뷰션 정보가 집계 서비스를 사용하여 집계되도록 보장함으로써 교차 컨텍스트 인식을 피한다. 집계 서비스는 각 사람이 해당 집계에 기여하는 값을 드러내지 않고 집계를 계산한다고 신뢰된다.

각 브라우저 인스턴스가 주어진 사이트의 집계에 기여하는 정보의 양에는 엄격한 제한이 적용된다. 각 기여에 추가적인 프라이버시 보호를 제공하기 위해 차등 프라이버시가 사용된다.

집계 서비스 동작의 세부사항은 § 6 집계에 포함되어 있다. 사용된 차등 프라이버시 설계는 § 7 차등 프라이버시에서 개괄한다.

1.2. 배경

웹의 초기부터, 광고는 사이트 제작을 재정적으로 지원하기 위해 널리 사용되어 왔다.

웹을 다른 광고 매체와 구별하게 한 한 가지 특징은 광고 캠페인의 효과에 대한 정보를 얻을 수 있다는 점이었다.

웹 광고주는 도달률(광고를 본 사람 수), 빈도(각 사람이 광고를 본 횟수), 및 전환(광고를 본 뒤 나중에 그 광고가 유도하려던 동작을 수행한 사람 수)과 같은 주요 메트릭을 측정할 수 있었다. 이에 비해, 이러한 측정은 다른 어떤 매체보다도 훨씬 더 시의적절하고 정확했다.

측정 성능의 대가는 개인정보 보호였다. 정확하고 포괄적인 정보를 생성하기 위해, 광고 사업자는 모든 웹 사용자의 활동을 광범위하게 추적했다. 각 브라우저에는 추적 식별자가 부여되었으며, 흔히 사이트 간 리소스와 연결된 쿠키가 사용되었다. 관심 대상이 되는 모든 동작은 이 식별자에 대해 기록되었고, 한 사람의 온라인 활동에 대한 포괄적인 기록이 형성되었다.

한 사람의 동작에 대한 상세한 기록을 보유하면 광고주가 사람들에 대한 특성을 추론할 수 있었다. 이러한 특성은 광고에 적합한 대상을 선택하기 쉽게 하여, 그 효과를 크게 향상시켰다. 이는 더 많은 정보를 수집하려는 강한 유인을 만들었다.

온라인 광고는 매우 경쟁적이다. 광고를 표시하는 사이트는 각 광고 게재에서 최대한 많은 수익을 얻으려 한다. 광고주는 비용 대비 가장 큰 효과가 있을 곳에 광고를 게재하려 한다. 이러한 주체들—​및 그들을 대신하여 운영하는 중개자들—​이 얻는 모든 경쟁 우위는 잠재적 대상에 대한 더 포괄적인 정보를 보유하는 데 달려 있다.

시간이 지나면서, 관심 있는 동작은 온라인 활동의 거의 모든 측면을 포함하도록 확장되었다. 그 정보를 웹 밖의 활동과 연관시키는 방법이 고안되었다. 다양한 목적을 위해 거래되는 개인 정보의 여러 판매자가 참여하는 활발한 거래가 형성되었다.

1.3. 목표

이 문서는 광고를 사용하는 사이트에서 기여도 측정을 가능하게 하면서 추적을 가능하게 하거나 조장하는 메커니즘, 예를 들어 사이트 간 쿠키를 피하고자 한다.

Attribution API는 사이트에 측정 도구를 제공함으로써 간접적이고 집단적인 사용자 이익을 제공하는 것을 목표로 한다. 이러한 도구는 효과적으로 적용될 경우 광고 성과에 대한 통찰을 제공할 수 있다.

1.4. 최종 사용자 이점

광고 성과의 측정은 새로운 교차 사이트 정보 흐름을 만든다. 그 정보 흐름은 교차 컨텍스트 인식이라는 프라이버시 위험 또는 비용을 만들며, 이는 최종 사용자에게 주는 이점의 관점에서 정당화되어야 한다.

어트리뷰션 사용을 통해 최종 사용자가 얻는 모든 이점은 간접적이다.

웹사이트를 방문하는 최종 사용자는 사이트가 보여주는 광고에 대한 자신의 주의를 통해 주로 “무료” 콘텐츠나 서비스의 비용을 지불한다. 이 “가치”는 광고주에게 발생하며, 광고주는 다시 사이트에 비용을 지불한다. 사이트는 이 돈을 콘텐츠나 서비스 제공을 지원하는 데 사용할 것으로 기대된다.

기여도 측정 시스템에 참여하는 것은 웹 사용자에게 부차적인 비용을 초래할 수 있다.

기여도 측정을 지원하면 광고주에게 광고 전략을 개선하는 데 사용할 수 있는 정보를 제공함으로써 더 효과적인 광고가 가능해질 수 있다. 기여도 측정을 통해 원하는 결과와 광고가 표시되는 시간과 장소, 광고가 제시되는 사람, 그리고 광고 자체의 세부 정보와 같은 광고 특성 간의 상관관계를 측정할 수 있다. 사이트는 이 정보를 사용하여 광고 활용 방식을 개선할 수 있다.

행동을 결과와 연결하는 것은 광고주가 성과를 개선하는 더 광범위한 측정 전략의 일부로 사용할 수 있는 도구이다. 효과적인 측정을 통해 광고주는 효과적인 광고에는 더 많이 지출하고 효과가 없는 광고에는 더 적게 지출할 수 있다. 이는 얻는 가치에 비해 광고의 전체 비용을 낮춘다. [ONLINE-ADVERTISING]

콘텐츠 게시자 및 서비스 제공자와 같이 광고 인벤토리를 제공하는 사이트는 더 효율적인 광고로부터 간접적으로 이익을 얻는다. 광고주가 원하는 결과를 가져오는 광고를 더 효과적으로 표시할 수 있는 광고 매체는 광고 게재에 더 높은 비용을 부과할 수 있다.

광고 게재를 통해 지원을 받는 사이트는 양질의 콘텐츠나 서비스를 더 잘 제공할 수 있다. 중요한 점은 이러한 지원이 이용자층으로부터 불균등하게 발생한다는 것이다. 이는 다른 형태의 재정 지원보다 더 공평할 수 있다. 광고된 상품에 지출하려는 경향이나 지출 능력이 낮은 사람도 비용을 지불할 여력이 있는 사람과 동일한 광고 지원 콘텐츠와 서비스를 이용할 수 있다. [EU-AD][COPPACALYPSE]

광고로 지원되는 "무료" 서비스를 제공할 수 있는 능력은 이러한 서비스의 가치에서 비롯되는 측정 가능한 경제적 이익을 제공한다. [FREE-GDP]

1.5. 집단적 프라이버시 효과

집계를 사용하면—​올바르게 구현된 경우—​사이트에 제공되는 정보가 개인이 아니라 그룹에 관한 것이 되도록 보장한다.

따라서 이 메커니즘의 도입은 집단적 프라이버시라는 개념에 맞는 집단적 의사결정을 나타낸다.

어트리뷰션 측정 참여는 참여하는 그룹이 더 클수록 더 낮은 프라이버시 비용을 가진다. 이는 사이트가 집계에서 개인에 대한 정보를 추출할 수 있는 능력에 집계가 미치는 영향 때문이다. 이는 특히 중앙 차등 프라이버시에서 그렇다. 이것이 이 명세에서 사용되는 프라이버시 설계의 수학적 기반이다.

더 큰 참여자 집단은 측정되는 광고에 대한 더 대표성 있고—​따라서 더 유용한—​통계도 생성한다.

어트리뷰션이 정당화된다면, 이 두 요소는 모든 사용자에 대해 어트리뷰션을 활성화하도록 동기를 부여한다.

사용자 에이전트가 어트리뷰션 측정을 활성화하도록 하는 조치는 일부 사람들에게 긍정적으로 받아들여지지 않을 것이다. 사람마다 광고와 관계를 맺음으로써 발생하는 비용과 이점을 다르게 인식한다. 제안된 설계는 사이트에 그 선택을 드러내지 않으면서도 사람들이 어트리뷰션에 참여하는 것처럼 보일 수 있는 선택권을 허용한다. § 9.2 Attribution API 비활성화 참조.

1.6. 히스토그램을 사용한 어트리뷰션

어트리뷰션은 하나 이상의 광고 게재(노출)와 광고주가 원하는 결과 사이의 상관관계를 측정하려고 시도한다.

집계로 고려될 때, 개인에 대한 정보는 유용하지 않다. 동작과 결과는 그룹화되어야 한다.

가장 단순한 형태의 어트리뷰션은 광고의 속성에 따라 노출을 여러 그룹으로 나누고 전환의 수를 센다. 그룹화는 광고가 표시된 위치, 표시된 내용(“크리에이티브”), 광고가 표시된 시점, 또는 누구에게 표시되었는지 같은 속성에서 형성될 수 있다.

이러한 그룹화와 각 그룹에 귀속된 전환 횟수는 히스토그램을 구성한다. 히스토그램의 각 버킷은 광고 그룹의 전환 횟수를 집계한다. 이를 통해 그룹 간 비교가 가능하다.

목적에 따라 서로 다른 그룹화를 사용할 수 있다. 이를 통해 인과관계를 확립하려는 엄밀한 실험과 서로 다른 처리 조건에 대한 보다 단순한 비교가 모두 가능해진다. 예를 들어, 광고 소재(광고의 콘텐츠)를 기준으로 그룹화하여 서로 다른 광고 소재를 비교할 수 있다.

각 전환에서 1보다 큰 값을 추가하면 단순한 카운트 이상의 것이 가능해진다. 히스토그램은 값도 집계할 수 있으며, 이는 서로 다른 결과를 구분하는 데 사용될 수 있다. 노출에 할당되는 값은 전환 값이라고 한다. 더 높은 전환 값은 더 큰 구매나 더 높게 평가되는 모든 결과에 사용될 수 있다. 전환 값은 또한 여러 노출 사이에서 크레딧을 나누기 위해 분할될 수도 있다.

1.7. 제한 사항 및 성공적인 사용

Attribution API가 제공하는 결과는 광고 전략에 관한 의사 결정에 정보를 제공할 수 있다. 그러나 충분한 주의를 기울이지 않으면 API 사용으로 잘못된 의사 결정을 뒷받침하는 오해의 소지가 있는 결과가 나올 수 있다.

API가 제공하는 정보를 사용하여 더 나은 결정을 내리려면, 그 한계—​특히 편향과 오류의 잠재적 원인—​를 이해해야 한다. 이러한 이해는 API를 사용하는 시스템의 설계와 모든 결과의 해석 모두에 적용되어야 한다.

범위의 한계

중요한 한계는 동일한 브라우저에서의 활동만 Attribution API로 포착할 수 있다는 점이다. 광고 캠페인의 범위와 효과가 단일 매체에만 한정되는 경우는 드물다. 이는 얻어진 어떠한 측정 결과도 모든 관련 활동을 포착한다고 가정할 수 없음을 의미한다.

비인과적 효과

광고를 접하는 사람 중 일부는 광고가 유도하려는 행동을 이미 실행할 의도가 있다. 그러한 광고에 결과를 귀속시키면 광고의 효과에 대해 잘못된 인상을 줄 수 있다.

광고의 인과적 효과를 더 정확하게 측정하려면, (무작위) 통제 실험—​또는 업계 용어로 증분성—​을 사용할 필요가 있다 [INFERNO]. 기본적인 광고 통제 실험은 대상 이용자층을 식별하고, 해당 이용자층 내의 처리 그룹에 광고를 제공하고, 통제 그룹에는 광고를 제공하지 않거나 기본 광고를 표시하며, 두 그룹 간 원하는 결과의 차이를 측정하는 방식으로 이루어진다.

이 API는 이러한 실험을 지원하는 데 사용할 수 있다. 이는 통제 모집단과 처리 모집단을 서로 다른 히스토그램 버킷에 할당함으로써 구현할 수 있다. 다만 현재 웹 플랫폼에는 서로 다른 사이트에 걸쳐 사용자를 통제 그룹과 처리 그룹에 일관되게 할당하는 기능이 없다는 점에 유의해야 한다.

단순한 기여도 측정 로직

이 API는 단순한 멀티터치 기여도 측정 알고리즘을 제공한다. 단순한 기여도 측정 알고리즘은 의사 결정에 영향을 미치는 방식으로 결과에 편향을 유발할 수 있다. 향후 버전의 API에서는 더 정교한 알고리즘을 지원할 수 있다.

오류의 원인

분산 측정 시스템에는 여러 가지 오류 원인이 있다. 차등 개인정보 보호는 집계 결과에 일정량의 노이즈를 추가하지만, 그 양은 알려져 있다.

그 밖의 다양한 이유로 결과가 측정 대상을 정확하게 반영하지 못할 수 있으며, 그중 일부는 피할 수 없을 수도 있다. 여기에는 다음이 포함된다.

• 참여 사이트에 구성을 전파하는 과정에서의 실패 및 지연.

• 노출 또는 전환 이벤트의 손실을 유발하는 스크립트 오류.

• 저장소 압박으로 인한 저장된 노출 정보의 손실.

• 우발적이거나 악의적인 노출 기록.

• 보고서 손실을 초래하는 네트워크 오류.

• IVT 분류로 인해 실제 이벤트가 무시되는 경우.

• IVT 분류에 사기 또는 우발적인 실수가 잘못 포함되는 경우.

이러한 오류는 측정 결과에 알 수 없는 정도의 불확실성을 더할 수 있다. API를 사용하는 사이트는 이러한 오류 및 다른 종류의 오류에 대한 노출을 관리할 책임이 있다. 향후 버전의 API에서는 사이트가 오류를 처리할 때 더 나은 지원을 제공하도록 할 수 있다.

2. 동작 개요

Attribution API는 두 종류의 이벤트, 즉 노출과 전환 사이의 연관성에 대한 집계 정보를 제공한다.

노출은 광고주가 어떤 웹사이트에서든 수행하는 모든 동작이다. 이 API는 무엇이 노출로 기록될 수 있는지를 제한하지 않는다. 광고주가 측정하려 할 수 있는 일반적인 동작에는 다음이 포함된다.

• 광고 표시.

• 사용자가 어떤 방식으로든 광고와 상호작용하도록 하는 것.

• 광고를 표시하지 않는 것(특히 광고 캠페인이 효과적인지 확인하려는 통제 실험의 경우).

이 API에서 전환은 측정 대상인 결과이다. 이 API는 무엇이 결과로 간주될 수 있는지를 제한하지 않는다. 광고주가 측정하려 할 수 있는 일반적인 결과에는 다음이 포함된다.

• 구매하기.

• 계정 가입하기.

• 웹페이지 방문하기.

이 절의 나머지는 Attribution API가 집계 서비스와 함께 어떻게 동작하여 집계된 어트리뷰션 측정을 생성하는지를 설명한다. 그 동작은 다음 그림에 설명되어 있다.

2.1. 노출 기록

노출이 발생하면, saveImpression() 메서드를 사용하여 브라우저가 정보를 저장하도록 요청할 수 있다. 여기에는 노출에 대한 식별자와 노출에 관한 몇 가지 추가 정보가 포함된다. 예를 들어 광고주는 추가 정보를 사용하여 해당 노출이 광고 조회였는지 광고 클릭이었는지를 기록할 수 있다.

2.2. 전환 또는 노출 질의

전환 시점에는 전환 보고서가 생성된다. 전환 보고서는 브라우저가 이전에 저장한 노출의 정보를 포함하는 암호화된 히스토그램 기여값이다.

measureConversion() 메서드는 브라우저에 전환 보고서를 구성하는 방법을 알려 주는 데 사용되는 제한된 쿼리를 받는다. 여기에는 브라우저가 저장한 노출 중에서 선택하는 값, 선택된 노출에 할당되는 전환 값, 그리고 전환 보고서를 구성하는 데 필요한 기타 정보가 포함된다.

전환 보고서가 생성하는 히스토그램은 다음과 같이 구성된다.

• 쿼리가 노출을 찾지 못했거나, 해당 사이트의 프라이버시 예산이 소진된 경우, 전부 0으로 이루어진 히스토그램이 구성된다.

• 하나 이상의 일치하는 노출이 발견되면, 브라우저는 관련 노출을 선택하기 위해 last-n-touch 어트리뷰션 로직을 실행한다. 제공된 전환 값은 귀속된 노출 시점에 지정된 버킷의 히스토그램에 추가된다. 다른 모든 버킷은 0으로 설정된다.

브라우저는 보고된 전환을 반영하도록 프라이버시 예산 저장소를 갱신한다.

결과 히스토그램은 선택된 집계 서비스의 요구사항에 따라 집계를 위해 준비되고 사이트에 반환된다. 이는 최소한 히스토그램의 암호화를 포함한다.

이 API를 호출하는 사이트는 항상 유효한 전환 보고서를 받는다. 그 결과, 사이트는 이 상호작용으로부터 다른 사이트에서 어떤 일이 일어났는지 전혀 알 수 없다.

2.3. 집계

사이트는 이 API 호출에서 수신한 암호화된 히스토그램을 수집하여 집계 서비스에 제출할 수 있다.

사이트로부터 암호화된 히스토그램 집합을 수신하면, 집계 서비스는 다음을 수행한다.

1. 제공된 입력으로부터 집계를 이전에 계산한 적이 없으며 충분한 전환 보고서가 있음을 확인하고,

2. 충분한 노이즈를 포함하여 히스토그램을 더해 차등 프라이버시 집계 히스토그램을 생성하고,

3. 그 집계를 사이트에 반환한다.

집계 서비스의 최종 출력을 기여 결과라고 부른다.

브라우저 구현은 위 기능을 신뢰할 수 있게 수행하도록 신뢰되는 집계 서비스 집합을 가져야 한다. 제공되는 서비스 집합 중에서, 전환 사이트는 집계를 수행할 서비스 선택에 대해 합의에 도달해야 한다.

브라우저는 집계 서비스를 등록하기 위한 프로그램을 수립할 수도 있으며, 이는 브라우저가 Web PKI 인증서를 검증할 때 사용하는 인증 기관을 승인하기 위해 사용되는 루트 저장소 프로그램과 성격상 유사하다. 그러한 프로그램의 수립은 이 문서의 범위를 벗어난다.

3. API 사용

Attribution API를 사용하는 사이트는 일반적으로 노출 또는 전환 중 하나를 등록하지만, 경우에 따라 동일한 사이트가 두 가지를 모두 수행할 수도 있다.

노출을 등록하려면 사이트는 saveImpression()을 호출한다. 매개변수 값을 수집하는 것 외에는 이 API를 사용하기 위한 준비가 필요하지 않지만, Attribution API 사용 여부를 결정할 때 지원되는 aggregationServices를 살펴보는 것이 유용할 수 있다.

사용자 에이전트에 리소스를 제공할 때 HTTP 응답에 `Save-Impression` 헤더를 포함하여 노출을 등록할 수도 있다.

전환 보고서를 요청하려면 사이트는 measureConversion()을 호출한다. 이 API를 호출하기 전에 사이트는 지원되는 집계 서비스를 선택한다. 페이지는 aggregationServices에서 찾은 지원되는 서비스 중 어느 것이든 선택할 수 있다. 선택한 서비스의 이름은 measureConversion() 메서드를 호출할 때 AttributionConversionOptions 딕셔너리의 aggregationService 멤버로 제공된다.

3.1. 사이트 식별자

이 API는 자신이 동작하는 기본 범위로 사이트에 대한 HTML 정의에 의존한다. 세 가지 유형의 사이트가 인식된다.

• 노출 사이트는 노출을 등록하는 사이트이다. 이 노출 사이트는 최상위 출처에서 파생된다. 이는 관련 설정 객체의 최상위 출처이며, 노출을 저장하기 위해 saveImpression() 이 호출되는 시점의 것이다.

• 전환 사이트는 전환이 발생하는 사이트이다. 전환 사이트는 measureConversion() 이 호출되는 시점의 관련 설정 객체의 최상위 출처에서 파생된다.

• 중개자 사이트는 iframe과 같은 어떤 교차 사이트 프레임에서 API를 호출하는 사이트이다. 중개자 사이트는 관련 설정 객체의 출처에서 파생된다. 이는 saveImpression() 또는 measureConversion() 중 하나가 호출되는 시점의 것이며, 이 출처가 각각 노출 사이트 또는 전환 사이트와 same site인 경우는 제외한다.

이 API는 출처가 아니라 사이트를 사용한다. 이는 프라이버시 결과를 가질 수 있는 모든 활동을 단일 엔티티와 연결하는 것에 의존하기 때문이다. 쿠키와 같은 기능은 프라이버시 관련 정보가 same site 출처들 사이에서 자유롭게 교환되도록 허용하며, 그렇지 않으면 이를 사용하여 프라이버시 예산을 초과할 수 있다.

3.2. Navigator 인터페이스

이 API의 모든 기능은 navigator.attribution 속성에 연결된다.

partial interface Navigator {
  [SecureContext, SameObject] readonly attribute Attribution attribution;
};

이는 세 가지 핵심 기능을 제공한다.

• 브라우저가 지원하는 집계 서비스 목록 (§ 3.3 지원되는 집계 서비스 찾기)

• 브라우저에 노출 저장을 요청하는 수단 (§ 3.4 노출 저장)

• 전환 측정을 요청하는 메서드 (§ 3.5 전환에 대한 기여 요청)

3.3. 지원되는 집계 서비스 찾기

aggregationServices 속성에는 사용자 에이전트가 지원하는 집계 서비스 집합이 포함된다. 사이트는 measureConversion() 메서드를 호출할 때 이러한 서비스 중 하나를 선택하고 지정한다. 노출을 등록하기 전에 지원되는 서비스를 질의하는 것도 유용할 수 있지만, 반드시 필요한 것은 아니며, 노출은 단일 집계 서비스로 범위가 한정되지 않는다.

const preferredServices = [
  "https://aggregator.example/tee",
  "https://aggregator.example/dap",
  "https://example.com/aggregator",
];
const supportedServices = navigator.attribution?.aggregationServices;
const serviceUrl = preferredServices.find(url => supportedServices?.has(url));

enum AttributionAggregationProtocol { "dap-18-histogram" };

dictionary AttributionAggregationService {
  required AttributionAggregationProtocol protocol;
};

[SecureContext, Exposed=Window]
interface AttributionAggregationServices {
  readonly maplike<USVString, AttributionAggregationService>;
};

[SecureContext, Exposed=Window]
interface Attribution {
  readonly attribute AttributionAggregationServices aggregationServices;
};

aggregationServices 속성은 집계 서비스를 식별하는 URL에서 그 서비스에 대한 메타데이터로의 매핑이다.

protocol, 타입은 AttributionAggregationProtocol

집계 서비스가 사용하는 protocol. 같은 프로토콜의 서로 다른 버전은 서로 다른 값을 사용한다. 하나의 서비스 제공자가 여러 프로토콜을 지원하더라도, 각각은 서로 다른 URL을 사용해야 한다. 이는 프로토콜의 선택을 함께 지정하지 않고도 각각을 URL로 고유하게 식별할 수 있게 보장한다.

URL은 식별된 집계 서비스를 선택하기 위해 measureConversion()에 aggregationService 매개변수로 전달된다.

The AttributionAggregationProtocol는 서로 다른 집계 서비스에서 사용하는 제출 프로토콜을 설명한다. 이 문서는 하나의 프로토콜을 정의한다:

dap-18-histogram

[DAP]에 기반한 프로토콜로, MPC를 사용한다. § 6.1 다자간 계산 집계를 참조하라.

3.4. 노출 저장

saveImpression() 메서드는 사용자 에이전트가 노출을 노출 저장소에 기록하도록 요청한다.

navigator.attribution.saveImpression({
  histogramIndex: 3,
  matchValue: 2,
  conversionSites: ["advertiser.example"],
  lifetimeDays: 7,
});

dictionary AttributionImpressionOptions {
  required unsigned long histogramIndex;
  unsigned long matchValue = 0;
  sequence<USVString> conversionSites = [];
  sequence<USVString> conversionCallers = [];
  unsigned long lifetimeDays = 30;
  long priority = 0;
};

dictionary AttributionImpressionResult {
};

[SecureContext, Exposed=Window]
partial interface Attribution {
  Promise<AttributionImpressionResult> saveImpression(AttributionImpressionOptions options);
};

saveImpression()의 인수는 다음과 같다.

histogramIndex, 유형은 unsigned long

measureConversion()이 이 노출을 이후의 전환과 일치시키면, 전환 값이 이 인덱스로 식별되는 히스토그램 버킷에 추가된다.

matchValue, 유형은 unsigned long이며, 기본값은 0

노출과 연결된 선택적 메타데이터이다. 이 값은 전환으로부터 기여도를 받을 수 있는 노출을 식별하는 데 사용할 수 있다.

conversionSites, 유형은 sequence<USVString>이며, 기본값은 []

이 노출에 대한 전환이 발생할 수 있는 최상위 전환 사이트이며, 해당 도메인 이름으로 식별된다. measureConversion() 메서드는 표시된 사이트 중 하나가 호출한 경우에만 이 노출에 기여도를 부여한다. 비어 있으면 모든 전환 사이트가 일치한다.

conversionCallers, 유형은 sequence<USVString>이며, 기본값은 []

이 노출을 전환에 대해 선택할 수 있는 중개 사이트 또는 전환 사이트이며, 해당 도메인 이름으로 식별된다. measureConversion() 메서드는 표시된 사이트 중 하나가 호출한 경우에만 이 노출에 기여도를 부여한다. 이 옵션에는 전환 사이트와 중개 사이트가 모두 포함된다. 비어 있으면 API를 호출하는 모든 사이트가 일치한다.

lifetimeDays, 유형은 unsigned long이며, 기본값은 30

양의 "유효 기간"(일 단위)으로, 이 기간이 지나면 노출은 더 이상 기여도를 받을 수 없다. 사용자 에이전트는 수명에 상한을 두어야 하며, 여기에 지정된 값이 해당 상한을 초과하면 그 값을 자동으로 줄여야 한다.

priority, 유형은 long이며, 기본값은 0

기여도 부여 중 노출을 정렬하는 데 사용되는 정수이다.

3.5. 전환에 대한 어트리뷰션 요청

measureConversion() 메서드는 사용자 에이전트가 전환에 대해 어트리뷰션을 수행하고, 전환 보고서를 반환하도록 요청한다.

measureConversion() 메서드는 매칭되는 노출이 발견되는지 여부와 관계없이 항상 전환 보고서를 반환한다. 매칭이 없거나 차등 프라이버시가 어트리뷰션 보고를 허용하지 않는 경우, 반환된 전환 보고서는 히스토그램에 기여하지 않는다. 즉, 균일하게 0이 된다.

const measurement = await navigator.attribution.measureConversion({
  ...serviceDetails,
  ...aggregatedMeasurementDetails,
  ...selectionDetails,
  ...attributionDetails,
});
sendReportToServer(measurement.report);

dictionary AttributionConversionOptions {
  required USVString aggregationService;
  double epsilon = 1.0;

  required unsigned long histogramSize;

  unsigned long lookbackDays;
  sequence<unsigned long> matchValues = [];
  sequence<USVString> impressionSites = [];
  sequence<USVString> impressionCallers = [];

  sequence<double> credit;
  unsigned long value = 1;
  unsigned long maxValue = 1;
};

dictionary AttributionConversionResult {
  required Uint8Array report;
};

[SecureContext, Exposed=Window]
partial interface Attribution {
  Promise<AttributionConversionResult> measureConversion(AttributionConversionOptions options);
};

measureConversion()의 인수는 다음과 같다.

aggregationService, 형식은 USVString

집계 서비스 중에서 선택한 항목이며, aggregationServices에서 찾을 수 있다.

epsilon, 형식은 double, 기본값은 1.0

이 전환 보고서에 지출할 프라이버시 예산의 양.

histogramSize, 형식은 unsigned long

전환 보고서에서 사용할 히스토그램 버킷 수.

lookbackDays, 형식은 unsigned long

양의 정수로 나타낸 일수이다. 지난 lookbackDays 이내에 발생한 노출만 이 전환과 일치한다. 생략하면 최대 조회 기간과 동일하다.

matchValues, 형식은 sequence<unsigned long>, 기본값은 []

집합이며, 노출을 선택하는 데 사용할 수 있는 match 값들이다.

impressionSites, 형식은 sequence<USVString>, 기본값은 []

노출 사이트의 집합. 노출 사이트가 이 집합 안에 있는 곳에서 기록된 노출만 이 전환과 일치할 자격이 있다. 비어 있으면, 모든 사이트가 일치한다.

impressionCallers, 형식은 sequence<USVString>, 기본값은 []

saveImpression() API를 호출했을 수 있는 사이트의 집합이며, 노출 사이트와 중개자 사이트를 모두 포함한다. 비어 있지 않으면, 나열된 사이트 중 하나가 기록한 노출만 이 전환과 일치할 자격이 있다.

value, 형식은 unsigned long, 기본값은 1

전환 값. 기여가 이루어지고 프라이버시 제한이 만족되면, 이 값은 전환 보고서에 인코딩된다.

maxValue, 형식은 unsigned long, 기본값은 1

집계에 포함된 모든 기여에 걸친 최대 전환 값. epsilon과 함께, 결과에 추가될 랜덤 노이즈의 분포를 보정하는 데 사용된다. 또한 이 전환 보고서에 지출할 프라이버시 예산의 양을 결정하는 데에도 사용된다.

credit, 형식은 sequence<double>

전환 값이 여러 노출에 걸쳐 어떻게 할당되는지를 설명하는 유한한 양수들의 목록. 이 값은 선택된 노출 목록에 걸쳐 지정된 순서대로 목록의 값에 비례하여 분할된다. 선택된 노출 수가 이 목록의 값 수보다 적으면, 이 목록의 추가 항목은 무시된다. 없으면, 전환 값은 단일 노출에 할당된다.

3.6. 중개자의 역할

이 API는 최상위 사이트를 대신하여 중개자가 동작하는 것을 지원한다. 광고는 게재, 입찰, 측정을 책임지는 독립 운영자에게 자주 위임된다.

중개자가 저장한 노출은 중개자 사이트의 식별자를 기록한다. 전환 측정을 위해 노출을 선택할 때, 중개자 사이트 식별자를 사용하여 노출을 선택할 수 있다.

3.7. 히스토그램 구성

개념적으로, 저장된 각 노출은 단일 히스토그램 정의를 가진다. 각 노출은 단일 Histogram Index 속성을 가지며, 이는 해당 노출에 할당된 값이 결과 히스토그램에서 어디에 나타나는지를 결정한다.

따라서 measureConversion()의 각 호출은 동일한 히스토그램 정의를 가진 노출을 선택해야 한다. 이는 API의 모든 사용에 적용되지만, 히스토그램의 일관된 정의는 노출이 여러 중개자에 의해 저장되고 측정될 때 특히 중요하다.

measureConversion()을 호출할 때 선택될 수 있는 모든 노출은 동일한 히스토그램 정의를 사용해야 한다. API는 올바른 노출만 선택되도록 보장하기 위한 여러 도구를 제공한다.

저장된 노출의 경우:

• Match values를 사용하여 노출을 히스토그램 정의별로 분리할 수 있다.

• 전환을 위한 노출의 사용은 전환 사이트 집합의 measureConversion()에만 보이도록 제한될 수 있다.

• 전환을 위한 노출의 사용은 사이트 집합이 호출한 measureConversion()에만 보이도록 제한될 수 있다.

전환 시점의 공통 매칭 로직의 일부로:

• match value 집합은 노출 집합을 제한한다.

• Impression Sites 집합은 노출이 저장된 노출 사이트를 제한한다.

• Impression Callers 집합은 노출을 저장한 전환 사이트 또는 중개자 사이트의 집합을 제한한다.

이러한 옵션은 어트리뷰션이 히스토그램을 선택하는 방식에 대해 사이트에 유연성을 제공한다. 이는 전환 사이트가 서로 다른 히스토그램을 사용하는 것을 배제하지 않는다. measureConversion() 호출이 서로 다른 히스토그램 정의를 가진 노출을 절대 선택하지 않는다면, 여러 노출은 서로 다른 히스토그램 정의로 저장될 수 있다. 이는 measureConversion()을 여러 번 호출함으로써 전환이 여러 히스토그램에 귀속될 수 있도록 보장한다.

3.8. Permissions Policy 통합

중개자에게 위임할 수 있는 기능은 Permission Policy에 의해 제어된다.

이 명세는 두 개의 정책 제어 기능을 정의한다.

• saveImpression() API의 호출로, 문자열 "save-impression"로 식별된다.

• measureConversion() API의 호출로, 문자열 "measure-conversion"로 식별된다.

이 두 기능 모두에 대한 기본 허용 목록은 *이다.

saveImpression()과 measureConversion()에 대해 별도의 권한을 두면, 둘 다 수행하는 페이지가 하위 리소스를 예상되는 종류의 활동으로 제한할 수 있다.

기본적으로 권한을 활성화하면 외부 서비스를 통합하는 작업이 단순해진다.

Permissions Policy는 전부 아니면 전무 방식의 제어만 제공하며, 프라이버시 예산 일부의 위임은 가능하게 하지 않는다.

4. API 내부

4.1. 노출 저장소

노출 저장소는 measureConversion() 메서드가 일치하는 노출을 찾는 데 사용한다.

이 API는 사이트에 의한 데이터 저장을 가능하게 하지만, 노출 저장소는 storage key를 사용하지 않는다.

4.1.1. 내용

노출 저장소는 집합인 노출들이다.

4.1.2. 유지 관리

사용자 에이전트는 주기적으로 타임스탬프와 수명 값을 사용하여 노출 저장소에서 만료된 모든 노출을 식별하고 삭제해야 한다.

measureConversion()이 만료된 노출을 기여도 부여에서 제외하는 한, 노출을 만료 즉시 제거할 필요는 없다. 그러나 사용자 에이전트는 만료된 노출을 무기한 보관해서는 안 된다.

4.1.3. Clear-Site-Data 통합

`Clear-Site-Data` 필드 [CLEAR-SITE-DATA]는 사이트가 사용자 에이전트가 유지하는 상태를 제거할 수 있게 한다. `"impressions"` 타입은 인식되는 타입 목록에 추가되며, Clear Site Data § 3.1 The Clear-Site-Data HTTP Response Header Field에서 정의된다.

응답에 대한 사이트 데이터 삭제 알고리즘이 호출될 때, 타입 목록이 `"impressions"`를 포함하면, 사이트에 대한 노출 삭제가 호출되며, origin을 전달한다.

4.1.4. 사이트 이름

노출 저장소는 세 가지 유형의 사이트에 대한 정보를 저장한다. 노출 사이트, 선택적 중개자 사이트, 그리고 전환 사이트의 집합이다.

이러한 사이트는 모두 반드시 스킴 및 호스트 형식이어야 하며, 스킴은 "https"여야 한다. 이는 호스트의 단순 문자열 직렬화만으로 사이트를 식별하기에 충분하다는 의미이다. 따라서 API는 단순한 문자열을 사용하여 사이트를 나타낼 수 있다.

구현이 내부적으로 튜플의 host 부분만 사용하여 사이트를 표현하는 것도 가능하다.

4.2. 프라이버시 예산 관리를 위한 상태

사용자 에이전트는 프라이버시 예산의 지출을 관리하는 데 사용되는 여러 상태 조각을 유지한다.

• 프라이버시 예산 저장소는 각 사이트별 및 각 에포크별 프라이버시 예산의 상태를 기록한다.

• 전역 프라이버시 예산 저장소는 모든 사이트에 걸쳐 적용되는 각 에포크별 전역 프라이버시 예산의 상태를 기록한다.

• 노출 사이트 할당량 저장소는 전역 프라이버시 예산 저장소에서 소비하기 위한, 각 노출 사이트별 및 각 에포크별 할당량의 상태를 기록한다.

• 에포크 시작 시각은 에포크가 시작되는 시점을 결정하는 데 사용된다. 이 값은 measureConversion() 호출의 부수 효과로 초기화된다.

• 단일 마지막 브라우징 이력 삭제 값은 사이트에 대한 브라우징 활동이 마지막으로 삭제된 시점을 추적한다.

• 단일 어트리뷰션 예산 잠금은 불리언 플래그이며, 프라이버시 예산 저장소에 대한 동시 작업을 방지하는 데 사용된다. 그렇지 않으면 예산의 과도한 지출로 이어질 수 있다.

프라이버시 예산 저장소, 전역 프라이버시 예산 저장소, 및 노출 사이트 할당량 저장소는 프라이버시 및 안전 예산 차감에 의해 갱신된다.

노출 저장소와 마찬가지로, 프라이버시 예산 저장소와 관련 저장소는 storage key를 사용하지 않는다. 이러한 저장소에는 정보가 삭제되는 방식에 대한 몇 가지 추가 제약이 있다. 자세한 내용은 § 9.7 API 상태 삭제를 참조한다.

어트리뷰션 예산 잠금을 불리언 플래그로 정의하는 선택은 명세 작성의 편의를 위한 것이다. 구현에는 대체 구성물이 더 적합할 수 있다. 구현은 이 값을, 예를 들어 에포크별로 분할하여, 경합 범위를 줄일 수 있을지도 모른다.

4.2.1. 프라이버시 예산 저장소

프라이버시 예산 키는 다음 항목들로 구성된 튜플이다.

에포크 인덱스

에포크 인덱스

사이트

사이트

프라이버시 예산 저장소는 키가 프라이버시 예산 키이고 값이 32비트 부호 없는 정수인 맵이다. 이러한 정수는 마이크로엡실론 단위로 값을 저장한다. 마이크로엡실론은 차등 프라이버시에서 사용되는 단위 엡실론 값의 백만분의 일이다 [DP].

32비트 정수를 선택하면 엡실론 설정이 4294의 최대 엡실론 이하로 제한된다. 이는 구현에 충분하고도 남을 것으로 예상된다.

전역 프라이버시 예산 저장소는 키가 에포크 인덱스이고 값이 32비트 부호 없는 정수인 맵이며, 마이크로엡실론 단위이다.

전역 프라이버시 예산 저장소는 모든 사이트에 걸쳐 적용되고 각 에포크마다 새로고침되는 단일 프라이버시 예산의 지출을 추적한다. 이는 같은 사람에 대한 활동을 여러 사이트에 걸쳐 상관시킬 수 있는 적대자에 대한 안전 한계를 제공한다.

각 사이트별 프라이버시 예산 저장소와 달리, 전역 프라이버시 예산 저장소는 사이트가 아니라 에포크 인덱스로만 키 지정된다.

노출 사이트 할당량 저장소는 키가 프라이버시 예산 키이고 값이 32비트 부호 없는 정수인 맵이며, 마이크로엡실론 단위이다.

노출 사이트 할당량 저장소는 하나의 에포크에서 어떤 단일 노출 사이트가 기여할 수 있는 “stock” (노출과 관련된 프라이버시 예산)의 양을 제한한다. 이는 단일 노출 사이트가 악의적으로 유발될 수 있는 전역 한계에서 과도한 양을 소비하는 것을 방지한다.

4.2.2. Attribution API 활성화

Attribution API는 대략 일시적 활성화 소비 API를 본뜬 것으로, 여기서 사용자 활성화는 일시적으로 API를 사용할 수 있게 한다. 이 설계는 일시적 활성화 소비 API와 구별되는 여러 차이점이 있다:

• 다음 중 하나가 발생하면 API가 짧은 기간 동안 사용 가능해진다:

  • 사용자 활성화 이벤트가 수신되는 경우 (즉, 클릭, 키 누름 또는 유사한 동작).

  • 탐색이 사용자에 의해 시작되는 경우 (즉, 사용자 탐색 관여가 "브라우저 UI"인 경우).

• 마지막 활성화 이후 구현 정의 기간 내에 saveImpression() 또는 measureConversion()를 호출하면, 해당 사이트에서 API가 활성화된다.

• 각 활성화는 API를 최대 하나의 최상위 사이트에서 사용할 수 있게 한다. 일시적 활성화와 유사하게, 활성화를 소비하는 것이 다른 유사한 API를 또 다른 활성화가 발생할 때까지 사용할 수 없게 만드는 것처럼, 한 사이트에서 API를 사용하면 다른 사이트에서는 그 API를 사용할 수 없게 된다.

• API가 성공적으로 사용되면, API는 최상위 순회 가능 항목의 활성 문서의 모든 자손 navigable에서 사용할 수 있도록 활성화된다 (즉, 교차 사이트 프레임을 포함하여 현재 페이지의 모든 프레임이) 추가 가용성 검사 없이 API에 접근할 수 있다.

• 각 활성화는 API를 최대 하나의 사이트에서만 사용 가능하게 한다. 탐색으로 최상위 traversable이 다른 사이트로 이동하면 API가 비활성화된다. 그러나 탐색을 시작한 동작을 포함할 수도 있는 모든 활성화는 API를 다시 사용 가능하게 만들 수 있다.

이는 효과 면에서 일시적 활성화와 대체로 유사하다. 그러나 attribution 활성화는 일시적 활성화와 별도의 상태를 사용하며, 그 상태는 다르게 추적된다. Attribution 활성화 상태는 영향을 받는 Window들이 아니라, 최상위 traversable에서 추적된다. 그 결과, attribution 활성화는 탐색을 거쳐서도 유지되어, 활성화가 탐색으로 이어지는 경우 새 페이지를 로드한 후 짧은 기간 동안 API를 사용할 수 있게 한다.

별도의 상태를 두면 attribution 활성화가 일시적 활성화 소비 API와 상호작용하지 않도록 보장한다. 활성화를 소비하는 API는 Attribution API를 사용할 수 없게 만들지 않으며, 마찬가지로 Attribution API를 사용해도 일시적 활성화 소비 API를 사용할 수 없게 만들지 않는다.

별도의 상태 추적은 사용자 활성화를 소비하는 사용자 동작을 Attribution API로 독립적으로 측정할 수 있게 보장한다.

탐색을 넘어 활성화를 유지하면 광고에서 흔히 쓰이는 패턴이 가능해진다. Site는 상호작용이 발생한 site에서 또는 이후의 site에서 Attribution API를 사용하여 동작을 검사할 수 있다.

이를 구현하기 위해, 각 최상위 traversable은 Attribution API에 대해 두 가지 상태를 추적한다:

1. attribution enabled flag는 API가 활성화되어 있는지를 추적하는 boolean 값이다. 이 값은 false로 초기화된다.

2. attribution activation timestamp는 마지막 사용자 활성화를 추적하는 moment이다. 이 값은 unix epoch로 초기화된다.

구현은 또한 기여도 활성화 지속 시간을 구현 정의 지속 시간으로 구성한다. 이는 일시적 활성화 지속 시간보다 짧지 않아야 한다. 다만 내비게이션으로 인한 지연 때문에 Attribution API에 접근할 수 없게 되는 것을 방지하려면 더 큰 값이 바람직할 수 있다.

구현은 내비게이션 중 페이지 콘텐츠를 로드하는 데 수반되는 지연을 고려하여 허용 시간을 연장하도록 선택할 수 있다. 고정된 값은 기기 또는 네트워크의 성능 차이를 고려하지 못할 수 있다. 구현은 성능 특성에 대한 이해를 바탕으로 기여도 활성화 지속 시간의 값을 연장할 수 있다. 또는 구현은 페이지 로드 중에 타이머를 일시 중지할 수 있다.

4.2.3. 에포크 시작 시각

privacy budget epoch는 (또는 epoch는) 일정 기간을 식별한다. epoch의 길이는 1주 또는 7 일로 고정되며, 여기서 일은 86400 초로 정의된다.

epoch start time은 wall clock의 moment이다. epoch는 각 사용자 에이전트에 대해 무작위로 선택된 한 주의 시간에 시작된다. 이는 privacy budget이 0에 도달함으로써 발생하는 집계의 편향이 모든 사용자의 모든 기여에 걸쳐 평균화되도록 보장한다.

시작 시간은 epoch가 처음 필요해질 때 사용자 에이전트에 의해 무작위로 선택된다—​이는 현재 epoch를 얻는 알고리즘을 호출하는 부수 효과이다.

에포크 인덱스는 주어진 에포크를 참조하는 정수이다. 에포크 인덱스는 노출 및 에포크 시작 시간에 접근하는 데 사용된다.

이 명세의 알고리즘은 모두 더 추상적인 에포크가 아니라 구체적인 에포크 인덱스를 사용한다. 시간상의 시점은 현재 에포크 가져오기 알고리즘을 사용하여 해당 에포크의 에포크 인덱스로 변환된다.

4.2.4. 마지막 브라우징 이력 삭제 시각

last browsing history clear는 wall clock을 사용하는 moment이며, browsing history가 마지막으로 삭제된 때를 추적한다. last browsing history clear 값은 현재 coarse된 wall time으로 갱신된다. 이는 사용자의 요청으로 어떤 site 수준 상태가 삭제될 때 이루어진다. 이 값은 처음에는 설정되어 있지 않다.

선택적 최적화로서, 다음 모두가 true이면 last browsing history clear를 갱신하는 것을 건너뛸 수 있다:

• 삭제되는 모든 상호작용이 삭제되지 않은 다른 상호작용을 가진 site들과의 상호작용이다.

• 삭제되는 모든 상호작용이, 같은 site와의 다른 상호작용이 유지된 epoch 동안 발생했다.

• epoch start time이 설정되어 있다.

세 조건이 모두 참이면, 마지막 브라우징 기록 삭제를 업데이트할 필요가 없다. 대신 프라이버시 예산 저장소는 영향을 받는 모든 사이트와 에포크에서 형성할 수 있는 모든 프라이버시 예산 키 조합에 대해 0의 값을 설정하여 반드시 업데이트해야 한다 (해당하는 에포크 인덱스를 사용한다).

이 최적화는 사용자 에이전트가 영향을 받은 사이트와의 상호작용에 관한 정보를 영향을 받은 에포크에 보존하고 있다는 사실에 의존한다. 이는 보존된 상호작용 중 어느 것이든 예산을 소진시켰을 수 있기 때문에 가능하다. 검색 기록의 공백에 관한 정보가 노출되지 않도록 하려면 예산을 재설정해야 한다.

4.3. 노출 저장 알고리즘

암시적 API 입력은 다음 필드를 가진 구조체이다:

4.4. 전환 측정 알고리즘

measureConversion() 메서드는 비동기적으로 완료되며, Attribution task source에 작업을 queue한다.

Validated conversion options는 다음 필드를 가진 struct이다:

4.4.1. 어트리뷰션 로직

어트리뷰션 로직은 전환 값이 히스토그램 버킷에 어떻게 할당되는지를 결정한다.

4.4.2. 공통 노출 매칭 로직

4.4.2.1. Last-N-Touch 어트리뷰션

4.5. 구현 정의 값 설정

이 명세는 여러 구현 정의 값을 식별한다. 이 절에는 이러한 값을 가장 적절하게 설정하는 방법에 관한 구현에 대한 몇 가지 권고 사항이 포함되어 있다.

구현은 lifetimeDays 및 lookbackDays에 대해 구현 정의 최대 조회 기간을 설정한다. 최대 조회 기간은 양의 정수로 나타낸 일수이다. 이 두 값에 서로 다른 최댓값을 둘 필요는 없다. 두 값 중 더 작은 값이 저장된 노출 중 어떤 것이 전환에 사용 가능한지를 결정하기 때문이다.

구현은 반드시 최대 조회 기간을 최소 30일로 설정해야 한다. 이 기간 내에 구현은 각 노출 사이트당 최소 1000개의 노출을 보존하도록 노력해야 한다.

구현은 가능한 경우 시간과 개수에 대한 이러한 권장 제한을 넘어 노출을 보존해야 한다. 노출을 저장하는 데 사용할 수 있는 용량은 노출 데이터를 보존하는 데 필요한 저장 공간과 전환 보고서를 생성하는 데 필요한 처리 시간 모두에 따라 달라진다. 사이트가 사용 가능한 용량을 초과하여 노출 저장을 요청하거나, 사용자가 요청하거나(§ 9.2 Attribution API 비활성화 참조), 또는 구현 정의 이유가 있는 경우, 구현은 이러한 제한에 도달하기 전에 노출을 폐기할 수 있다.

구현이 노출을 보존하지 않기로 선택할 수 있는 한 가지 가능한 이유는 해당 사이트가 충분한 사용자 참여를 얻지 못했기 때문이다.

saveImpression() 및 measureConversion()에 전달되는 사이트 목록에 대해 구현 정의 값이 선택된다. 노출당 최대 전환 사이트 수는 conversionSites 값의 개수에 대한 제한이며, 구현은 반드시 이 값을 최소 5로 설정해야 한다. 노출당 최대 전환 호출자 수 및 전환에 대한 최대 노출 호출자 수는 각각 conversionCallers 및 impressionCallers 값의 개수에 대한 제한이며, 구현은 반드시 이 값들을 각각 최소 10으로 설정해야 한다. 전환에 대한 최대 노출 사이트 수는 impressionSites 값의 개수에 대한 제한이며, 구현은 반드시 이 값을 최소 30으로 설정해야 한다.

최대 크레딧 값 수에 대해 구현 정의 값이 선택되며, 이는 credit 값의 개수에 대한 제한이다. 구현은 반드시 이 값을 최소 10으로 설정해야 한다. 최대 일치 값 수에 대해 구현 정의 값이 선택되며, 이는 matchValues 값의 개수에 대한 제한이다. 구현은 반드시 이 값을 최소 30으로 설정해야 한다.

measureConversion()이 생성하는 히스토그램의 크기는 구현 정의 최대 히스토그램 크기와 최대 집계 서비스 히스토그램 크기 모두의 제한을 받는다. 집계 기술의 선택이 제한을 설정할 것으로 예상되므로 최대 히스토그램 크기에는 최솟값이 설정되지 않는다. 최대 집계 서비스 히스토그램 크기는 집계 서비스가 사용하는 기술의 선택에 의해 결정되는 고정된 값이며, 구현 정의가 아니다.

4.5.1. 프라이버시 및 안전 한계 매개변수 구성

사용자 에이전트는 다음에 대한 값을 정의하여 privacy budget 및 safety limit을 구성한다:

• 사이트별 프라이버시 예산 (ε_site)은 구현 정의이다. 차등 프라이버시 집계에 대한 실험에서는 1(더 높은 프라이버시)에서 10(더 높은 성능) 사이 범위의 값으로 합리적인 성능을 달성할 수 있음이 확인되었다.

• 에포크당 전역 프라이버시 예산 (ε_global)은 각 사이트에서 에포크당 사용할 수 있는 최대 프라이버시 예산이며, 마이크로엡실론으로 지정된다. 구현은 이 값을 각 사이트의 프라이버시 예산의 에포크당 배수로 설정해야 한다.

• 에포크당 노출 사이트 할당량 (ε_imp-quota)은 하나의 노출 사이트가 전역 프라이버시 예산에서 에포크당 소비되도록 할 수 있는 최대 프라이버시 예산이며, 마이크로엡실론으로 지정된다. 구현은 이 값을 각 사이트의 프라이버시 예산의 에포크당 배수로 설정해야 한다.

사이트별 사이트 예산의 배수로 안전 제한을 구성하면 여러 사이트에서 API를 어떻게 사용할 수 있는지가 결정된다. 이 배수를 설정할 때, 구현은 예산을 사용할 것으로 예상되는 사이트 수를 고려해야 하며, 예산을 완전히 사용하지 않는 사이트를 고려하여 그 수를 낮춰 조정할 수도 있다.

사이트별 사이트 예산의 배수로 안전 제한을 설정하면 공유 제한을 소진하려면 많은 사이트의 협력이 필요하게 되어, 이러한 제한은 주요 프라이버시 메커니즘이라기보다 악용을 방지하기 위한 수단으로 주로 유용하게 된다.

5. HTTP API

5.1. 노출 저장

`Save-Impression`은 사용자 에이전트가 saveImpression() API를 호출하도록 요청하는 response에 설정되는 Dictionary Structured Header이다.

Save-Impression: histogram-index=3, match-value=2, conversion-sites=("advertiser.example"), lifetime-days=7

다음 key가 정의되며, 이는 saveImpression()에 전달되는 AttributionImpressionOptions dictionary의 member에 대응한다. 생략된 선택적 key에 대한 기본값은 대응하는 AttributionImpressionOptions field와 같은 방식으로 취급된다. 알 수 없는 dictionary key는 무시되며, 알 수 없는 parameter도 마찬가지다.

conversion-sites

conversionSites의 값으로, 문자열을 포함하는 inner list이다. 각 문자열 값은 A-label만 사용하는 도메인 이름을 포함한다. 따라서 국제화 도메인 이름은 punycode를 사용해야 한다. 이 키는 선택 사항이다.

conversion-callers

conversionCallers의 값으로, 문자열을 포함하는 inner list이다. 각 문자열 값은 A-label만 사용하는 도메인 이름을 포함한다. 따라서 국제화 도메인 이름은 punycode를 사용해야 한다. 이 키는 선택 사항이다.

histogram-index

histogramIndex의 값으로, 32비트 부호 없는 정수 범위의 정수이다. 이 키는 필수이다.

priority

priority의 값으로, 32비트 부호 있는 정수 범위의 정수이다. 이 키는 선택 사항이다.

match-value

matchValue의 값으로, 32비트 부호 없는 정수 범위의 정수이다. 이 키는 선택 사항이다.

lifetime-days

lifetimeDays의 값으로, 양의 정수이다. 이 키는 선택 사항이다.

5.2. 전환 측정

`Measure-Conversion`은 사용자 에이전트가 measureConversion() API를 호출하도록 요청하는 response에 설정되는 Dictionary Structured Header이다.

Measure-Conversion: aggregation-service="https://aggregator.example/tee", histogram-size=20, epsilon=1.0, lookback-days=14, impression-sites=("publisher.example" "other.example"), impression-callers=("ad-tech.example"), match-values=(2), credit=(0.25 0.25 0.5), value=3, max-value=7, report-url="https://report-handler.example/foo"

다음 key가 정의되며, 이는 measureConversion()에 전달되는 AttributionConversionOptions dictionary의 member에 대응한다. 생략된 선택적 key에 대한 기본값은 대응하는 AttributionConversionOptions field와 같은 방식으로 취급된다. 알 수 없는 dictionary key는 무시되며, 알 수 없는 parameter도 마찬가지다.

aggregation-service

aggregationService의 값으로, 문자열이다. 이 키는 필수이다.

epsilon

epsilon의 값으로, 양의 decimal 또는 정수이다. 이 키는 선택 사항이다.

histogram-size

histogramSize의 값으로, 양의 정수이다. 이 키는 필수이다.

lookback-days

lookbackDays의 값으로, 양의 정수이다. 이 키는 선택 사항이다.

match-values

matchValues의 값으로, 음이 아닌 정수를 포함하는 inner list이다. 이 키는 선택 사항이다.

impression-sites

impressionSites의 값으로, 문자열을 포함하는 inner list이다. 각 문자열 값은 A-label만 사용하는 도메인 이름을 포함한다. 따라서 국제화 도메인 이름은 punycode를 사용해야 한다. 이 키는 선택 사항이다.

impression-callers

impressionCallers의 값으로, 문자열을 포함하는 inner list이다. 각 문자열 값은 A-label만 사용하는 도메인 이름을 포함한다. 따라서 국제화 도메인 이름은 punycode를 사용해야 한다. 이 키는 선택 사항이다.

credit

credit의 값으로, 양의 decimal 또는 양의 정수를 포함하는 inner list이다. 이 키는 선택 사항이다.

value

value의 값으로, 양의 정수이다. 이 키는 선택 사항이다.

max-value

maxValue의 값으로, 양의 정수이다. 이 키는 선택 사항이다.

report-url

결과 보고서가 있는 경우 해당 보고서가 POST될 잠재적으로 신뢰할 수 있는 URL을 포함하는 문자열이다. URL은 응답 URL을 기준으로 상대적일 수 있다. 해당 스킴은 반드시 "https"여야 한다. 이 키는 필수이다.

5.3. Fetch 몽키 패치

HTTP-network fetch를 다음과 같이 수정한다:

6. 집계

집계 서비스는 여러 개의 어트리뷰션 정보를 받아 집계 지표를 생성한다.

사용자 에이전트 구현체마다 집계에 대한 요구사항은 서로 다를 것이다. 하지만 집계 과정에는 몇 가지 공통 요소가 있다.

첫째, 사용자 에이전트는 집계 서비스에 대한 정보를 설정받거나, 아니면 다른 방식으로 얻어야 한다. 여기에는 지원되는 집계 메서드와 필요한 모든 설정이 포함된다.

각 집계 메서드는 히스토그램이 어떻게 다음과 같이 처리되는지를 정의해야 한다:

• 집계를 위해 준비되고,

• 암호화되고,

• 필요한 메타데이터로 주석 처리되고, 그리고

• 집계를 위해 집계 서비스에 제출되는지.

또한 집계 메서드는 사이트가 집계 결과를 어떻게 얻는지도 정의해야 한다.

6.1. 다자간 계산 집계

다자간 계산 (MPC) 시스템은 여러 독립 엔티티가 관여하여 합의된 함수를 협력적으로 계산하는 시스템이다.

이 명세는 Prio [PRIO] 및 분산 집계 프로토콜(Distributed Aggregation Protocol, DAP) [DAP]에 기반한 MPC 시스템을 사용한다. 이는 두 당사자 MPC 시스템으로, 입력의 정확성에 대해 클라이언트가 제공하는 증명에 의존한다는 특징이 있다. 이를 통해 시스템에 제출되는 데이터의 크기가 다소 증가하는 비용으로 매우 효율적인 MPC 동작이 가능하다.

MPC를 사용하는 집계 서비스는 미리 정의된 함수를 계산하기 위해 협력하는 두 개 이상의 독립 서비스로 구성된다.

MPC가 제공하는 기본 보장은 함수의 정의된 출력과 명확히 정의된 누출만이 어떤 엔티티에게도 공개된다는 것이다.

MPC 보장은 참여 엔티티의 일부가 정직한 경우에 한해서만 유지된다. Prio에서 사용되는 두 당사자 MPC의 경우, 프라이버시—​즉 입력의 기밀성—​는 어느 한 MPC 운영자가 정직하게 남아 있는 한 유지된다. 이 MPC 구성은 어느 MPC 운영자에 의한 출력 손상은 방지하지 않는다.

6.1.1. Prio 및 DAP

dap-18-histogram 집계 메서드는 Prio [PRIO] 및 분산 집계 프로토콜(DAP) [DAP]을 사용한다. 구체적으로 이 집계 메서드는 Prio3L1BoundSum [PRIO-L1] 검증 가능한 분산 집계 함수(Verifiable Distributed Aggregation Function, VDAF) [VDAF]를 사용한다.

DAP 및 Prio3L1BoundSum 인스턴스화는 보고서가 어떻게 준비되고, 암호화되며, 집계를 위해 제출되는지를 정의한다. 또한 DAP는 집계값이 어떻게 얻어지는지와 사용자 에이전트가 집계 서비스에 대해 어떤 설정 정보를 얻어야 하는지도 정의한다.

Prio3L1BoundSum을 사용할 때, 보고서에는 MPC에 참여하는 노드들이 제출된 히스토그램의 합이 설정된 값보다 작다는 것을 확인할 수 있게 해 주는 분산 영지식 증명이 포함된다. Prio3L1BoundSum은 히스토그램 합이 2의 거듭제곱보다 엄격히 작다는 것만 검증할 수 있다. 즉, 증명은 양의 정수 값 n에 대해 합이 2ⁿ보다 작다는 것을 확인한다.

보고서를 구성하기 위해, maxValue보다 큰 다음 2의 거듭제곱 값에 기반하여 증명이 생성된다. 이는 집계 서비스가 maxValue와 다음 2의 거듭제곱 사이의 보고서를 거부할 수 없음을 의미한다. 따라서 악의적인 사용자 에이전트는 집계 히스토그램에 maxValue 값의 최대 두 배까지 기여하는 보고서를 생성할 수 있다. 증명은 maxValue가 2ⁿ − 1과 같을 때 초과 기여의 기회가 없음을 보장한다; 그러한 공격의 상대적 효과는 다른 제약이 허용하는 범위 내에서 maxValue를 2ⁿ − 1에 최대한 가깝게 설정함으로써 줄일 수 있다.

6.1.2. DAP 확장

DAP에 대한 확장 [DAP-ATTRIBUTION]은 이 애플리케이션에 필요하다:

• 수집자 신원 (collector_identity)은 집계 요청을 담당하는 엔티티를 식별한다. 이 확장의 값은 API 호출자의 신원을 인코딩하며, 이는 중개 사이트 또는 전환 사이트일 수 있다. 수집자 신원 확장은 전체 DAP 작업에 적용된다.

• 예산 출처 (budget_source)는 프라이버시 예산을 소비한 엔티티를 식별한다. 이 확장의 값은 전환 사이트의 신원을 인코딩한다. 예산 출처 확장은 전체 DAP 작업에 적용된다.

• 프라이버시 예산 (privacy_budget)은 집계 서비스가 집계 작업에 설정된 것보다 더 적은 프라이버시 예산을 받은 보고서를 집계하지 않도록 보장한다. 프라이버시 예산 확장은 각 보고서에 적용된다.

사용자 에이전트는 이러한 확장을 사용하여 자신이 생성하는 보고서를 구성한다.

6.1.3. DAP용 보고서 암호화

6.2. 재전송 공격 방지 요구사항

브라우저가 생성한 전환 보고서는 보고서를 요청한 사이트가 소비한 프라이버시 예산의 양에 바인딩된다.

집계 서비스는 동일한 보고서를 두 번 이상 수락하지 않음을 반드시 보장해야 한다.

7. 차등 프라이버시

이 설계는 프라이버시 설계의 기반으로 차등 프라이버시 개념을 사용한다. [PPA-DP]

차등 프라이버시는 시스템이 공개하는 개인 정보의 양을 보장할 수 있는 프라이버시에 대한 수학적 정의이다. [DP] 차등 프라이버시는 이 시스템에서 프라이버시가 보호되는 유일한 수단은 아니지만, 가장 엄밀하게 정의되고 분석된 수단이다. 따라서 가장 강한 프라이버시 보장을 제공한다.

차등 프라이버시는 집계된 데이터셋에 대한 개인 데이터 기여를 숨기기 위해 무작위 노이즈를 사용한다. 노이즈의 효과는 데이터셋에 대한 개별 기여를 숨기면서도, 집계 분석의 유용성은 유지하는 것이다.

차등 프라이버시를 적용하려면, 어떤 정보가 보호되는지를 정의할 필요가 있다. 이 시스템에서 보호되는 정보는 단일 사용자 프로필의 노출이며, 단일 사용자 에이전트에서, 단일 에포크 동안, 전환을 등록하는 단일 웹사이트에 대한 것이다. § 7.1 프라이버시 단위는 이 설계의 함의를 더 자세히 설명한다.

이 어트리뷰션 설계는 개별 차등 프라이버시라고 하는 차등 프라이버시의 한 형태를 사용한다. 이 모델에서 사용자 에이전트는 각각 자신이 기여하는 정보를 제한하도록 보장할 별도의 책임을 진다.

이 API의 개별 차등 프라이버시 설계에는 세 가지 주요 구성 요소가 있다:

1. 사용자 에이전트는 (프라이버시 예산을 사용하여) 노출에 관한 정보 중 전환 보고서를 통해 기기를 벗어나는 양을 제한한다. § 7.2 프라이버시 예산은 이를 더 깊이 살펴본다.

2. 집계 서비스는 임의의 주어진 전환 보고서가 사용자 에이전트가 그 보고서에 대해 계산한 프라이버시 예산에 따라서만 사용되도록 보장한다. § 6.2 재전송 공격 방지 요구사항은 집계 서비스에 대한 요구사항을 더 자세히 설명한다.

3. 노이즈는 집계 서비스가 추가한다. § 7.3 차등 프라이버시 메커니즘은 사용될 수 있는 메커니즘을 자세히 설명한다.

이러한 조치들은 함께 각 프라이버시 단위에 대해 공개되는 정보에 제한을 둔다.

7.1. 프라이버시 단위

차등 프라이버시 구현에는 무엇이 보호되는지에 대한 명확한 정의가 필요하다. 이는 프라이버시 단위로 알려져 있으며, 프라이버시 보호를 받는 엔티티를 나타낸다.

이 시스템은 세 값의 조합인 프라이버시 단위를 채택한다:

1. 사용자 에이전트 프로필. 즉, 한 사람이 사용하는 사용자 에이전트의 인스턴스이다.

2. 노출에 관한 정보를 요청하는 사이트 (전환 사이트).

   노출을 등록하는 사이트(노출 사이트)는 고려되지 않는다. 이러한 사이트는 이 시스템으로부터 직접 정보를 받지 않는다.

3. 현재 에포크.

이 값들 중 하나가 변경되면 새로운 프라이버시 단위가 생성되며, 그 결과 별도의 프라이버시 예산이 생긴다. 사람이 방문하는 각 사이트는 각 에포크마다 제한된 양의 정보를 받는다.

이상적으로 프라이버시 단위는 한 사람이다. 이상적이기는 하지만, 여러 이유로 한 사람과 완벽하게 대응됨을 보장하는 유용한 시스템을 개발하는 것은 불가능하다:

• 사람들은 종종 조정 없이 여러 브라우저와 여러 기기를 사용한다.

• 모든 웹사이트를 포괄하는 단위는 한 사이트에 의해 소진되어, 다른 사이트가 어떠한 정보도 얻지 못하게 할 수 있다.

• 광고는 지속적인 활동이다. 새 데이터에 대해 프라이버시 예산을 할당하지 않으면, 사이트는 자신의 예산을 영구히 소진할 수 있다.

7.1.1. 프라이버시 속성 및 그 한계에 대한 형식적 분석

Attribution의 프라이버시 보호는 여러 계층으로 구성된다.

1. 사이트별 예산은 하나의 전환 사이트가 사용자에 대해 알아낼 수 있는 정보의 양을 제한한다.

2. 전역 예산은 모든 사이트가 사용자에 대해 알아낼 수 있는 정보의 양에 대한 최종적인 제한을 제공한다.

3. 노출 사이트 할당량은 전환 사이트가 하나의 노출 사이트에서 사용자의 활동에 대해 알아낼 수 있는 정보의 양을 제한한다.

4. 각 사용자 동작 후 유지되는 카운터는 데이터를 API에 저장하거나 API로부터 정보를 얻을 수 있는 사이트 수를 제한한다.

이 명세의 공식적인 프라이버시 분석은 두 논문을 기반으로 한다. 첫 번째 [PPA-DP]는 온디바이스 개별 DP 회계에 대한 이론을 확립한다. 두 번째 [PPA-DP-2]는 분석을 사이트별 예산과 전역 예산이 제공하는 수학적 프라이버시 보장으로 확장한다.

사이트별 예산은 주요 프라이버시 보호 수단으로 볼 수 있다. 사이트별 예산은 의미 있는 DP 보장을 제공하도록 구성해야 한다. 그러나 [PPA-DP-2]의 분석에서는 이러한 보장을 제한하는 두 가지 가정을 식별했다.

1. 데이터 생성에서 사이트 간 적응성이 없어야 함. 사이트의 질의 가능한 데이터 스트림(노출 및 전환)은 다른 사이트의 과거 DP 기여도 결과와 독립적으로 생성되어야 한다.

2. 사이트 간 공유 제한을 통한 누출이 없어야 함. 한 사이트의 질의는 다른 사이트로 어떤 보고서가 전송되는지에 영향을 주어서는 안 된다.

요약하면, 실제로는 어느 가정도 성립할 수 없다.

사이트 간 적응성이 없다는 가정이 필요한 이유는 시스템에 시간이 지남에 따라 동일한 사용자와 상호작용할 수 있는 여러 사이트가 관여하기 때문이다. 사이트는 서로의 DP 측정값을 기반으로 사용자에게 표시하는 광고를 변경한다. 예를 들어 한 광고주가 기여도 결과를 통해 더 나은 광고를 만드는 방법을 알아낸다면, 일부 사용자는 경쟁사 대신 해당 사이트에서 전환할 수 있다. 이 경우 한 사이트가 알아낸 정보는 -- 해당 사이트의 자체 사이트별 예산에만 계산되지만 -- 경쟁사에 보이는 데이터(또는 데이터의 부재)를 변경한다. 하지만 이는 해당 경쟁사의 사이트별 예산에는 반영되지 않는다.

지속적인 측정을 제공하는 모든 시스템에는 이러한 속성이 있으므로, 결론은 이 제한을 받아들이는 것뿐이다. 이 제한은 전역 DP 예산과 공유 할당량을 두는 근거 중 일부이며, 이는 두 번째 가정으로 이어진다.

여러 사이트에 걸친 공유 제한이 있는 경우 사이트 간 누출이 없다는 가정이 필요하다. 이러한 공유 제한의 예로는 전역 DP 보장을 제공하는 것을 목표로 하는 전역 안전 제한이 있다. 일부 사이트의 measureConversion() 요청으로 인해 공유 제한에 도달하면 다른 사이트에 대한 보고서가 필터링될 수 있다. 예를 들어 자신에게 노출이 있음을 알고 있는 사이트는 공유 제한에 도달했는지 여부에 관한 정보를 얻는다. 이 정보는 집계되고 노이즈가 추가되지만, 예산을 소진한 사이트에 관한 정보이며 해당 사이트의 사이트별 예산을 초과하는 정보이다.

공유 제한을 통한 누출은 그러한 제한을 남용을 제한하는 수단으로만 사용해야 하는 근거가 된다. 공유 제한을 사이트별 예산의 큰 배수로 설정하면 공유 제한을 악용하려면 최소한 그만큼 많은 사이트의 협력이 필요하게 된다. 배수가 클수록 공유 제한은 프라이버시 보호 수단으로서는 덜 유용해지고 서비스 거부 또는 이와 유사한 형태의 남용을 방지하는 수단으로 더 적합해진다.

반면 분석에 따르면 전역 예산은 이러한 제한 없이 타당한 전역 개별 DP 보장을 제공하도록 구현할 수 있다. 그러나 많은 사이트에서 API 사용을 지원하려면 전역 예산을 사이트별 예산의 상당히 큰 배수로 구성해야 한다. 이는 전역 예산이 제공하는 DP 보장이 어떠한 가정에도 의존하지 않지만, 그것만으로는 의미 있는 DP 보호를 제공할 수 없음을 의미한다. 따라서 사이트별 예산이 주요 DP 보장을 제공한다. 전역 예산은 악의적인 사이트의 조직적인 공격이 발생할 경우를 위한 대체 보호 수단으로 볼 수 있다.

전역 DP 예산은 또한 여러 사이트에서 사용자 신원을 연결하여 사이트별 예산을 결합할 수 있는 사이트에 대해서도 보호한다. 사이트별 모델은 이러한 가능성을 고려하지 않지만, 일부 사이트가 이러한 기능을 보유하는 것은 일반적이다. 특히 여기에는 신원 제공자, 사용자 식별자(예: 이메일 주소 또는 전화번호)를 수신하는 사이트, 내비게이션 추적을 성공적으로 사용하는 사이트 [NAV-TRACKING-MITIGATIONS], 그리고 어떤 이유로든 사이트 간 쿠키를 사용할 수 있는 사이트 [WEB-WITHOUT-3P-COOKIES]가 포함된다. 여러 사이트에서 Attribution을 사용하면 이러한 사이트에 협력상의 어려움이 생길 수 있지만, 사이트가 활동을 한 개인에게 연결할 수 있는 가능성은 시스템의 프라이버시에 대한 어떠한 종합적인 분석에서도 무시할 수 없다.

7.1.2. 브라우저 인스턴스

각 브라우저 인스턴스는 별도의 프라이버시 예산을 관리한다.

브라우저 인스턴스 간 조정은 가능할 수 있지만, 기대되지는 않는다. 그러한 조정은 공개되는 정보의 총량을 줄임으로써 프라이버시를 개선할 수 있다. 또한 한 브라우저 인스턴스의 노출이 다른 인스턴스에서 전환되도록 허용함으로써 어트리뷰션의 유용성을 개선할 수도 있다.

서로 다른 구현 간의 조정은 현재 이 작업의 범위를 벗어난다. 구현은 같은 사람을 위한 것으로 알려진 인스턴스 간에 일부 조정을 수행할 수 있지만, 이는 필수는 아니다.

7.1.3. 사이트별 제한

웹사이트에 공개되는 정보는 사이트를 기준으로 이루어진다. 이는 다른 프라이버시 관련 기능에서 사용되는 동일한 경계와 일치한다.

출처와 같은 더 세분화된 프라이버시 단위는 추가 정보를 얻는 것을 사소하게 만들 것이다. 같은 사람에 관한 정보가 여러 출처에서 수집될 수 있다. 그런 다음 그 정보는 쿠키 [COOKIES] 또는 유사한 것을 사용하여 사이트 내 정보의 자유로운 흐름을 악용함으로써 결합될 수 있다.

§ 7.2.2 안전성 제한은 이 제한을 악용하는 공격과 그러한 공격으로부터 보호하기 위해 사용자 에이전트가 구현할 수 있는 일부 추가 안전성 제한을 논의한다.

7.1.4. 프라이버시 예산 에포크

사이트는 각 프라이버시 예산 에포크 (또는 에포크)에 기록된 노출을 질의하는 데 사용되는 별도의 차등 프라이버시 예산을 받는다.

이 예산은 사용자 에이전트에 등록되고 나중에 질의되는 노출에 적용되며, 전환에는 적용되지 않는다.

분석 [PPA-DP]의 관점에서 노출의 각 에포크는 별도의 데이터베이스를 형성한다. 유한한 프라이버시 예산이 각 데이터베이스에 대해 이루어지는 모든 질의에 걸쳐 적용된다.

여러 에포크에 걸친 노출에서 생성된 전환 보고서를 가지는 것은 프라이버시상 결과를 가진다. 웹사이트를 한 번 방문하는 것만으로도 그 사이트는 많은 에포크에 걸친 활동에 대한 정보를 얻을 수 있다. 이를 위해서는 해당 전체 기간 동안 전환 사이트가 노출의 대상으로 식별되어 있기만 하면 된다. 질의될 수 있는 에포크의 수는 사용자 에이전트가 제한한다.

목표는 가능한 한 큰 에포크를 설정하는 것이다. 더 긴 기간은 프라이버시/유용성의 균형을 더 좋게 한다. 사이트가 어느 시점에서든 더 큰 전체 예산을 할당받을 수 있으면서도, 전체 프라이버시 손실률을 낮게 유지할 수 있기 때문이다. 그러나 더 긴 간격은 프라이버시 예산을 완전히 소진하기 쉽게 만들어, 다음 갱신까지 아무 정보도 얻지 못하게 할 수 있다.

에포크 기간을 일주일로 설정하기로 한 결정은 대체로 임의적이다. 일주일은 사이트가 며칠 또는 몇 주 뒤에 발생할 수 있는 변화까지 고려해야 하는 세심한 계획 없이도 프라이버시 예산을 어떻게 사용할지 결정할 어느 정도의 유연성을 제공하기에 충분할 것으로 기대된다.

§ 7.2 프라이버시 예산은 예산 책정 절차를 더 자세히 설명한다.

7.2. 프라이버시 예산

브라우저는 프라이버시 예산을 유지하며, 이는 프라이버시 손실의 양을 제한하는 수단이다.

이 명세는 그 기반으로 개별 형태의 (ε, δ)-차등 프라이버시를 사용한다. 이 모델에서 프라이버시 손실은 ε 값을 사용하여 측정된다. δ 값은 집계에 노이즈를 추가할 때 집계 서비스가 처리한다.

각 사용자 에이전트 인스턴스는 프라이버시 예산을 관리할 책임이 있다.

요청되는 각 전환 보고서는 보고서가 소비하는 프라이버시 예산의 양을 나타내는 ε 값과 전환 보고서에서 반환될 수 있는 값의 최댓값을 지정한다.

7.2.1. 프라이버시 예산 차감

전환 보고서에 대한 노출을 검색할 때, 사용자 에이전트는 해당 노출이 저장된 프라이버시 예산 에포크의 예산에서 지정된 ε 값을 차감한다. 해당 에포크의 프라이버시 예산이 충분하지 않으면, 그 에포크의 노출은 사용되지 않는다.

전환 사이트가 measureConversion()을 호출할 때마다, 어트리뷰션 로직이 노출을 선택한 에포크에 대해 프라이버시 예산이 차감된다.

사용자 에이전트가 프라이버시 예산의 소진을 어떻게 관리하는지는 선택된 어트리뷰션 로직에 따라 달라진다.

7.2.2. 안전성 제한

기본 프라이버시 단위는 여러 사이트에 걸쳐 같은 사람의 활동을 상호 연관시킬 수 있는 공격자에게 취약하다.

사이트 그룹은 때때로 공유 소유권이나 강한 합의가 있는 경우처럼 자신의 활동을 조정할 수 있다. 어떤 특정 방문자가 동일한 사람임을—​FedCM [FEDCM] 같은 것을 포함한 어떤 수단으로든—​확신할 수 있는 사이트 그룹은 이 API에서 얻은 정보를 결합할 수 있다.

이는 어트리뷰션에서 사이트가 정보를 얻는 속도를 조정이 발생하는 사이트 수에 비례하여 증가시키는 데 사용될 수 있다. 기본 프라이버시 단위는 이러한 방식으로 공개되는 정보에 어떠한 제한도 두지 않는다.

이 효과에 대응하기 위해, 사용자 에이전트는 사이트를 고려하지 않는 추가 프라이버시 예산인 안전성 제한을 구현할 수 있다. 안전성 제한은 사이트별 예산보다 상당히 높을 수 있으므로, 대부분의 일반적인 브라우징 활동에서는 도달하지 않는다. 목표는 그것들이 집중적인 활동이나 공격을 받는 경우에만 효과적이도록 보장하는 것이다.

사이트별 프라이버시 예산과 마찬가지로, 사이트가 자신의 전환 보고서 요청이 안전성 제한을 초과하게 했는지 여부를 판별할 수 없어야 한다는 점이 매우 중요하다.

7.3. 차등 프라이버시 메커니즘

차등 프라이버시 메커니즘—​즉 노이즈가 추가되는 구체적인 방법—​은 집계 서비스가 선택할 수 있다.

라플라스 노이즈를 추가하면 좋은 결과를 얻을 것으로 예상되며, 전체적인 노이즈의 크기와 구현 및 분석의 단순성 사이에서 균형을 이룬다. 현재 설계는 L1 노름에 기반한 DP 민감도를 사용하며, 이는 집계에 추가되는 라플라스 노이즈를 지원한다. 다른 노이즈 메커니즘을 지원하려면 민감도를 계산하고 전달하는 방식에 추가 변경이 필요할 수 있다.

이러한 집계 서비스에 대해 정의된 것처럼, 중앙 위치에서 노이즈를 추가하면 총 보고서 수가 증가해도 총 노이즈 양이 증가하지 않는다. 이는 보고서가 생성되는 지점에서 노이즈를 적용하는 차등 프라이버시 설계 (즉 로컬 차등 프라이버시 모델)에 비해 유용성 측면의 이점을 제공한다. 그런 설계에서는 노이즈가 총 보고서 수에 비례하여 증가한다.

8. 보안 고려사항

8.1. 노출 저장소

Attribution API가 사용하는 노출 저장소는 브라우징 활동과 관련된 정보를 보유하고 브라우징 세션 간에 지속된다. 노출 저장소를 통한 정보 흐름은 엄격하게 제어되지만, 일부 정보는 출처 간에 운반된다.

다음 조치들은 노출 저장소를 통한 유해한 정보 흐름의 가능성을 제한한다:

• 웹사이트는 노출 저장소에서 읽을 수 없다. 노출 저장소의 정보는 암호화된 전환 보고서를 통해서만 공개된다. 사용자 에이전트와 집계 서비스의 기능 조합으로 제공되는 차등 프라이버시는 집계 서비스가 출력한 집계 정보가 어떤 사용자의 기여도 없는 경우의 값과 구별될 확률에 대해 엄밀한 한계를 제공한다.

• 사용자는 저장된 노출을 명시적으로 지울 수 있다.

• 사용자 에이전트가 명시적인 사용자 동작이 없더라도 lifetimeDays의 최댓값을 부과함으로써, 데이터가 노출 저장소에 지속될 수 있는 기간을 제한할 것을 권장한다.

8.2. 구현에서의 사이드 채널 위험

Attribution API를 구현하려면 필요한 보안 및 프라이버시 속성을 유지하도록 주의해야 한다. API를 호출하는 사이트는 다음을 알 수 없다.

• Attribution API가 활성화되어 있는지 여부.

• 어트리뷰션이 발생했는지 여부.

• 프라이버시 예산이 소진되었는지 여부.

• 전환 보고서가 0이 아닌 전환 값을 반영하는지 여부.

• 어떤 histogramIndex가 전환 값에 할당되는지.

• 에포크가 시작되는 시간.

명시적인 반환 값이나 throw된 예외만이 사이트가 Attribution API로부터 정보를 얻을 수 있는 유일한 방법은 아니라는 점에 유의한다. 다음과 같은 사이드 채널에서 민감한 정보를 추론할 수 있을 가능성이 있다.

• API가 완료되는 데 걸리는 시간의 변동.

• 메모리, 스토리지, 네트워크, CPU와 같은 공유 리소스를 API가 소비하는 것. 여기에는 해당 소비에 대한 제한의 적용이 사이트에서 관찰될 수 있는 경우 그 적용도 포함된다.

API의 함수 실행 시간 변동은 보장을 유지하기 위한 주요 고려 사항이다. 실행 시간과 관련하여 특히 우려되는 두 가지 요소가 있다.

• measureConversion()이 처리하는 노출의 수. 사이트는 저장되는 노출의 수와 이를 선택하는 로직을 제어하므로, 이는 사이트가 사이트 간 타이밍 사이드 채널을 생성할 수 있는 상당한 노출 가능성을 만든다.

• 공유 전역 상태에 대한 접근. API에 대한 동시 접근은 정확성 오류를 방지하기 위해 단일 기여도 예산 잠금에 의해 관리된다. 해당 잠금은 API에 동시에 접근하는 사이트 사이에서 정보가 누출될 수 있는 수단을 만든다.

전역 프라이버시 예산 저장소, 노출 사이트 할당량 저장소, 그리고 에포크 시작 시간의 공유 전역 상태는 이러한 값이 알고리즘 실행 시간에 직접 영향을 주지 않으므로 위험이 더 적다. 구현은 여전히 어떠한 전역 상태도 브라우저 핑거프린트 또는 기타 정보 누출에 기여하지 않도록 보장해야 한다.

모든 사이드 채널을 완전히 제거하는 것은 현실적으로 어렵지만, 구현은 기여도 API에서 민감한 정보가 누출되는 것을 방지하기 위해 합리적인 노력을 반드시 해야 한다. 누출을 방지하기 위한 전략에는 다음이 포함된다.

• API가 비활성화되어 있는 경우에도 모든 API 입력을 완전히 검증한다.

• 조건부 로직을 피한다. 예를 들어, measureConversion()은 보고할 전환 값이 0인 경우에도 항상 전환 보고서를 구성하는 전체 과정을 거칠 수 있다.

• 특정 작업에 고정된 실행 시간을 설정한다.

8.3. 집계 서비스

웹 플랫폼의 일부는 아니지만, 집계 서비스의 보안은 Attribution 메커니즘의 전반적인 보안에 매우 중요하다. 전환 보고서는 measureConversion()에 의해 생성되며 집계 서비스의 암호화 키를 사용하여 암호화된다. 따라서 이러한 보고서에 포함된 정보가 공개될 가능성의 상당 부분은 집계 서비스의 세부 사항에 따라 달라진다.

사용자 에이전트 개발자는 Attribution API에서 지원되는 서비스로 추가하기 전에 집계 서비스의 설계와 집계 서비스 운영자의 신뢰성을 신중하게 고려해야 한다. 이러한 문제에 대한 추가 논의는 § 6 집계 및 § 9 프라이버시 고려 사항에서 확인할 수 있다.

8.4. 여러 사이트의 보고서 결합

Attribution API의 프라이버시 메커니즘은 주로 사이트 단위로 작동한다. 악의적인 운영자는 여러 사이트에 대해 노출을 등록하려고 시도하여, 그렇지 않았다면 어트리뷰션을 통해 공개되었을 정보의 양을 초과할 수 있다. § 7.2.2 안전 제한에서는 이러한 가능성을 완화하기 위해 추가적인 사이트 간 프라이버시 예산을 설정하는 방안을 설명한다.

8.5. 교차 사이트 참여 제어

집계 히스토그램을 생성하려면, 여러 사이트가 협력해야 한다. 모든 노출 사이트는 자신이 저장하는 노출에 대해 일관된 값을 생성해야 한다. 전환 사이트는 노출 사이트가 올바른 값을 기록한다고 신뢰해야 한다.

API는 집계를 오염시킬 수 있는 원치 않는 노출의 위험을 사이트가 관리할 수 있도록 여러 필터링 옵션을 제공한다.

• 노출 사이트는 conversionSites를 사용하여 특정 전환 사이트를 대상으로 할 수 있다.

• 노출은 conversionCallers를 사용하여 전환 사이트에서 동작하는 특정 중개자로 제한될 수 있다.

• 전환 사이트는 impressionSites를 사용하여 어트리뷰션의 일부로 질의하는 노출 사이트를 제한할 수 있다.

• 전환은 또한 impressionCallers를 사용하여 특정 중개자가 저장한 노출로 질의를 제한할 수 있다.

필터링 옵션은 어떤 사이트가 어트리뷰션에 참여할 수 있는지를 제한하는 데 유용하며, 이는 집계 결과를 오염시킬 수 있는 엔티티 집합을 줄인다. 이러한 옵션을 효과적으로 사용하는 것은 원치 않는 노출이 실수로 포함되는 일을 방지하는 데 특히 유용하다.

이러한 필터링 옵션은 결과를 오염시키려는 악의적 시도에 대해서는 효과가 제한적이다. 신뢰는 이러한 제어가 기대하는 것만큼 엄격하게 이분법적인 경우가 드물다. 목록에 포함된 노출 사이트는 전환 사이트의 관점에서 진짜인 노출과 위조되거나 오류가 있는 노출을 섞을 수 있다. 오류가 있는 노출은 InValid Traffic(IVT)으로 간주되는 것을 나타내며, 그중 일부는 사기로 간주될 수 있다.

8.5.1. 광고 사기

웹 광고는 다양한 종류의 사기의 대상이 되어 왔다. 사이트는 자신들에게 게재된 광고에 가치가 잘못 귀속된 것처럼 보이도록 하기 위해 이 API를 사용하여 노출 사기를 시도할 수 있다.

노출의 사기적 등록은 이 API에서 특히 우려되는 부분이다. 노출이 기기에만 저장되기 때문이다. 사기성 노출을 식별하고 그것을 어트리뷰션에서 제외하기 위해 서버 측 인텔리전스를 적용할 수 없다.

악의적인 노출에 대한 유일한 직접적 완화책은 사이트 수준 필터링 옵션이다. 이는 완전히 신뢰되지 않는 사이트의 노출이 의도된 후보 노출 집합에 대한 어트리뷰션을 방해하지 못하게 한다.

반대로, 전환 보고서가 암호화되어 있더라도, 보고서가 전환 사이트로 전송되기 때문에, 전환 사이트는 전환이 사기일 가능성이 있다고 판단하고 이를 집계에서 제외할 수 있다.

9. 프라이버시 고려사항

이 API의 주된 프라이버시 목표는 사이트에 어트리뷰션을 수행할 수 있는 능력을 제공하는 것이 그들의 교차 사이트 인식 수행 능력을 향상시키지 않도록 보장하는 것이다.

이 절은 이 목표를 달성하기 위해 필요한 보호에 대해 더 많은 정보를 제공한다. 추가 논의는 동일 사이트 인식 방지와 같은 부차적인 프라이버시 목표를 다룬다.

9.1. Attribution API에 의해 노출되는 정보

노출 저장소와 프라이버시 예산 저장소에는 브라우징 활동의 단면에 관한 정보가 포함된다. API 사용이 증가함에 따라, 이 정보의 범위도 증가한다. 그러나 이러한 저장소에 쓰이는 대부분의 정보는 결코 공개되지 않는다. 어트리뷰션은 기기에서 수행되기 때문에 (온디바이스 어트리뷰션), 귀속된 전환에 관한 정보만 Attribution API에 의해 노출된다. 이는 노출과 전환에 관한 정보가 모두 집계 서비스로 전송되는 오프디바이스 어트리뷰션 방식과 대조된다. 후자의 방식에서는 집계 서비스의 손상 (또는 집계 서비스와의 통신 손상)으로 인해 공개될 수 있는 정보의 양이 훨씬 더 크다.

Attribution API가 어트리뷰션을 수행할 때, 그 어트리뷰션에 관한 정보는 차등 프라이버시 제한이 허용하는 범위 내에서만 기기에서 공개된다.

Attribution API는 제한된 관련 노출 후보 집합과 비교적 드문 전환 이벤트의 연관성을 측정하기 위한 것이지만, 더 큰 규모의 데이터 수집에 API가 어떻게 오용될 수 있는지를 고려하는 것이 중요하다. 노출이 가능한 전환 사이트를 열거해야 한다는 요구사항 (그리고 그 반대도 마찬가지)는 API가 대량 데이터 수집에 오용되는 것을 방지하고, 그러한 오용 시도를 더 잘 보이게 하는 데 중요한 역할을 한다.

9.2. Attribution API 비활성화

사용자 에이전트는 사용자가 Attribution API를 비활성화할 수 있도록 반드시 제어 기능을 제공해야 한다.

Attribution API는 집계된 정보만 공개하도록 설계되었다. 차등 프라이버시를 사용하면 특정 사용자가 집계된 출력에 기여했는지를 알아낼 가능성이 제한된다. 그러나 일부 사용자는 여전히 어트리뷰션 측정에 참여하지 않기를 원할 수 있다.

구현은 Attribution API 전용 제어 기능을 사용하거나, 여러 기능에 적용되는 통합 프라이버시 제어 기능을 통해 사용자가 참여를 거부할 수 있는 선택권을 제공할 수 있다.

사용자 에이전트 개발자는 다른 프라이버시 모드와 Attribution API의 상호 작용을 고려하는 것이 권장된다. 예를 들어, 비공개 브라우징 모드에서는 어트리뷰션이 비활성화될 수 있으며, 또는 사용자가 진단 데이터 수집을 거부한 경우 비활성화될 수도 있다.

설계상 사용자가 참여를 거부했는지는 웹사이트에서 감지할 수 없다.

핑거프린팅의 위험을 최소화하고, Attribution API를 비활성화하기로 선택한 사용자에 대한 차별을 방지하기 위해, 사이트는 API가 비활성화되었음을 감지할 수 없어야 한다. 구체적으로, 그 외의 조건에서는 유효한 Attribution API에 대한 모든 호출은 API가 비활성화된 경우에도 성공적으로 완료된다. 동작상의 유일한 차이는 API가 비활성화되었을 때 반환되는 전환 보고서가 어떠한 전환 값도 절대로 보고하지 않는다는 것이다. 보고서는 암호화되어 있으므로, 이 차이는 전환 보고서를 수신하는 사이트에서 감지할 수 없다.

9.3. 가시성

구현은 사용자가 노출 저장소의 상태를 확인하고 과거 보고서 제출 내역을 검토할 수 있는 방법을 제공하는 것이 권장된다.

이러한 인터페이스는 사이트별 Attribution API의 집계 사용을 보여 주는 요약 정보로 제한될 수 있다. 노출과 제출된 보고서의 세부 정보를 검사하는 인터페이스는 사용자와 웹 개발자 모두가 API의 동작을 진단할 수 있게 할 수 있다.

9.4. 구성되지 않은 브라우저

이 API는 사용자 에이전트 인스턴스가 measureConversion() 요청에 응답하는 데 필요한 모든 구성을 갖추고 있다고 가정한다.

집계 서비스에서 measureConversion()을 호출하는 데 필요한 구성이 없거나 오래된 경우, 사이트에서 이를 관찰할 수 있을 수 있다.

구성을 가져오는 작업으로 인해 measureConversion() 호출의 해결이 지연될 수 있다면, 이는 타이밍 부채널을 생성한다. 대신 가짜 응답이 생성되는 경우, 올바르게 구성된 사용자 에이전트의 응답과 가짜 응답 간의 차이가 관찰될 수 있다. 이는 키 식별자 또는 암호화되지 않은 기타 메타데이터의 사용일 수 있다. 암호문 길이의 차이 역시 암호화되는 내용의 변경이나 알고리즘 선택의 변경을 드러낼 수 있다.

오래되었거나 존재하지 않는 구성을 감지하는 것은 핑거프린팅을 통해 사용자 에이전트를 식별하는 데 사용될 수 있다. HPKE 구성은 요청 시 가져와서는 안 된다. 그렇게 하는 데 걸리는 시간이 measureConversion() 호출자에게 정보를 유출하기 때문이다.

따라서 사용자 에이전트는 사이트에서 관찰할 수 없는 방식으로 집계 서비스 구성을 획득하는 것을 우선시하는 것이 권장된다. 이는 콘텐츠 로드를 시작하기 전에 시작 시 구성을 획득함으로써 달성할 수 있다.

필요한 구성을 획득할 수 없거나, 명백히 오래된 경우, 구현은 measureConversion()이 호출될 때 즉시 거부하도록 선택할 수 있다. 이는 정보를 유출하지만, 가짜 값을 생성하려고 시도하는 것보다 유출되는 정보가 적을 수 있다.

9.5. 저장된 노출에 식별 정보 포함하기

사이트는 matchValue 또는 다른 필드를 사용하여, 노출에 일정량의 데이터를 인코딩할 수 있다. API는 사이트가 이러한 필드에 사용자 식별자를 인코딩하는 것을 막지 않는다. 어트리뷰션 과정은 전환 보고서를 구성할 때 이 데이터를 사용할 수 있으며, 이는 해당 식별 정보가 그 보고서를 수신하는 사이트에 제공될 수 있다는 위험을 내포한다. 다음 조치들이 이 위험을 완화한다:

• 노출 저장소는 직접 읽을 수 없다. 따라서 식별자는 전환 보고서에서 그것에 관한 정보가 공개되는 범위 내에서만 추적에 사용할 수 있다.

• 전환 보고서의 정보는 집계와 노이즈 추가 후에만 공개된다.

• 사용자는 노출 저장소를 지울 수 있다.

• Attribution API가 비활성화되어 있을 때에는 노출 저장소에 노출이 저장되지 않는다.

9.6. 서드 파티 컨텍스트에서의 사용

Attribution API는 서드 파티 컨텍스트에서도 사용할 수 있다. 특히 서드 파티 iframe은 할 수 있다 saveImpression()을 호출할 수 있다. 다만 노출은 iframe의 출처가 아니라 최상위 탐색 컨텍스트의 사이트와 함께 기록된다는 점에 유의한다.

서드 파티 컨텍스트에서 API를 사용할 수 있다는 것은 프라이버시 위험을 어느 정도 증가시키지만, iframe이 광고를 표시하는 데 흔히 사용되기 때문에 이러한 지원은 필요하다고 간주된다.

9.7. API 상태 지우기

사용자 에이전트는 저장소를 지우는 옵션을 제공할 수 있다. 이는 두 가지 이유로 존재한다:

• 사이트에 대한 프라이버시, 즉 사이트가 향후 상호작용에서 사용자를 인식하지 못하게 하기 위해 (즉, 동일 사이트 인식을 방지하기 위해).

• 활동 흔적을 로컬에서 제거하여, 컴퓨터의 다른 사용자가 브라우징 기록에 접근하지 못하게 하기 위해.

프라이버시 예산 소비를 추적하는 상태를 지우는 것은 사이트에 대한 프라이버시에 부정적인 영향을 준다. 그러면 사이트는 어트리뷰션으로부터 더 많은 정보를 얻을 수 있게 된다.

사용자 에이전트는 재량에 따라 API가 비활성화될 때 프라이버시 예산 저장소와 에포크 시작 시간에서 데이터를 지울 수 있다. 이 경우 API가 다시 활성화되면, API가 비활성화되기 전에 얼마나 많은 예산이 소비되었는지 확인할 방법이 없다. 이 경우 사용자 에이전트는 마지막 브라우징 기록 삭제 값을 업데이트하여 프라이버시 예산이 의도치 않게 초과되지 않도록 할 수 있다.

9.7.1. 사이트 데이터 지우기

사용자의 요청으로 사이트 데이터를 지우지만 브라우징 기록은 유지할 때, 사용자 에이전트는 영향을 받는 사이트의 집합, false(forgetVisits에 대해), 그리고 해당 동작이 수행된 시간을 인수로 하여 clear browsing history for attribution를 호출한다. 이는 해당 사이트의 프라이버시 예산을 0으로 설정하여, 그 사이트에서 전환 측정을 사용할 수 없게 한다. 이는 노출 저장소에서 저장된 노출을 제거하지 않는다; 논리적으로 노출은 저장되는 시점에 전환 사이트로 이전된다.

사이트의 요청으로 사이트 데이터를 지울 때, 즉 `Clear-Site-Data` 헤더를 사용하는 경우, 사용자 에이전트는 프라이버시 예산 저장소나 에포크 시작 시간 중 어느 것도 변경하지 않고, 노출만 제거한다.

9.7.2. 브라우징 기록 지우기

브라우징 기록을 지울 때 프라이버시 예산 저장소를 갱신하는 것만으로는 충분하지 않다. 사이트에 대한 프라이버시 손실을 방지하는 데 필요한 사이트별 정보를 유지하면, 컴퓨터의 다른 사용자가 발견할 수 있는 사이트 방문 정보가 남게 된다.

브라우징 기록을 지우는 사용자 에이전트는 영향을 받는 사이트의 집합, true(forgetVisits에 대해), 그리고 작업이 시작된 시간을 인수로 하여 clear browsing history for attribution를 호출한다.

브라우징 기록을 지울 때, 사용자 에이전트는 모든 사이트별 프라이버시 예산 정보를 제거해야 한다 (즉, 프라이버시 예산 저장소에서 항목을 제거한다). 또한 사용자 에이전트는 그 정보의 손실로 인해 이후의 프라이버시 예산 소비가 설정된 제한을 초과하는 프라이버시 손실을 초래하지 않도록 보장해야 한다.

이는 브라우징 기록이 폐기된 에포크 동안 어트리뷰션을 비활성화함으로써 달성할 수 있다. 그렇지 않으면 기록을 지우기 직전에 자신의 예산을 소비한 사이트가 상태 지우기가 없었을 때보다 API를 통해 더 많은 것을 알 수 있게 된다.

이는 영향을 받는 사이트에 대해 남은 에포크 동안 API를 비활성화한다. 에포크 시작 시간은 지워지지 않으므로, 에포크 타임라인은 연속적으로 유지된다.

사용자 에이전트는 last browsing history clear 값에 기록이 마지막으로 지워진 시점을 기억한다. 이는 사이트가 사용자 에이전트가 선택한 최대 허용 프라이버시 예산을 초과할 수 없다는 것이 보장될 때까지 예산 소비를 방지하는 데 사용된다.

get the starting epoch for attribution 알고리즘은 전환 사이트가 상태가 지워진 시점으로부터 한 에포크 기간 안에 시작되는 어떤 에포크의 노출도 질의할 수 없도록 보장한다.

9.7.3. 노출 지우기

노출 저장소를 지우는 메커니즘이 반드시 제공되어야 한다. 예를 들어, Attribution API를 비활성화하는 제어 기능이 활성화될 때 노출 저장소를 지울 수 있다.

사용자 에이전트가 제공하는 저장된 데이터(기록, 쿠키 등)를 지우는 모든 메커니즘을 노출 저장소까지 포함하도록 확장하는 것이 권장된다. § 9.7 API 상태 지우기에서는 저장된 데이터의 삭제에 관한 더 자세한 정보를 제공한다.

사이트의 상태를 지우는 사용자 에이전트는 영향을 받는 기간 동안 저장되었으며 노출 사이트 또는 전환 사이트가 일치하는 모든 저장된 노출을 반드시 폐기해야 한다. 노출 사이트의 경우, 이러한 노출은 삭제된 활동과 관련된다. 상태가 삭제된 전환 사이트는 이러한 노출을 사용할 수 없게 된다.

노출 중 일치하는 중개 사이트가 있는 경우에는 유지할 수 있다.

9.8. 시계 선택

이 API는 시간의 기반으로 wall clock을 사용한다. 이는 주로 API가 지속적인 시간 개념에 의존하기 때문이다. monotonic clock은 사용자 에이전트의 단일 실행 동안에만 정의되므로, 사용자 에이전트가 재시작되면 일관성에 대한 보장이 없다.

wall clock은 시계 drift로 인해 누적될 수 있는 오류를 보정하도록 조정될 수 있다. 따라서 wall clock은 항상 일정한 속도로 전진한다고 보장되지 않으며, 때로는 감소할 가능성도 포함한다.

wall clock의 감소는 이 API가 제공하는 프라이버시 보장에 영향을 주지 않는다. 시계의 증가만이 프라이버시에 부정적인 영향을 줄 수 있다. 정상적인 시간 진행을 초과하는 증가는 프라이버시 예산이 의도보다 더 빨리 갱신되는 결과를 낳을 수 있다.

각 에포크 내에서 보정을 겪는 시계의 경우, 시계 조정은 프라이버시 효과를 가지지 않는다. 충분히 큰 단일 보정은 프라이버시 예산이 예정된 시각보다 앞서 갱신되도록 하여, 일회성 프라이버시 손실 증가를 초래할 수 있다. 지속적인 큰 보정은 프라이버시에 가장 심각한 영향을 주며, 에포크 간 각 전환이 추가 프라이버시 예산을 공개하게 된다.

전체 에포크를 건너뛰는 매우 큰 시간 증가는 추가 프라이버시 손실을 초래하지 않는다. 노출이 저장될 수 없는 한 프라이버시 손실은 가능하지 않다.

물론 시계에 크거나 지속적인 보정이 필요한 모든 사용자 에이전트는 자신이 보고하는 시간의 결과로 매우 식별 가능할 가능성이 높다. 그것만으로도 원치 않는 교차 사이트 인식을 가능하게 하기에 충분할 가능성이 높다.

10. 감사의 말

이 명세는 많은 사람들의 많은 작업의 결과물이다. 이 API 수준의 큰 형태는 Luke Winstrom의 아이디어에 기반한다. 프라이버시 아키텍처는 [PPA-DP]의 저자들이 제공한 것이다.