글로벌 프라이버시 컨트롤 (GPC)

W3C 워킹 드래프트

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2025/WD-gpc-20251217/
최신 공개 버전:
https://www.w3.org/TR/gpc/
최신 에디터 드래프트:
https://w3c.github.io/gpc/
히스토리:
https://www.w3.org/standards/history/gpc/
커밋 히스토리
에디터:
Sebastian Zimmeck (Wesleyan 대학교)
Peter Snyder (Brave 소프트웨어)
Justin Brookman (컨슈머 리포트)
Aram Zucker-Scharff (워싱턴 포스트)
이전 에디터:
Robin Berjon (Protocol Labs) (뉴욕 타임스 ~ 2022년 9월)
Ashkan Soltani (Independent)
David Harbage (DuckDuckGo)
피드백:
GitHub w3c/gpc (풀 리퀘스트, 이슈 등록, 오픈 이슈)

초록

이 문서는 HTTP 및 DOM을 통해 전송되는 신호를 정의하며, 이는 개인이 자신의 개인정보를 제3자에게 판매하거나 공유하지 말 것을 웹사이트와 서비스에 요청함을 전달합니다. 이 표준은 이러한 요청을 집행할 수 있는 기존 및 향후 법적 프레임워크와 함께 작동하도록 설계되었습니다.

이 문서의 현황

이 섹션은 본 문서가 발행된 시점의 상태를 설명합니다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정본은 W3C 표준 및 초안 인덱스에서 확인할 수 있습니다.

이 문서는 프라이버시 워킹 그룹 에서 권고안 절차를 따라 워킹 드래프트로 발행되었습니다.

워킹 드래프트로 발행되었다고 해서 W3C 및 그 회원들의 인준을 의미하지는 않습니다.

이 문서는 초안이며 언제든지 업데이트, 대체 또는 폐기될 수 있습니다. 진행 중인 작업 외의 문서로 인용하는 것은 적절하지 않습니다.

이 문서는 W3C 특허 정책하에 운영되는 그룹에서 작성되었습니다. W3C공개 특허 공개 목록 을 유지하며, 해당 페이지에는 특허 공개 방법에 대한 안내도 포함되어 있습니다. 실제로 특허에 대해 알고 있고, 그 특허가 필수 청구를 포함한다고 생각하는 개인은 W3C 특허 정책 6절에 따라 정보를 공개해야 합니다.

이 문서는 2025년 8월 18일 W3C 프로세스 문서에 따라 관리됩니다.

1. 소개

이 섹션은 비규범적입니다.

오늘날 웹사이트를 구축하는 것은 종종 사용자가 직접 상호작용하기로 선택한 기업이 아닌 다른 기업이 제공하는 서비스에 의존하는 경우가 많습니다. 이는 웹 기술의 복잡성이 증가하고, 다양한 서비스 간의 역할 분담이 이루어지면서 발생한 결과입니다. 이러한 아키텍처는 더 나은 웹 경험을 제공하는 데 사용될 수 있지만, 개인정보를 침해하는 방식으로 악용될 수도 있습니다([privacy-principles]). 데이터는 제한된 운영 목적을 위해 서비스 제공자와 공유될 수 있지만, 많은 사용자가 불쾌하다고 생각하는 행동 기반 타겟팅에 사용되거나 제3자와 공유될 수도 있습니다.

이러한 문제를 해결하기 위해 전 세계 여러 국가와 지역에서 다양한 법적 프레임워크가 제안되거나 제정되었습니다. 일부 모델은 추적에 대한 사용자 동의를 기반으로 하며, 데이터 최소화 원칙에 근거한 다른 모델들은 특정 데이터 공유나 처리 자체를 전면적으로 금지하기도 합니다.

일부 법률 및 제안은 사용자가 자신의 개인정보 보호를 요청할 권리를 부여하며, 여기에는 데이터가 상호작용하려는 기업 이외의 곳에 판매되거나 공유되지 않도록 "옵트아웃"을 요청할 권리도 포함됩니다. 그러나 사용자가 방문하는 모든 사이트마다 일일이 자신의 권리를 직접 표현해야 한다면 이는 비현실적이며, 사용자에게 '프라이버시 노동'을 강요하는 셈이 됩니다([privacy-principles]).

