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

W3C 워킹 드래프트

이 문서에 대한 추가 정보
이 버전:
https://www.w3.org/TR/2026/WD-gpc-20260924/
최신 발행 버전:
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자와의 데이터 공유, 그리고 교차 컨텍스트 타기팅 광고에 자신의 데이터가 사용되는 것을 방지하기 위한 적용 가능한 권리를 주장한다는 사실을 보편적으로 알리는 방법을 제공함으로써 사용자 선택을 확장하기 어려운 문제를 해결합니다. 이 신호를 통해 사용자는 이러한 전역 거부 선택 기반 법률의 특정 조항을 활용할 수 있습니다. 예를 들어 개인정보의 판매 또는 공유를 중단하기 위한 California Consumer Privacy Act의 "거부 선택 선호 신호" 관련 조항 [CCPA-REGULATIONS]이나, 사용자가 자신의 정보 판매 또는 조직 간 타기팅 광고에 자신의 정보가 사용되는 것을 거부할 수 있도록 하는 Colorado 및 기타 주 법률의 "보편적 거부 선택 메커니즘"에 관한 유사한 조항이 이에 해당합니다.

그러나 Global Privacy Control은 사용자가 공유 및 교차 컨텍스트 타기팅 광고를 거부한다는 선호를 표현할 수 있도록 설계되었지만, 가능한 모든 개인정보 보호 권리를 행사하기 위한 제어 수단은 아니며 광고 또는 광고 타기팅을 거부할 수 있는 모든 권리를 행사하기 위한 것도 아닙니다. 예를 들어 GPC는 삭제 권리를 행사하도록 설계되지 않았습니다. 또한 GPC는 동일한 컨텍스트 내의 데이터 수집이나 광고 타기팅을 다루도록 설계되지 않았습니다. 자세한 내용은 법적 및 구현 고려 사항 가이드를 참조하십시오.

이 명세를 거부 선택 방식의 규제 또는 더 넓은 의미의 교차 컨텍스트 추적을 지지하거나, 동의 또는 데이터 최소화에 기반한 다른 모델을 거부하는 것으로 해석해서는 안 됩니다. 대신 특정 관할권에서 사용자에게 부여된 적극적 권리를 행사할 수 있도록 설계되었습니다.

2. 정의

판매 또는 공유 거부 상호작용이란 사용자가 자신이 상호작용하려는 당사자 이외의 어떤 당사자에게도 자신의 데이터가 판매되거나 공유되지 않도록 하거나, 자신의 데이터가 교차 컨텍스트 광고 타기팅에 사용되지 않도록 요청하는 웹사이트와의 상호작용입니다. W3C의 개인정보 보호 원칙의 관점에서 보면, 사용자는 최소한 데이터 컨트롤러가 하나만 존재하고, 다른 컨텍스트에서 광고 타기팅에 데이터가 사용되지 않도록 요청하는 것입니다. 해당 컨텍스트가 동일한 사업자의 소유인 경우에도 마찬가지입니다.

판매 또는 공유 거부 선호란 사용자가 사용자 에이전트에서 Global Privacy Control 설정을 활성화하거나, 그러한 설정을 기본값으로 사용하는 도구를 사용하는 등의 방식으로 자신의 데이터가 "판매되거나 공유되지 않도록" 요청하는 것입니다(이는 해당 설정이 그 도구 사용자들의 가장 일반적인 기대와 일치하기 때문일 수 있습니다). 설정된 경우 이 선호는 사용자가 판매 또는 공유 거부 상호작용을 하면서 웹을 탐색하기를 기대한다는 것을 나타냅니다.

3. 판매 또는 공유 거부 선호 표현

3.1 표현 형식

Global Privacy Control 선호는 모든 HTTP 요청에는 HTTP 헤더의 형태로, 모든 웹사이트에는 Web API 속성의 형태로 전달되어야 합니다.

설정된 경우 이 선호는 컨텍스트에 따라 단일 값 1 또는 이에 상응하는 true로 표현됩니다.

규제, 법률 또는 기타 요구 사항이 없는 경우 웹사이트는 표현된 Global Privacy Control 선호를 해당 사용자에게 가장 적절하다고 판단하는 방식으로 해석할 수 있으며, 특히 사용자의 개인정보 보호에 대한 기대, 컨텍스트, 문화적 상황을 고려할 수 있습니다. 마찬가지로 웹사이트는 명시적인 선호가 이 프로토콜을 통해 표현되지 않은 경우, 사이트별 사용자 선호 또는 제3자 등록 서비스와 같이 이 프로토콜 범위 밖의 다른 선호 정보를 사용하여 자신의 동작을 결정하거나 조정할 수도 있습니다.

