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

W3C 워킹 드래프트

이 문서에 대한 추가 정보
이 버전:
https://www.w3.org/TR/2026/WD-gpc-20260219/
최신 발행 버전:
https://www.w3.org/TR/gpc/
최신 편집자 초안:
https://w3c.github.io/gpc/
이력:
https://www.w3.org/standards/history/gpc/
커밋 기록
편집자:
Sebastian Zimmeck (Wesleyan University)
Peter Snyder (Brave Software)
Justin Brookman (Consumer Reports)
Aram Zucker-Scharff (The Washington Post)
이전 편집자:
Robin Berjon (Supramundane Agency) (The New York Times until Sep 2022)
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]). 데이터는 제한된 운영 목적으로 서비스 제공자와 공유될 수 있지만, 많은 사용자들이 반감하는 방식으로 행동 타깃팅에 공유되거나 사용될 수도 있습니다.

이 문제를 해결하기 위해 전 세계 관할구역에서 여러 법적 체계가 제안되거나 제정되었습니다. 어떤 모델들은 추적을 위해 사용자 동의에 의존합니다. 데이터 최소화 원칙에 기반한 다른 모델들은 특정 데이터 공유나 데이터 처리를 전면적으로 금지하기도 합니다.

일부 법률 및 제안은 사용자가 자신의 프라이버시를 보호해 달라고 요청할 권리를 부여합니다. 여기에는 그들의 데이터가 상호작용하려는 사업자 외부로 판매되거나 공유되지 않도록 하는 "옵트아웃" 요청이 포함됩니다. 그러나 사람들이 방문하는 모든 사이트마다 수동으로 권리를 표명하도록 요구하는 것은 비현실적이며, 사람들에게 "프라이버시 노동"을 부과하는 것입니다 ([privacy-principles]).

이 명세서는 이러한 마지막 범주의 법들을 위해 설계되었으며, HTTP 헤더나 DOM을 통해 모든 웹사이트 게시자에게 개인의 데이터 판매 금지, 제3자와의 데이터 공유 금지, 그리고 교차-컨텍스트 타깃 광고를 위한 데이터 사용 금지와 같은 해당 권리의 행사를 보편적으로 신호할 수 있는 방법을 제공함으로써 사용자 선택의 확장 문제를 다룹니다. 이 신호는 사용자가 일부 글로벌 옵트아웃 기반 법들에서 특정 조항을 활용할 수 있게 합니다. 예를 들어 캘리포니아 소비자 개인정보 보호법의 "opt out preferences signals"와 관련된 조항을 통해 개인 정보의 판매나 공유를 중단하도록 하는 것([CCPA-REGULATIONS])이나 콜로라도 및 다른 주들의 법률에 있는 "universal opt-out mechanisms"와 유사한 조항을 통해 사용자가 정보의 판매나 기관 간 타깃 광고를 위한 사용을 옵트아웃할 수 있게 하는 조항 등이 있습니다.

그러나 Global Privacy Control은 사용자가 공유 및 교차-컨텍스트 타깃 광고에 대해 옵트아웃하고자 하는 선호를 표현할 수 있도록 설계되었을 뿐, 모든 가능한 프라이버시 권리나 광고 또는 광고 타깃팅에 대한 모든 옵트아웃 권리를 행사하기 위해 고안된 것은 아닙니다. 예를 들어 GPC는 삭제 권리를 행사하도록 설계되지 않았습니다. 또한 GPC는 동일한 컨텍스트 내에서의 데이터 수집이나 광고 타깃팅을 다루도록 설계된 것도 아닙니다. 자세한 내용은 법적 및 구현 고려사항 가이드를 참조하십시오.

이 명세서는 옵트아웃 규제 모델(또는 보다 광범위한 교차-컨텍스트 추적)을 지지하거나 동의 기반 또는 데이터 최소화에 기반한 다른 모델들을 거부하는 것으로 해석되어서는 안 됩니다. 대신 특정 관할구역에서 사용자에게 부여된 적극적 권리를 행사할 수 있도록 가능하게 만드는 것을 목적으로 합니다.

2. 정의

하나의 판매 또는 공유 금지 상호작용은 웹사이트와의 상호작용으로, 그 사람은 자신의 데이터가 그 사람이 상호작용하려는 사업자 이외의 어떤 당사자에게도 판매되거나 공유되지 않도록 요청하거나, 자신의 데이터가 교차-컨텍스트 광고 타깃팅에 사용되지 않도록 요청하는 것입니다. 관점에서 보면 W3C's 개인정보 원칙, 그 사람은 적어도 단 하나의 데이터 컨트롤러만 있기를 요청하고 그리고 그 데이터가 다른 컨텍스트, 심지어 그 컨텍스트가 동일한 사업체에 의해 소유되더라도.

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 선호를 해당 개인에게 가장 적절하다고 판단되는 방식으로 해석할 수 있으며, 특히 그 사람의 프라이버시 기대, 컨텍스트 및 문화적 상황을 고려하여 판단할 수 있습니다. 마찬가지로, 웹사이트는 이 프로토콜의 범위를 벗어난 다른 선호 정보, 예를 들어 사이트별 개인 선호나 제3자 등록 서비스 등을 이용하여, 이 프로토콜을 통해 명시적인 선호가 표현되지 않았을 때 자신의 동작을 알리거나 조정할 수 있습니다.

사용자 에이전트는 사용자의 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 result을 반환합니다.

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. January 2008. 인터넷 표준. 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. 현행표준. URL: https://html.spec.whatwg.org/multipage/
[privacy-principles]
개인정보 원칙. Robin Berjon; Jeffrey Yasskin. W3C. 15 May 2025. STMT. URL: https://www.w3.org/TR/privacy-principles/
[RFC2119]
요구 수준을 표시하기 위한 RFC용 핵심어. S. Bradner. IETF. March 1997. 최선의 현재 관행. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3339]
인터넷의 날짜와 시간: 타임스탬프. G. Klyne; C. Newman. IETF. July 2002. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc3339
[RFC8174]
RFC 2119 핵심어에서 대문자 대 소문자의 모호성. B. Leiba. IETF. May 2017. 최선의 현재 관행. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8259]
자바스크립트 객체 표기법(JSON) 데이터 교환 형식. T. Bray, Ed. IETF. December 2017. 인터넷 표준. URL: https://www.rfc-editor.org/rfc/rfc8259
[RFC8615]
잘 알려진 균일 자원 식별자(URI). M. Nottingham. IETF. May 2019. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc8615
[WebDriver]
WebDriver. Simon Stewart; David Burns. W3C. 6 February 2026. W3C 작업 초안. URL: https://www.w3.org/TR/webdriver2/
[webidl]
Web IDL 표준. Edgar Chen; Timothy Gu. WHATWG. 현행표준. 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?