본 명세는 이러한 마지막 범주의 법률을 위해 설계되었으며, HTTP 헤더 또는 DOM을 통해 모든 웹사이트 운영자에게 사용자의 데이터 판매, 제3자와의 데이터 공유, 맥락 간 타겟 광고에 대한 데이터 사용을 방지하고자 하는 권리를 보편적으로 신호할 수 있는 방법을 제공함으로써 사용자 선택의 확장 문제를 해결합니다. 이 신호를 통해 사용자는 캘리포니아 소비자 프라이버시법(예시: "옵트아웃 선호 신호" 관련 조항)이나 콜로라도 및 기타 주의 법률에 있는 "보편적 옵트아웃 메커니즘"과 같은 특정 옵트아웃 법률 조항을 활용하여 개인정보의 판매 또는 공유 중단, 교차 조직 타겟 광고에 대한 사용 거부 등을 할 수 있습니다([CCPA-REGULATIONS]).

그러나 Global Privacy Control은 사용자가 정보 공유 및 맥락 간 타겟 광고 거부 의사를 표현할 수 있도록 설계되었지만, 이 컨트롤은 모든 가능한 프라이버시 권리나 모든 광고 또는 광고 타겟팅 거부 권리를 행사하도록 의도된 것은 아닙니다. 예를 들어, GPC는 삭제 권한을 행사하기 위해 설계된 것이 아닙니다. 또한, GPC는 동일 사이트 데이터 수집 및 동일 사이트 광고 타겟팅을 다루기 위해서도 설계되지 않았습니다. 자세한 내용은 법적 및 구현 고려사항 안내서를 참조하세요.

이 명세는 옵트아웃 방식의 규제 모델이나 맥락 간 추적을 지지하거나 동의 또는 데이터 최소화에 기반한 다른 모델을 거부하는 것으로 해석되어서는 안 됩니다. 대신, 특정 관할 구역에서 사용자에게 부여된 적극적 권리를 행사할 수 있도록 설계되었습니다.

2. 정의

판매 또는 공유 금지 상호작용(do-not-sell-or-share interaction)은 웹사이트와의 상호작용 중, 사용자가 자신의 데이터가 본인이 의도한 상호작용 대상이 아닌 다른 당사자에게 판매되거나 공유되지 않기를 요청하거나, 자신의 데이터가 교차 컨텍스트 광고 타겟팅에 이용되지 않기를 요청하는 행위이다.

do-not-sell-or-share preference란, 사용자가 Global Privacy Control 설정을 사용자 에이전트에서 활성화하거나, 해당 설정이 기본값으로 지정된 도구(아마도 그 도구 사용자의 일반적 기대와 일치하기 때문일 수 있음)를 사용함으로써 자신의 데이터 "판매 또는 공유 금지"를 요청하는 것을 의미합니다. 설정된 경우, 이 preference는 사용자가 do-not-sell-or-share interactions을 기대하면서 웹을 탐색하고자 함을 나타냅니다.

3. 판매 또는 공유 거부 의사 표현

3.1 의사 표현 형식

Global Privacy Control preference는 모든 HTTP 요청(HTTP 헤더 형태) 및 모든 웹사이트(Web API 속성 형태)에 대해 전달되어야 합니다.

설정된 경우, 이 preference는 상황에 따라 1 또는 동등하게 true의 단일 값으로 표현됩니다.

규제, 법률, 기타 요구사항이 없는 경우, 웹사이트는 표현된 Global Privacy Control preference를 해당 사람에게 가장 적절하다고 판단되는 방식으로 해석할 수 있습니다. 특히 사용자의 프라이버시 기대, 맥락, 문화적 환경에 비추어 고려할 수 있습니다. 마찬가지로 웹사이트는 이 프로토콜의 범위를 벗어난 기타 preference 정보(예: 사이트별 사용자 preferences나 제3자 등록 서비스 등)를 활용하여 이 프로토콜을 통해 명시적 preference가 표현되지 않았을 때 행동을 안내하거나 조정할 수 있습니다.

사용자 에이전트는 사용자의 preferences를 최대한 정확하게 전달해야 합니다. 사용자 에이전트는 Global Privacy Control 값에 대해 자신이 가장 신뢰하는 사용자의 preference를 나타내도록 노력해야 합니다.