사용자 에이전트는 사용자의 선호를 가능한 한 정확하게 전달해야 합니다. 사용자 에이전트는 Global Privacy Control 값에 대한 사용자의 선호라고 사용자 에이전트가 가장 잘 판단하는 바를 표현하도록 노력해야 합니다.

3.2 선호 캐싱

사용자의 데이터가 "판매되거나 공유되지 않도록" 요청한다는 사실을 일관되게 전달하기 위해 선호는 각 최상위 탐색 시 캐시되어야 합니다. 이는 최상위 탐색 중 또는 이후에 선호가 변경되더라도 다음 탐색 전까지는 그 변경이 반영되지 않는다는 뜻입니다.

최상위 브라우징 컨텍스트에는 gpcAtNavigation 불리언이 있습니다. 초기값은 false입니다.

gpcAtNavigation의 값은 선호를 최상위 브라우징 컨텍스트의 활성 문서가 로딩을 시작한 시점의 사용자 선호와 일치하도록 해야 합니다. 사용자의 선호가 활성화되어 있었다면 true이고, 사용자의 선호가 비활성화되어 있었거나 설정되지 않았다면 false입니다.

선호가 최상위 브라우징 컨텍스트에 캐시된 일부 gpcAtNavigation과 일치하지 않도록 변경되는 경우, 사용자 에이전트는 일치하지 않는 모든 탭을 사용자에게 알리고 현재 선호를 반영하도록 캐시된 gpcAtNavigation을 갱신하기 위해 해당 탭을 다시 로드할 수 있는 옵션을 제공하도록 해야 합니다.

3.3 HTTP 요청의 Sec-GPC 헤더 필드

Sec-GPC 헤더 필드는 HTTP 요청에서 판매 또는 공유 거부 상호작용에 대한 사용자의 일반적이고 보편적인 선호를 표현하기 위한 메커니즘입니다 (모든 요청 메서드에 적용됩니다). 경우에 따라 해당 사용자와의 특정 합의로 인해 웹사이트가 일반적으로 적용되는 선호를 무시할 수 있습니다(아래 § 5.3과 법적 및 구현 고려 사항 가이드를 참조하십시오).

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

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

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

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

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

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

HTTP 중개자는 "1"로 설정된 Sec-GPC 헤더를 제거해서는 안 되지만, 다른 값을 포함하는 Sec-GPC 헤더는 제거할 수 있습니다. 또한 특정 HTTP 요청을 시작한 사용자가 판매 또는 공유 거부 선호를 가지고 있다고 믿을 근거가 있는 HTTP 중개자는 "1"로 설정된 Sec-GPC 헤더를 삽입할 수 있습니다.

3.3.1 Sec-GPC 필드 값의 확장성

Sec-GPC는 의도적으로 확장 메커니즘 없이 정의되어 있습니다. 이전의 유사한 헤더에 대한 경험에 따르면 사람들은 그 존재 여부를 검사할 때, 특히 아직 확장이 존재하지 않는 경우 값을 파싱하는 대신 문자열 동등성에 의존하는 경향이 있습니다. 물론 이러한 검사는 확장 콘텐츠가 존재하면 실패하며, 결과적으로 해당 메커니즘을 무용지물로 만들게 됩니다. 이 표준에 확장이 필요하다는 것이 입증되는 경우, 그러한 확장은 다른 헤더를 통해 구현해야 하며, 해당 헤더가 시간이 지나면서 이 헤더를 대체할 수도 있습니다.

3.4 선호를 감지하는 JavaScript 속성

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 식별자 /.well-known/gpc.json을 갖습니다 [RFC8615].

GPC 지원 리소스를 대상으로 하는 유효한 GET 요청을 수신한 오리진 서버는 오리진에서 제공되는 페이지가 GPC를 어떻게 준수하는지에 관한 기계 판독 가능한 표현을 포함한 성공 응답을 반환하거나, 또는 그러한 표현으로 이어지는 일련의 리디렉션을 반환합니다 (해당 표현은 다른 오리진의 서버에서 제공될 수 있습니다).