3.2 선호 캐싱

preference는 각 최상위 탐색 시 캐싱되어야 합니다. 이는 사용자의 "판매 또는 공유 금지" 요청의 일관성을 보장하기 위함입니다. 즉, preference가 최상위 탐색 중이나 이후에 변경되면, 다음 탐색까지 반영되지 않습니다.

최상위 브라우징 컨텍스트gpcAtNavigation 불리언 값을 가집니다. 기본값은 false입니다.

gpcAtNavigation의 값은 해당 preference를 반영해야 합니다. 즉, 최상위 브라우징 컨텍스트활성 문서가 로딩을 시작할 때의 preference를 반영해야 하며, true라면 사용자의 preference가 활성화된 것이고, false라면 비활성화되었거나 설정되지 않은 것입니다.

preference가 어떤 gpcAtNavigation 캐시에 저장된 값과 다르게 변경되면, 사용자 에이전트는 불일치하는 탭을 사용자에게 알리고, 탭을 새로고침하여 캐시된 gpcAtNavigation을 최신 preference로 갱신할 수 있는 옵션을 제공해야 합니다.

3.3 Sec-GPC HTTP 요청 헤더 필드

Sec-GPC 헤더 필드는 HTTP 요청(모든 요청 메서드)에 있어 사용자의 일반적이고 보편적인 preferencedo-not-sell-or-share interaction을 표현하기 위한 메커니즘입니다. 일부 경우, 사용자와의 특정 합의에 따라 웹사이트가 일반적으로 적용되는 preference를 무시할 수 있습니다(아래 5.3절 및 법적 및 구현 고려사항 가이드 참고).

필드의 문법([ABNF])은 다음과 같습니다:

Sec-GPC-field-name  = "Sec-GPC"
Sec-GPC-field-value = "1"

사용자 에이전트는 최상위 브라우징 컨텍스트gpcAtNavigationfalse일 경우, Sec-GPC 헤더 필드를 생성해서는 안 됩니다.

사용자 에이전트는 최상위 브라우징 컨텍스트gpcAtNavigationtrue일 경우, Sec-GPC 필드값이 정확히 숫자 문자 "1"인 헤더 필드를 생성해야 합니다.

사용자 에이전트는 하나의 HTTP 요청 내에서 Sec-GPC를 둘 이상 생성해서는 안 되며, HTTP 트레일러에 Sec-GPC 필드를 사용해서는 안 됩니다.

Sec-GPC 헤더가 포함된 HTTP 요청을 처리하는 서버는 필드값이 정확히 "1"이 아닐 경우, 해당 헤더가 명시되지 않은 것처럼 요청을 처리해야 합니다. 여러 Sec-GPC 헤더 중 적어도 하나의 필드값이 "1"이라면 서버는 해당 요청을 "1" 값의 헤더가 하나만 있는 것처럼 처리해야 하며, 그렇지 않다면 없는 것처럼 처리해야 합니다.

HTTP 중개자는 Sec-GPC가 "1"로 설정된 헤더를 제거해서는 안 되며, 다른 값의 Sec-GPC 헤더를 제거할 수 있습니다. 또한, 특정 HTTP 요청을 보낸 사람이 do-not-sell-or-share preference를 가지고 있다고 판단되는 경우, HTTP 중개자는 Sec-GPC를 "1"로 삽입할 수 있습니다.

3.3.1 Sec-GPC 필드 값의 확장성

Sec-GPC 헤더는 의도적으로 확장 메커니즘 없이 정의되어 있습니다. 이전 유사 헤더의 경험에 따르면, 확장이 존재하지 않을 때에는 값의 존재를 테스트할 때 파싱이 아니라 문자열 일치를 사용하는 경우가 많았습니다. 이런 체크는 확장 내용이 있으면 실패하게 되며, 결국 해당 메커니즘이 무의미해집니다. 이 표준에 확장이 꼭 필요하다면, 별도의 헤더를 통해 구현되어야 하며, 그로 인해 이 헤더가 대체될 수도 있습니다.

3.4 선호 감지를 위한 자바스크립트 속성

globalPrivacyControl 속성을 통해 클라이언트 측 스크립트가 Sec-GPC 헤더 값이 최상위 브라우징 컨텍스트활성 문서를 로드할 때 전송되었는지 확인할 수 있습니다.

WebIDLinterface mixin GlobalPrivacyControl {
  readonly attribute boolean globalPrivacyControl;
};
Navigator includes GlobalPrivacyControl;
WorkerNavigator includes GlobalPrivacyControl;

Sec-GPC 헤더가 전송되지 않은 경우 값은 false이며, 그렇지 않으면 값은 true입니다.

globalPrivacyControl의 값은 최상위 브라우징 컨텍스트gpcAtNavigation이어야 합니다.

globalPrivacyControl 속성은 navigator 객체에서 일반/워커 컨텍스트 모두 사용 가능하므로, navigator.globalPrivacyControl을 통해 확인할 수 있습니다.

4. GPC 지원 리소스

사이트는 필요 시, GPC 요청을 준수한다는 사실을 나타내기 위해 .well-known URL에서 리소스를 제공할 수 있습니다. GPC 지원 리소스의 목적은 사이트가 Global Privacy Control을 인지하고 지원함을 전달하는 데 있습니다. 지원 리소스는 사용자의 에이전트가 접근할 때 해당 사이트가 GPC 요청을 준수하는지 여부를 전달하는 용도가 아닙니다. 기본적으로 오리진의 지원 여부는 알 수 없음 상태입니다.

GPC 지원 리소스는 오리진 서버의 URL 기준 /.well-known/gpc.json이라는 well-known 식별자를 가집니다 [RFC8615].

오리진 서버가 자신의 GPC 지원 리소스를 대상으로 하는 유효한 GET 요청을 받으면, 아래 정의된 사이트 전체 추적 상태에 대한 기계 판독 가능한 표현이 포함된 성공 응답 또는 해당 표현으로 이끄는 일련의 리다이렉트를 반환합니다(이 표현은 다른 오리진의 서버가 제공할 수도 있습니다).

4.1 GPC 지원 표현

오리진 서버는 GPC 지원 리소스를 application/json 미디어 타입 [RFC8259]을 사용한 유효한 표현으로 반환해야 합니다. 그렇지 않을 경우 오리진의 지원 여부는 알 수 없습니다.

GPC 지원 표현은 반드시 JSON 객체여야 하며, 그렇지 않을 경우 오리진의 지원 여부는 알 수 없습니다. 아래 목록에 없는 이 JSON 객체의 멤버는 본 명세에서 의미가 없으며 무시되어야 합니다. 멤버는 다음을 포함합니다:

6. 프라이버시 고려사항

사용자의 선호(HTTP 헤더 필드 또는 navigator 객체 내)가 노출되면, 사용자를 두 그룹으로 나누어 브라우저 또는 기기 핑거프린팅에 사용될 수 있는 정보를 더 많이 제공할 수 있습니다. 이 추가 정보는 신호가 다른 신호와 완벽히 일치하거나, 설정이 변경 불가능할 때를 제외하고는 항상 노출됩니다. 따라서 구현 방식에 따라 GPC 신호는 프라이버시 비용을 초래할 수도 있지만, 이는 신호 송신의 프라이버시 이점에 의해 정당화될 수 있습니다.

7. 보안 고려사항

본 명세의 기능에는 알려진 보안 영향이 없습니다.

8. 자동화

사용자 에이전트 자동화 및 애플리케이션 테스트 목적상, 본 문서는 다음과 같은 확장 명령을 정의합니다. [WebDriver]

8.1 Global Privacy Control 설정

HTTP 메서드 URI 템플릿
POST /session/{session id}/privacy

Global Privacy Control 설정 확장 명령은 현재 세션의 do-not-sell-or-share preference를 수정합니다.

remote end stepssession, URL variables, parameters가 주어진 경우 다음과 같습니다:

  1. gpcparametersgpc 속성으로 지정합니다.

  2. gpc가 undefined이거나 불리언이 아니면, error 코드 invalid argument로 오류를 반환합니다.

  3. 사용자의 preference를 해당 session에 기록하여, gpc가 true면 브라우저는 do-not-sell-or-share interactions을 수행하고, false면 수행하지 않도록 합니다.

  4. success와 data null을 반환합니다.

8.2 Global Privacy Control 조회

HTTP 메서드 URI 템플릿
GET /session/{session id}/privacy