4.1 GPC 지원 표현

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

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 설정 확장 명령은 현재 세션의 판매 또는 공유 거부 선호를 수정하고, 갱신된 설정을 반환합니다.

원격 종단 단계는 session, URL variables, parameters가 주어졌을 때 다음과 같습니다.

  1. gpc를 parameters의 gpc 속성으로 설정합니다.

  2. gpc가 정의되지 않았거나 불리언이 아니면 오류 코드 invalid argument를 사용하여 오류를 반환합니다.

  3. 이 session에 대한 사용자의 선호를 기록하여, gpc가 true이면 브라우저가 판매 또는 공유 거부 상호작용을 수행하고, gpc가 false이면 판매 또는 공유 거부 상호작용을 수행하지 않도록 합니다.

  4. result를 속성 "gpc"가 gpc로 설정된 JSON Object로 설정합니다.

  5. 데이터 result와 함께 성공을 반환합니다.

8.2 Global Privacy Control 가져오기

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

Global Privacy Control 가져오기 확장 명령은 현재 세션의 판매 또는 공유 거부 선호를 반환합니다.

원격 종단 단계는 session, URL variables, parameters가 주어졌을 때 다음과 같습니다.

  1. 이 session에 대한 사용자의 선호가 브라우저가 판매 또는 공유 거부 상호작용을 수행하도록 되어 있으면, gpc를 true로 설정합니다.

  2. 그렇지 않으면 gpc를 false로 설정합니다.

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

  4. 데이터 result와 함께 성공을 반환합니다.

9. 적합성

비규범적이라고 표시된 섹션뿐 아니라 이 명세의 모든 작성 지침, 다이어그램, 예제 및 참고 사항은 비규범적입니다. 이 명세의 그 밖의 모든 내용은 규범적입니다.

이 문서의 핵심어 MAY, MUST, MUST NOT, 그리고 SHOULD는 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 합니다.

A. 구현 고려 사항

GPC 신호는 특정 사이트에 전송되는 모든 HTTP 요청에 첨부된다는 점을 고려할 필요가 있습니다. 웹에서 페이지 하나를 렌더링하려면 흔히 수십 개의 이러한 요청을 해야 합니다. 따라서 각각의 GPC 상호작용마다 비용이 많이 드는 감사 추적을 포함한 완전한 거부 선택 절차를 GPC 신호가 실행하도록 하면 비현실적일 수 있습니다. 그렇게 하면 가능한 한 효율적으로 실행되어야 하는 콘텐츠 전송 네트워크(CDN)에서 제공되는 리소스를 포함해 매우 많은 처리가 발생하기 때문입니다.

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

B. 감사의 글

이 명세는 대부분 Tracking Protection Working Group과 Tracking Preference Expression (DNT)에 기여한 다른 사람들이 개발한 개념에 의존합니다.

C. 참고 문헌

C.1 규범적 참고 문헌

[ABNF]
구문 명세를 위한 확장 BNF: ABNF. D. Crocker, 편집자; P. Overell. IETF. 2008년 1월. 인터넷 표준. URL: https://www.rfc-editor.org/info/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. 2025년 5월 15일. STMT. URL: https://www.w3.org/TR/privacy-principles/
[RFC2119]
RFC에서 요구 수준을 나타내기 위해 사용하는 핵심어. S. Bradner. IETF. 1997년 3월. 현행 모범 사례. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC3339]
인터넷의 날짜 및 시간: 타임스탬프. G. Klyne; C. Newman. IETF. 2002년 7월. 제안 표준. URL: https://www.rfc-editor.org/info/rfc3339/
[RFC8174]
RFC 2119 핵심어의 대문자와 소문자 간 모호성. B. Leiba. IETF. 2017년 5월. 현행 모범 사례. URL: https://www.rfc-editor.org/info/rfc8174/
[RFC8259]
JavaScript Object Notation (JSON) 데이터 교환 형식. T. Bray, 편집자. IETF. 2017년 12월. 인터넷 표준. URL: https://www.rfc-editor.org/info/rfc8259/
[RFC8615]
잘 알려진 통합 자원 식별자 (URI). M. Nottingham. IETF. 2019년 5월. 제안 표준. URL: https://www.rfc-editor.org/info/rfc8615/
[WebDriver]
WebDriver. Simon Stewart; David Burns. W3C. 2026년 7월 2일. 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?