Global Privacy Control 조회 확장 명령은 현재 세션의 do-not-sell-or-share preference를 반환합니다.

remote end stepssession, URL variables, parameters가 주어진 경우 다음과 같습니다:

  1. 해당 session에 대해 브라우저가 preference를 따라 do-not-sell-or-share interactions을 수행한다면, gpc를 true로 둡니다.

  2. 그렇지 않으면 gpc를 false로 둡니다.

  3. result를 "gpc" 속성이 gpc로 설정된 JSON Object로 둡니다.

  4. success와 data null을 반환합니다.

9. 적합성

비규범적임으로 표시된 섹션뿐 아니라, 본 명세의 모든 작성 가이드라인, 다이어그램, 예시, 노트는 비규범적입니다. 본 명세의 그 외 모든 내용은 규범적입니다.

본 문서의 MAY, MUST, MUST NOT, SHOULD와 같은 주요 단어는, BCP 14 [RFC2119] [RFC8174]에 설명된 대로 모두 대문자로 나타날 때에만 해당 의미로 해석되어야 합니다.

A. 구현 시 고려사항

GPC 신호가 특정 사이트에 대한 모든 HTTP 요청에 첨부된다는 점을 고려할 필요가 있습니다. 웹에서 페이지를 렌더링하려면 종종 수십 개의 요청을 보내야 합니다. 따라서 모든 GPC 상호작용마다 비용이 많이 드는 감사를 포함한 완전한 옵트아웃 절차를 트리거하도록 하면, 특히 가능한 효율적으로 실행되어야 하는 CDN(콘텐츠 전송 네트워크)에서 제공되는 리소스를 포함해, 처리량이 매우 커져 비현실적일 수 있습니다.

GPC를 지원하고자 하는 규제기관은 이러한 구현상의 어려움을 고려하는 것이 권장됩니다. 이를 해결하는 한 가지 방법은 사이트에 판매/공유 금지 상호작용 선호를 지속적으로 요청하기 위해 제공된 사용자 인터페이스 제공과, 사용자 에이전트에서 상태가 유지되는 판매/공유 금지 상호작용 신호 제공을 구분하는 것입니다. 후자의 경우, 사용자가 이전에 해당 판매/공유 금지 상호작용 선호를 요청했고 이미 그 선호가 활성화된 상태에서 상호작용하는 것처럼 처리할 수 있습니다.

B. 감사의 글

본 명세는 주로 Tracking Protection Working GroupTracking Preference Expression (DNT)에 기여한 다른 분들이 개발한 개념에 의존하고 있습니다.

C. 참고문헌

C.1 규범적 참고문헌

[ABNF]
구문 명세를 위한 확장 BNF: ABNF. D. Crocker, Ed.; P. Overell. IETF. 2008년 1월. 인터넷 표준. URL: https://www.rfc-editor.org/rfc/rfc5234
[html]
HTML 표준. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[RFC2119]
RFC에서 요구사항 수준을 나타내는 주요 단어. S. Bradner. IETF. 1997년 3월. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3339]
인터넷상의 날짜 및 시간: 타임스탬프. G. Klyne; C. Newman. IETF. 2002년 7월. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3339
[RFC8174]
RFC 2119 주요 단어의 대소문자 모호성. B. Leiba. IETF. 2017년 5월. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8259]
자바스크립트 객체 표기법(JSON) 데이터 교환 포맷. T. Bray, Ed. IETF. 2017년 12월. 인터넷 표준. URL: https://www.rfc-editor.org/rfc/rfc8259
[RFC8615]
Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. IETF. 2019년 5월. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8615
[WebDriver]
WebDriver. Simon Stewart; David Burns. W3C. 2018년 6월 5일. W3C 권고. URL: https://www.w3.org/TR/webdriver1/
[webidl]
Web IDL 표준. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/

C.2 참고용 참고문헌

[CCPA-REGULATIONS]
CCPA 규정. URL: https://www.oag.ca.gov/sites/all/files/agweb/pdfs/privacy/oal-sub-final-text-of-regs.pdf?
[privacy-principles]
프라이버시 원칙. Robin Berjon; Jeffrey Yasskin. W3C. 2025년 5월 15일. STMT. URL: https://www.w3.org/TR/privacy-principles/