다음도 참조 번역.
Copyright © 2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
개인정보 보호는 웹의 필수적인 부분입니다. 이 문서는 전 세계에 적용되는 개인정보 및 관련 개념에 대한 정의와 웹을 신뢰할 수 있는 플랫폼으로 발전시키는 데 지침이 되어야 할 개인정보 원칙들을 제공합니다. 웹을 사용하는 사람들은 기술과 정책 간의 더욱 긴밀한 관계로부터 혜택을 얻을 수 있으며, 이 문서는 두 측면 모두에 맞게 작성되었습니다.
이 섹션은 이 문서가 발표될 당시의 상태를 설명합니다. 현재 W3C 간행물과 이 기술 보고서의 최신 개정본 목록은 W3C standards and drafts index에서 https://www.w3.org/TR/를 통해 확인할 수 있습니다.
이 문서는 웹 개인정보 보호 원칙 태스크포스에 의해 준비되었으며, 해당 태스크포스는 TAG에 의해 소집되었습니다.
이 문서는 기술 아키텍처 그룹에 의해 성명으로 게시되었으며 Note 트랙을 사용했습니다.
W3C 성명은 광범위한 합의 형성 과정을 거쳐 W3C와 그 회원들이 지지하는 문서입니다.
W3C 특허 정책은 이 문서에 대해 어떠한 라이선스 요구사항이나 약속도 부과하지 않습니다.
이 문서는 2023년 11월 03일 W3C 프로세스 문서의 적용을 받습니다.
이 문서는 프라이버시 원칙을 윤리적 웹 원칙에서 상세히 설명합니다: "보안과 프라이버시는 필수적입니다." 이 문서는 프라이버시에 중점을 두고 있지만, 이는 프라이버시가 항상 다른 윤리적 웹 원칙보다 더 중요하다는 의미로 받아들여져선 안 되며, 이 문서는 서로 충돌하는 경우 다양한 윤리적 웹 원칙들 간의 균형을 어떻게 맞출지에 대해서는 다루지 않습니다.
웹상의 프라이버시는 주로 두 가지 힘에 의해 규제됩니다: 웹 플랫폼이 노출(또는 노출하지 않)하는 아키텍처적 역량과 웹이 사용되는 다양한 관할구역의 법률들([New-Chicago-School], [Standard-Bodies-Regulators]). 이러한 규제 메커니즘은 분리되어 있습니다; 한 국가의 법률이 웹 전체의 아키텍처를 변경하지 않으며(그럴 수도 없고 그래서도 안 되며), 마찬가지로 웹 사양이 특정 법률을 무효화할 수는 없습니다(다만 법을 만들고 집행하는 것을 더 쉽게 만들 수는 있습니다). 웹은 단순히 특정 법적 프라이버시 체계의 구현이 아니며, 종종 법적 요구사항을 초과하는 공유된 가치에 의해 주도되는 고유한 특징과 보장을 가지고 있습니다.
그러나 웹상의 프라이버시 목표는 기술과 법이 서로 보완할 때 가장 잘 달성됩니다. 이 문서는 웹상의 프라이버시를 규제하기 위한 기술적 노력을 돕기 위해 공유된 개념을 정립하려고 합니다. 또한 법적 규제 체계 간 또는 그와의 정렬을 추구하는 데 유용할 수 있습니다.
이 문서의 목표는 모든 가능한 프라이버시 문제를 다루는 것이 아니라, 웹 커뮤니티가 프라이버시에 대해 정보에 입각한 결정을 내리고 프라이버시를 웹 아키텍처에 통합할 수 있도록 충분한 배경을 제공하는 것입니다.
몇몇 아키텍처 원칙은 절대적인 것은 아니며, 프라이버시도 예외는 아닙니다: 프라이버시는 접근성이나 국제화 같은 다른 바람직한 윤리적 아키텍처 특성과 긴장을 일으킬 수 있으며, 그런 경우 웹 커뮤니티는 적절한 균형을 찾기 위해 함께 노력해야 합니다.
이 문서의 주요 대상은
추가 대상에는 다음이 포함됩니다:
이 문서는 새로운 웹 표준 또는 기능의 수명 주기 초기에 또는 웹 제품 개발 단계에서 대상 독자들이 프라이버시 문제를 가능한 한 일찍 다룰 수 있도록 돕기 위해 작성되었습니다. 처음부터 프라이버시를 고려하면 예측 가능하지만 예상치 못한 문제들을 나중에 해결하기 위해 특수한 예외를 추가하거나 사용자가 받아들이기 어려운 시스템을 구축해야 하는 상황을 피할 수 있습니다.
이 문서는 새로운 표준의 프라이버시 검토를 안내하므로, 웹 사양의 작성자는 설계 초기에 이 문서를 참고하여 그들의 기능이 원활하게 검토를 통과하도록 해야 합니다.
이 섹션은 모든 프라이버시 원칙의 목록이며, 문서 나머지 부분에 있는 더 긴 설명으로 링크되어 있습니다.
어떤 대상 독자가 포함되어야 합니까?
이 문서는 기술 지침을 담고 있습니다. 다만 그 지침들을 맥락에 맞게 이해하려면 먼저 몇몇 용어를 정의하고 우리가 프라이버시로써 무엇을 의미하는지 설명해야 합니다.
웹은 정보 흐름들로 구성된 사회적·기술적 시스템입니다. 이 문서는 웹에 적용되는 프라이버시에 대해 특히 다루므로, 정보 흐름과 관련된 프라이버시에 초점을 맞춥니다.
웹은 모두를 위한 것입니다 ([For-Everyone]). 웹은 "사람들을 돕고 순수한 사회적 이익을 제공하는 플랫폼"이 되어야 합니다 ([Ethical-Web-Principles]). 웹이 사람들에게 봉사하는 방식 중 하나는 감시와 데이터가 가능하게 하는 조작으로부터 사람들을 보호하려는 것입니다.
정보는 사람들을 예측하고 영향을 미치며, 사람들의 행동을 통제하는 온라인 공간을 설계하는 데 사용될 수 있습니다. 더 큰 양의 정보 수집과 더 높은 정밀도 및 신뢰성, 점점 더 다양한 데이터 유형 간 상호운용성의 증가, 그리고 가속화된 처리 속도는 사생활 및 공적 자유를 위협하는 권력의 집중으로 이어지고 있습니다. 게다가 자동화와 삶의 모든 측면에 대한 컴퓨터화 증가는 정보의 힘을 증가시키고, 가해자가 피해자와 같은 공간에 있어야만 억제될 수 있었던 여러 침해적 행위의 비용을 낮춥니다.
어떤 행위자가 한 사람에 대한 데이터를 자동으로 수집하고 처리할 수 있고, 그 사람이 자신의 데이터를 보호하거나 처리 제어를 하려면 수동으로 조치를 취해야 한다면, 이 자동화 비대칭은 해당 행위자에게 유리한 힘의 불균형을 만들고 사람의 자율성을 감소시킵니다. 이 문서는 데이터 처리가 사람들에게 미칠 수 있는 영향에 중점을 두지만, 회사나 정부 같은 다른 행위자들에게도 영향을 줄 수 있습니다.
모든 사람이 힘의 불균형에 저항할 수 있는 능력이 동일한 것은 아니라는 점을 염두에 두는 것이 중요합니다: 어떤 사람들은 더 취약할 수 있어 더 많은 보호가 필요합니다.
데이터 거버넌스는 정보 흐름을 규제하는 원칙들의 체계입니다. 데이터 거버넌스는 어떤 행위자가 어떤 데이터를 수집할 수 있는지, 어떤 방식으로 수집할 수 있는지, 그리고 어떻게 처리할 수 있는지를 결정합니다 ([GKC-Privacy], [IAD]). 이 문서는 사람들을 우선하는 데이터 거버넌스를 위한 구성 요소들을 제공합니다.
원칙들은 문맥마다 달라집니다 ([Understanding-Privacy], [Contextual-Integrity]). 예를 들어, 사람들은 직장, 카페, 가정에서의 프라이버시에 대해 서로 다른 기대를 갖습니다. 프라이버시 상황을 이해하고 평가하려면 다음을 명확히 식별하는 것이 가장 좋습니다:
항상 프라이버시 원칙들이 작동하고 있습니다. 어떤 원칙 집합이 더 관대할 수는 있지만, 그것이 중립적이라는 의미는 아닙니다. 모든 프라이버시 원칙은 사람들에게 영향을 미치므로, 우리는 웹 문맥에서 어떤 원칙이 윤리적 웹 가치와 가장 잘 정렬되는지를 결정해야 합니다 ([Ethical-Web-Principles], [Why-Privacy]).
정보 흐름은 행위자들이 교환하거나 처리하는 정보입니다. 사람의 프라이버시는 그들의 정보가 다른 행위자들에게서 흘러나갈 때뿐 아니라 정보가 그들에게 흘러들어올 때도 해를 입을 수 있습니다. 후자의 예로는 예상치 못한 충격적인 이미지, 잠을 자려 할 때의 큰 소음, 조작적 정보, 집중하고 있는 중 방해하는 메시지, 또는 사회적 상호작용을 하려 할 때의 괴롭힘 등이 있습니다. (이들 중 일부 경우에 해당 정보는 개인 데이터가 아닐 수도 있습니다.)
웹에서는 정보 흐름에 참여하는 행위자들이 다양하며, 특정 상호작용 내에서 사용자에게 항상 분명하거나 인식 가능한 것은 아닙니다. 웹사이트 방문은 해당 사이트 운영에 기여하는 행위자들뿐 아니라 네트워크 접근 권한을 가진 행위자들도 포함할 수 있습니다. 여기에는 인터넷 서비스 제공자, 다른 네트워크 사업자, 학교·도서관·대학 등 로컬 네트워크를 제공하는 기관, 정부 정보기관, 네트워크나 다른 행위자들의 시스템에 접근 권한을 얻은 악의적 해커 등이 포함될 수 있습니다. 이러한 행위자들은 감시 같은 고수준 위협을 추구할 수 있습니다 ([RFC6973]). 광범위하고 무차별적인 감시의 한 형태인 만연한 모니터링(pervasive monitoring)은 인터넷과 웹 사용자들의 프라이버시에 대한 알려진 공격입니다 [RFC7258].
정보 흐름에는 다른 사람들 — 예를 들어 사이트의 다른 사용자들 — 도 포함될 수 있으며, 여기에는 친구, 가족, 교사, 낯선 사람, 또는 공무원이 포함될 수 있습니다. 공개 및 괴롭힘을 포함한 일부 프라이버시 위협은 정보 흐름에 관여한 다른 사람들에게 특유할 수 있습니다 ([RFC6973]).
한 사람의 자율성은 다른 행위자들로부터 부당한 영향 없이 자신의 의지로 결정을 내릴 수 있는 능력입니다. 사람들은 결정을 숙고할 수 있는 지적 자원과 시간이 제한되어 있어 판단할 때 지름길에 의존해야 하며, 이로 인해 그들의 선호도, 포함하여 프라이버시 선호도가 조작될 수 있습니다 ([Privacy-Behavior], [Digital-Market-Manipulation]). 어떤 사람의 자율성은, 그 시스템이 제한 없는 시간과 지적 능력이 주어졌을 때 해당 사람이 내렸을 결정에 더 근접한 지름길을 제공할 때 향상됩니다. 반대로 비슷한 지름길이 이상적 조건에서의 결정에 반하는 경우 자율성은 감소합니다.
자율성을 저해하는 제공물과 상호작용은 기만적 패턴(또는 다크 패턴)으로 알려져 있습니다. 기만적 패턴은 의도적일 필요는 없습니다 ([Dark-Patterns], [Dark-Pattern-Dark]). 사람들의 자율성에 영향을 미칠 수 있는 것을 만들 때는 여러 독립적 관점의 검토자들이 그것이 기만적 패턴을 도입하지 않는지 점검하는 것이 중요합니다.
오늘날의 데이터 경제에서 발생하는 잠재적 데이터 관련 결정의 양이 많기 때문에, 사람들이 자신의 데이터 처리 방식에 대해 상세한 통제를 갖기는 불가능합니다. 이 사실이 프라이버시가 사라졌다는 것을 의미하지는 않습니다. 연구는 사람들이 자신의 데이터가 어떻게 처리되는지에 대해 여전히 우려하고 무력감을 느끼며 자율성을 잃었다고 느낀다는 것을 보여줍니다 ([Privacy-Concerned]). 기술 인프라를 신중히 설계하면 사람들에게 자신의 데이터에 관해 더 큰 자율성을 부여할 수 있습니다. 이는 적절하고 프라이버시 보호적인 기본값을 설정하고 사용자 친화적인 선택 구조를 설계함으로써 이루어집니다.
사람들이 데이터 처리 시스템과 상호작용하는 방식을 제어할 수 있게 하는 여러 유형의 메커니즘이 존재합니다. 처리되는 목적의 수나 처리되는 데이터의 양을 늘리는 메커니즘은 옵트인 또는 동의로 불립니다. 반대로 이러한 목적 수나 처리되는 데이터의 양을 줄이는 메커니즘은 옵트아웃으로 알려져 있습니다.
신중하게 배치될 경우 이러한 메커니즘은 사람들의 자율성을 향상시킬 수 있습니다. 그러나 흔히 이들은 어떤 처리들이 적절한지 아닌지를 결정하는 어려운 작업을 회피하는 수단으로 사용되어 시스템 사용자가 프라이버시 노동을 떠맡게 만들기도 합니다.
사람들은 사진이나 위치정보 접근 허용과 같이 그렇지 않으면 제한될 데이터 공유에 대해 동의할 수 있어야 합니다. 행위자는 사용자가 이러한 동의를 부여할 때 정보를 제공받았음을 확실히 하고, 사용자가 원할 때 언제든 동의를 철회할 수 있도록 알 수 있게 해야 합니다. 데이터 처리에 대한 동의와 웹 플랫폼 API 접근 권한 부여는 유사한 문제입니다. 동의와 권한은 사용자가 다른 일을 하려고 할 때 답변을 미루거나 피할 수 있도록 요청되어야 합니다. 사용자가 데이터에 대한 영구적 접근을 허용하면, 사람들로 하여금 이 지속적 접근을 인지하고 언제든 끌 수 있게 하는 표시기가 있어야 합니다. 일반적으로 동의는 드물고 의도적이며 일시적이어야 합니다.
옵트아웃 메커니즘이 존재할 때, 그것은 바람직하게는 전역 옵트아웃 메커니즘과 함께 작동해야 합니다. 개념적으로 전역 옵트아웃 메커니즘은 사용자 에이전트의 일부로 작동하는 자동화 장치입니다. 이는 사이트와의 모든 상호작용에서 사용자를 대신해 옵트아웃 버튼(또는 사용자의 권리 표현)을 누르는 로봇과 동등합니다. (예: 사용자가 정당한 이익에 기초한 처리를 거부하거나, 특정 목적에 대한 동의를 철회하거나 자신의 데이터가 판매되거나 공유되지 않도록 요청하는 경우 등.) 사용자는 사실상 자신의 옵트아웃 표현을 사용자 에이전트에 위임하여 자동화 비대칭을 바로잡는 데 도움을 줍니다. Global Privacy Control (GPC)는 좋은 전역 옵트아웃 메커니즘의 예입니다.
이 모델 하에서, 전역 옵트아웃 신호는 사용자가 과거에 설정을 바꾸었거나 특정 사용자 에이전트를 사용하기로 한 결정을 한 시점의 결정으로 이해되어서는 안 되며, 오히려 사이트와의 모든 상호작용에서 자동으로 재확인하는 선호로 이해되어야 합니다.
옵트아웃 또는 다른 데이터 권리의 한 구현 전략은 사람들에게 안정적인 식별자를 할당하고 이 식별자들을 사람들의 선호와 매핑하는 중앙 레지스트리를 유지하는 것입니다. 특정 사람의 데이터를 처리하려는 행위자는 그 사람의 선호를 중앙 레지스트리에서 가져와 자신의 처리 설정을 그에 맞춰 구성해야 합니다. 이 접근법은 전화번호나 주소의 마케팅 용도 옵트아웃을 포착하기 위해 사용된 바 있습니다. 그러나 이 접근법은 여러 이유로 권장되지 않습니다: 악의 행위자를 기술적으로 막지 못하고, 단일 실패 지점을 만들며, (특히 웹 시스템이 암시하는 처리 규모에서는) 의미있게 감사를 수행하기 어렵고, 기존 시스템 경험은 사람들이 자신의 권리를 행사하기 어렵게 만든다는 것을 보여줍니다.
프라이버시 노동은 한 사람이 자신이 정보의 주체이거나 수신자인 데이터 처리의 적절성을 보장하는 작업을 수행하게 하는 관행을 말하며, 대신 처리를 수행하는 행위자에게 책임을 두지 않는 것입니다. 사람들에게 동의를 묻는 데이터 시스템은 프라이버시 노동을 증가시키는 경향이 있습니다.
일반적으로 프라이버시의 구현은 종종 노동을 사람들에게 떠맡깁니다. 이는 특히 1970년대에 데이터베이스 증가에 대한 개인의 자율성을 지원하기 위해 처음 제시된 느슨한 원칙 집합인 공정 정보 관행(FIPs)의 후예 체계에서 특히 그렇습니다. FIPs는 일반적으로 처리량이 충분히 적어 어떤 사람이 충분한 실사를 수행하여 의사결정에서 자율적일 수 있다고 가정합니다. 이들은 프라이버시 노동을 사람들에게 떠넘기고 완전하고 무제한적인 자율성을 가정하기 때문에 특정 유형의 데이터 처리를 금지하지 않고 단지 다른 절차적 요구사항을 부과합니다. 이러한 접근법은 더 이상 적절하지 않습니다.
절차적 접근법의 한 가지 주요 문제는 힘의 불균형이 큰 상황 — 예를 들어 독점적 플랫폼이 제공하는 필수 서비스 사용자의 경우 — 과 개인과 행위자가 거의 동등한 지위에 있거나(또는 소규모 사업자가 경쟁 환경에서 더 큰 힘을 가질 수 있는 경우처럼) 다른 상황에 동일한 요구사항을 적용하는 경향이 있다는 것입니다. 또한 한 행위자가 다른 행위자들을 강요하여 부적절한 관행을 용이하게 만들 수 있는 경우를 충분히 고려하지 않습니다. 이는 광고나 콘텐츠 집계에서 지배적 플레이어들이 종종 하는 일입니다 ([Consent-Lackeys], [Content-Aggregation-Technology]).
FIPs에 대한 언급은 오늘날까지도 남아 있습니다. 종종 이들은 "투명성과 선택"이라고 언급되며, 오늘날의 디지털 환경에서는 이는 종종 부적절한 처리가 설명되고 있다는 신호가 됩니다.
때때로 어린이 또는 노인을 비롯한 특정 그룹의 사람들이 취약한 사람들로 분류됩니다. 그러나 어떤 사람도 하나 이상의 문맥에서, 때로는 자신도 깨닫지 못한 채, 취약해질 수 있습니다. 어떤 사람은 개인 데이터를 공개할 때 자신이 취약하거나 취약해질 수 있다는 것을 인지하지 못할 수 있으며, 어떤 행위자는 그 사람이 취약한지 알 방법이 없을 수 있습니다. 시스템 설계자는 이를 시스템 설계 시 고려해야 합니다.
어떤 개인들은 개인 데이터의 수집, 오용, 손실 또는 도난으로 인해 프라이버시 위험이나 피해에 더 취약할 수 있습니다. 그 이유는:
추가적인 프라이버시 보호는 취약한 사람들의 개인 데이터나 그들의 개인 데이터가 수집·사용·공유될 경우 누군가를 취약하게 만들 수 있는 민감 정보에 필요할 수 있습니다(예: 추적 요소 차단, 센서 데이터 또는 설치된 소프트웨어나 연결된 장치에 관한 정보 차단).
때때로 다른 사람들이 부모, 보호자, 동료 등으로서 취약한 사람들이 프라이버시 위험을 평가하고 프라이버시 결정을 내리는 데 도움을 줄 수 있지만, 모든 사람은 자신만의 프라이버시 권리를 가집니다.
일부 취약한 사람들은 웹 사용에 관한 좋은 결정을 하도록 도와줄 보호자가 필요합니다(예: 어린이, 부모가 종종 그들의 보호자 역할을 함). 보호자를 가진 사람은 피보호자로 알려집니다.
피보호자는 정보에 입각한 결정을 내리고 프라이버시 권리에 관한 자율성을 행사할 권리가 있습니다. 그들의 보호자는 피보호자의 능력이 충분치 않을 때 피보호자가 그렇게 할 수 있도록 돕는 의무가 있으며, 이는 보호자의 욕구와 충돌하더라도 적용됩니다. 실제로 많은 보호자들이 피보호자의 최선의 이익에 따라 결정을 내리지 않는 경우가 많으며, 웹 플랫폼 기술은 이러한 상황의 내재적 위험을 악화시키지 않아야 합니다.
사용자 에이전트는 보호자가 피보호자를 위험으로부터 보호하려는 선의의 필요성과 보호자가 악의적일 경우 피보호자가 자신을 보호할 필요성 사이의 균형을 맞춰야 합니다.
사용자 에이전트는 2.8 장치 소유자 및 관리자의 원칙을 준수함으로써 취약한 피보호자를 보호할 수 있으며, 보호자의 책임을 다하도록 돕기 위한 목적으로만 피보호자에 관한 정보를 보호자에게 제공해야 합니다. 그렇게 하는 메커니즘은 보호자가 피보호자의 이익에 반하여 행동하지 않는다는 것을 피보호자가 인식했을 때 그들을 돕는 조치를 포함해야 합니다.
프라이버시 원칙들은 사회적 과정을 통해 정의되기 때문에 특정 문맥에서 적용 가능한 프라이버시의 정의는 논쟁의 대상이 될 수 있습니다 ([Privacy-Contested]). 이는 프라이버시를 집단적 행동의 문제로 만듭니다 ([GKC-Privacy]). 집단 차원의 데이터 처리는 인구 집단이나 개인에게 영향을 미칠 수 있으며, 이는 때로는 사람들이 동의라는 낙관적 가정 아래에서도 통제할 수 없는 방식으로 발생할 수 있습니다. 예를 들어, 어떤 사람이 특정 행위자에게 자신이 특정 그룹의 일원이라는 사실만 공개하기를 원할 수 있습니다. 그러나 같은 그룹의 다른 구성원들이 동일 행위자와 상호작용하면서 훨씬 더 많은 정보를 공개하면, 정보를 제공하지 않은 사람들에 대해서도 효과적인 통계적 추론이 가능해질 수 있습니다.
따라서 우리가 고려하는 것은 데이터를 공유하는 사람들과 그 공유를 요청하는 행위자 간의 관계뿐만 아니라, 동일한 그룹으로 간접적으로 분류될 수 있는 사람들 간의 관계도 포함됩니다 ([Relational-Turn]). 이러한 관계는 데이터가 비식별화되었을 때에도 지속될 수 있다는 점을 이해하는 것이 중요합니다. 더 나아가, 사람들이 자발적이든 아니든 간에 그렇게 분류되는 것은 세상이 작동하는 방식을 바꾸며, 이는 개인과 그룹 모두에 해를 끼칠 수 있는 자기강화 루프를 만들어낼 수 있습니다 ([Seeing-Like-A-State]).
일반적으로 데이터 관련 집단적 문제는 집단적 해결책을 요구합니다. 웹 표준은 사용자 에이전트에서 구조적 통제를 정의하고, 연구자와 규제기관이 집단 수준의 남용을 발견할 수 있도록 하며, 프라이버시 문제를 처리할 수 있는 기관을 수립하거나 위임함으로써 데이터 거버넌스를 돕습니다. 거버넌스는 주로 개인 통제를 증가시키는 방식으로 작동할 경우 목표 달성에 어려움을 겪을 것입니다.
대규모로 데이터를 수집하는 것은 상당한 사회적 이익을 가져올 수 있습니다. 문제는 행위자들이 집단 이익을 위해 데이터를 처리하는 동시에 그와는 배치되는 목적들(예: 수익 목적)에도 사용하려 할 때 발생합니다. 이러한 배치된 목적은 종종 사회적 이익을 뒷받침한다고 정당화되지만, 이는 적절하려면 집단적 감독이 필요합니다.
사람들이 그룹의 구성원이 되는 방법은 여러 가지가 있습니다. 스스로 가입하여 모임에 참여하는 자발적 그룹(클럽 가입 등)일 수도 있고, 관료제나 그 컴퓨터화된 등가물과 같은 외부 행위자에 의해 분류되는 경우도 있습니다 ([Beyond-Individual]). 후자의 경우 사람들은 자신이 그룹으로 묶이고 있다는 사실을 인지하지 못할 수 있으며, 그 그룹의 정의가 불투명한 머신러닝 기법으로 생성되었다면 이해하기 어려울 수 있습니다.
집단 프라이버시 보호는 두 가지 수준에서 이루어질 수 있습니다. 그룹의 존재 자체 또는 최소한 그 활동은 구성원이 익명으로 유지된다고 해도 보호될 필요가 있을 수 있으며, 이를 우리는 "집단 프라이버시"라고 부릅니다. 반대로, 그룹의 존재와 활동은 잘 알려져 있지만 구성원임을 알리는 사실을 보호하고자 하는 경우(예: 권위주의 체제 하의 반체제 운동 참여)는 "멤버십 프라이버시"라 부릅니다. 전자의 사례에 대한 프라이버시 침해 예로는 피트니스 앱 Strava가 개인의 행동이나 신원을 드러내지는 않았지만 인기 러닝 루트의 히트맵을 공개하여 군사 기지 주변의 활동을 드러낸 경우가 있습니다 ([Strava-Debacle], [Strava-Reveal-Military]).
소그룹에 대한 정보가 처리될 때 개인정보가 개별적으로 노출되지 않더라도 사람들의 프라이버시 이익이 영향을 받을 수 있습니다. 예를 들어 교실 학생들의 브라우징 활동은 교사가 어떤 학생이 특정 건강 관련 자료에 접근했는지 정확히 알지 못하더라도 민감할 수 있습니다. 특정 진료소를 방문한 사람들에게 정보를 표적화하거나 특정 배심원단에 속한 사람들에게 메시지를 타겟팅하는 것도 고유 식별 데이터가 없더라도 침해적일 수 있습니다.
사람들이 자신이 그룹의 구성원이라는 사실을 모를 때, 함께 권리를 옹호하기 위해 다른 구성원을 쉽게 찾을 수 없을 때, 또는 자신이 왜 특정 그룹으로 분류되는지 이해하기 어려울 때, 자기 규제적 접근으로 자신을 보호할 능력은 사실상 사라집니다.
집단 프라이버시의 일반적 문제 중 하나는 그룹의 한 구성원의 행동이 다른 구성원들이 공유되기를 원치 않는 정보를 드러내는 경우입니다. 예를 들어 한 사람이 함께 참석한 행사 사진을 게시할 때 다른 사람들은 자신의 참여가 공개되기를 원치 않을 수 있습니다. 연락처 업로드를 허용하는 사이트의 경우 업로드를 수행하는 사람이 자신의 소셜 네트워크 정보를 공개하는 데 더 개방적일 수 있어 연결된 사람들이 원하지 않는 공개가 발생할 수 있습니다. 이러한 문제들은 단순하고 명확한 해결책이 없을 수 있지만 웹사이트를 구축하는 사람들은 이를 신중히 고려해야 합니다.
투명성은 개인의 선택을 충분히 돕지 못하는 경우가 많지만, 연구자와 기자들이 우리의 집단적 의사결정에 관해 알릴 수 있게 하는 데 중요한 역할을 합니다. 이 고려사항은 TAG의 Strong and Secure Web Platform에 대한 결의를 확장하여, 정보 흐름과 자동화된 결정이 관여하는 경우 "광범위한 테스트와 감사가 계속 가능하도록" 해야 한다는 것을 보장합니다.
그러한 투명성은 데이터(자신의 개인 데이터에서 파생된 데이터 포함)에 대한 강한 접근 권한과 자동화된 결정의 결과를 설명할 메커니즘이 있을 때만 기능할 수 있습니다.
사용자 에이전트는 사람(그의 사용자)과 웹 사이의 중개자 역할을 합니다. 사용자 에이전트는 가능한 범위 내에서 개인에게 유리하게 집단적 거버넌스가 정한 원칙을 구현합니다. 이들은 정보 비대칭의 생성 방지를 추구하고, 사용자가 자동화 비대칭을 바로잡을 수 있도록 자동화를 제공합니다. 가능한 경우 이들은 사용자가 침해적인 메시지를 받지 않도록 보호합니다.
사용자 에이전트는 그것을 사용하는 사람과 완전히 일치하며 오직 그 사람의 이익을 위해 작동해야 합니다. 사용자 에이전트는 제1 당사자가 아닙니다. 사용자 에이전트는 그 사람의 이익을 항상 우선하는 신뢰할 수 있는 대리인입니다. 때때로 이는 위험한 결정을 수행하지 못하도록 막거나 결정을 내리는 속도를 늦추는 방식으로 그 사람을 자신으로부터 보호하는 것을 의미할 수 있습니다. 예를 들어 사용자 에이전트는 사이트의 진위를 확인할 수 없다면 누군가가 사이트에 연결하기 어렵게 만들며, 민감한 장치를 페이지에 노출하려 할 때 그 사용자가 정말로 의도했는지 확인합니다. 또한 사용자가 행동을 영구적으로 모니터링하도록 동의하는 것을 방지합니다. 그 의무들은 다음을 포함합니다 ([Taking-Trust-Seriously]):
이러한 의무들은 사용자 에이전트가 그 사용자를 진심으로 돌보도록 보장합니다. 학술 연구에서는 이러한 신뢰할 수 있는 대리인과의 관계를 종종 "수탁자적(fiduciary)"이라고 설명합니다 ([Fiduciary-Law], [Fiduciary-Model], [Taking-Trust-Seriously]; 긴 비공식적 논의를 위해 [Fiduciary-UA]를 참조하십시오). 일부 관할구역에서는 "수탁자"에 대해 별도의 법적 의미가 있을 수 있습니다.
이 문서의 나머지에서 설명하는 많은 원칙은 사용자 에이전트의 의무를 확장하고 보다 명확하게 만듭니다.
프라이버시 원칙들은 함께 작동하고 서로를 지원하도록 설계되었지만, 때때로 한 프라이버시 원칙을 더 잘 따르도록 시스템을 개선하려는 제안이 다른 원칙의 준수를 저해할 수 있습니다.
모든 원칙을 완벽하게 만족시키지 못하는 초기 설계가 주어지면, 보통 다른 몇몇 설계들이 있어 일부 원칙에 대한 상황을 개선하면서 다른 원칙을 희생하지 않는 경우가 있습니다. 그런 설계들을 찾기 위해 노력하세요.
다르게 말하면 원칙들 간의 거래를 시작하기 전에 파레토 개선을 찾아보라는 것입니다.
파레토 전선에서 서로 다른 설계들 중 하나를 고르는 경우, 어떤 프라이버시 원칙을 선호할지는 복잡하며 각 특정 상황의 세부 사항에 크게 의존합니다. 사람들의 프라이버시가 비프라이버시 관심사와도 긴장 상태에 있을 수 있다는 점을 유념해야 합니다. 윤리적 웹 원칙에서 논의된 바와 같이, "특정 기술이 적용되는 문맥, 그 기술의 예상 대상, 기술이 누구에게 이익이 되고 누구에게 불이익이 되는지, 그리고 관련된 권력 역학을 고려하는 것이 중요합니다" ([Ethical-Web-Principles]). 이러한 복잡성에도 불구하고 기본적인 규칙이 있습니다:
이는 데이터가 수집될 때 명시된 목적보다 더 많은 목적으로 사용되어서는 안 된다는 일반 원칙의 특별한 사례입니다.
서비스는 때때로 사람들의 데이터를 다른 사람을 보호하기 위해 사용합니다. 그러한 서비스를 운영하는 주체는 어떤 데이터를 이러한 목적을 위해 사용하는지 설명해야 합니다. 또한 서비스는 사용자가 규칙을 위반했다고 판단할 경우 그 사람의 데이터를 어떻게 사용하거나 공유할 수 있는지도 밝혀야 합니다.
누군가가 사용 중인 서비스의 규칙을 위반하면 그에 상응하는 정도만큼 프라이버시 보호를 희생한다고 말하기는 매력적이지만
다음 예시들은 이러한 긴장 중 일부를 보여줍니다:
이 섹션은 일반적으로 웹의 문맥에 적용되도록 고안된 일련의 원칙들을 설명합니다. 웹의 특정한 문맥은 더 많은 제약이나 다른 고려사항이 필요할 수 있습니다. 시간이 지나면서 더 구체적인 문맥에 대한 보다 전문화된 개인정보 원칙들이 발표될 것으로 예상합니다.
이러한 원칙들은 사용자 에이전트에 의해 시행되어야 합니다. 이것이 불가능한 경우에는, 다른 주체들이 이를 시행할 방법을 찾도록 권장합니다.
한 사람의 신원은 그들을 정의하는 특성들의 집합입니다. 특정한 문맥에서의 그들의 신원은 특정한 상황에서 그들이 드러내는 특성들의 집합입니다.
사람들은 서로 다른 문맥에 서로 다른 신원을 제시할 수 있고, 하나의 신원을 여러 다른 문맥에서 공유할 수도 있습니다.
사람들은 일시적이거나 익명인 신원을 제시하기를 원할 수 있습니다. 이는 시간에 따라 추적하는 데 쓸모없을 정도로 적거나 불안정한 특성들의 집합입니다.
한 사람의 신원들은 종종 그들이 보유한 법적 신원과는 별개일 수 있습니다.
어떤 상황에서는, 이 원칙을 지키는 최선의 방법이 식별(인식)을 방지하는 것일 수 있습니다(예: 한 사이트가 자신의 사용자가 다른 사이트에서 한 행동에 대해 아무 것도 알 수 없도록).
다른 상황에서는, 이 원칙을 지키는 최선의 방법이 식별(인식)을 지원하는 것일 수 있습니다(예: 한 사용자가 다른 사이트에서 특정 신원을 가졌음을 한 사이트에 증명하도록 돕는 경우).
유사하게, 사용자 에이전트는 동일한 사이트에 대한 반복 방문 간에 식별(인식)을 방지하거나 지원함으로써 사용자를 도울 수 있습니다.
사용자 에이전트는 사이트 내에서의 문맥들을 구분하기 위해 최선을 다하고, 그들의 사용자의 바람에 따라 이러한 내부 사이트 문맥들 간의 식별(인식)을 방지하거나 지원하도록 그들의 분할을 조정해야 합니다.
데이터 최소화는 데이터가 노출되거나 오용될 위험을 줄입니다. 또한 사용자 에이전트와 기타 행위자들가 그들의 사용자가 내려야 할 결정을 더 의미있게 설명하는 데 도움이 됩니다. 자세한 내용은 웹 API의 데이터 최소화를 참조하십시오.
데이터 최소화 원칙은 식별 가능하다고 알려져 있지 않거나 민감하다고 알려져 있지 않더라도 모든 개인 데이터에 적용됩니다. 참조: 2.4 민감 정보.
사이트는 때때로 사용자의 주요 목표에 필요하지 않은 방식으로 데이터를 사용할 때가 있습니다. 예를 들어 광고주에게 과금하거나 사이트 성능을 측정하거나 개발자에게 버그를 알릴 수 있습니다. 이러한 것들은 데이터의 부수적 사용에 해당합니다.
부수적 사용은 데이터 처리가 주로 그 데이터의 주체인 사람 이외의 행위자들에게 직접적인 이익을 제공하는 모든 경우를 말합니다. 개인 데이터의 부수적 사용은 해당 개인에게 간접적인 이익을 제공할 수 있지만, 어떤 이익이 있더라도 그것은 간접적입니다. 예를 들어 광고주에게 과금할 수 있는 능력은 사이트가 비즈니스를 유지하고 향후 상호작용을 가능하게 한다는 이익을 제공하지만, 이 이익은 주로 사이트 소유자에게 실현됩니다.
사이트는 부수적 사용을 위해 다양한 출처에서 원하는 데이터를 얻을 수 있습니다:
이 모든 데이터 출처는 개인의 설정, 장치, 환경 또는 행동에 관한 개인 데이터를 드러낼 수 있으며, 이는 민감할 수 있고 브라우저 지문 채집의 일부로 사용되어 문맥 간 사람 식별을 가능하게 할 수 있습니다. 2.2 데이터 최소화 원칙을 지키기 위해, 사이트와 사용자 에이전트는 이 데이터의 사용에 대해 사람들의 목표와 선호를 이해하고 존중하도록 노력해야 합니다.
작업 그룹은 사용자 에이전트가 기존 정보로부터 계산되는 부수적 API를 어떻게 다루어야 하는지에 대해 합의를 보지 못했습니다. 이러한 API의 옹호자들은 이들이 개인 데이터를 추출하기 어렵고, 동일한 정보를 비부수적 API를 통해 수집하는 것보다 더 효율적이며, 많은 사람이 이를 끌 경우 사이트가 이러한 API를 채택할 가능성이 줄어들고, 이를 끄는 행위 자체가 브라우저 지문 채집에 기여할 수 있다고 주장합니다. 반대자들은 데이터가 더 쉽거나 더 저렴하게 수집될 수 있다면 더 많은 사이트가 이를 수집할 것이며, 여전히 일정한 위험이 있으므로 사용자가 직접 사이트의 기능을 크게 깨뜨리지 않는 API 그룹을 끌 수 있어야 한다고 주장합니다.
다른 사용자들이 서로 다른 선호를 가질 가능성이 있으므로:
대부분의 부수적 사용은 사이트가 어떤 개인 데이터를 학습할 필요가 없도록 합니다. 예를 들어, 사이트 성능 측정이나 광고 과금은 많은 사용자에 걸쳐 데이터를 평균하거나 합산하여 개별 기여를 흐릿하게 만듭니다. 개인 식별을 막음으로써 API가 개인 데이터를 노출하지 않고도 그 용례를 제공할 수 있게 하는 사적 집계 기술이 종종 가능합니다.
어떤 부수적 사용은 데이터가 사람과 관련될 필요는 없지만, 많은 사람들에 대한 유용한 집계를 웹 API에 설계하는 것이 어렵거나 새로운 기술의 발명이 필요할 수 있습니다. API 설계자가 이 상황을 처리할 수 있는 방법에는 다음과 같은 것들이 포함됩니다:
만약 어떤 API가 이러한 선택들 중 하나를 해야 하고, 그 API에 대해 다른 무언가가 변경될 필요가 있다면, 설계자들은 개인 데이터를 노출하지 않는 새로운 API로 전체를 대체하는 것을 고려해야 합니다.
일부 다른 부수적 사용은 사람이 자신의 데이터에 연결될 것을 요구합니다. 예를 들어, 어떤 사람이 웹사이트가 자신의 특정 컴퓨터에서 깨지는 버그 리포트를 제출하고 개발자가 버그를 수정하는 동안 후속 연락을 받을 수 있기를 원할 수 있습니다. 이것은 사용자의 허락을 묻기에 적절한 시기입니다.
어떤 사람들은 자신의 특정 상황에 대해 API 설계자들의 일반적 결정이 부적절하게 만드는 무언가를 알고 있을 수 있습니다. 새로운 정보를 제공하는 부수적 API가 다른 어떤 방법으로도 제공되지 않는 정보를 제공하므로, 사용자 에이전트는 브라우저 지문 채집의 추가 위험에도 불구하고 사용자가 이를 끌 수 있게 해야 합니다.
사이트들이 이용할 수 있는 많은 API들은 사람들, 웹 서버 및 기타 대상에 대한 많은 데이터를 노출하며, 이 데이터들은 결합되어 사람들에 관한 정보를 만들 수 있습니다.
사용자 제어 설정이나 권한은 웹의 데이터 접근을 차단(guard)할 수 있습니다. 웹 API를 설계할 때는 API가 정보를 적절한 방식으로 노출하도록 접근 차단을 사용하십시오.
정보를 얻는 새로운 방법을 추가하는 새로운 API는 기존의 유사한 방법들만큼 강하게 차단되어야 합니다.
한 집합의 접근 차단 하에서 노출되는 것이 허용될 수 있지만, 다른 집합에서는 허용되지 않을 수 있습니다. API 설계자가 그들의 새 API가 기존의 허용된 API가 이미 동일한 정보를 노출하므로 허용된다고 설명하려는 경우, 그들은 새 API가 적어도 동일하게 엄격한 차단 하에서만 제공되는지 주의 깊게 확인해야 합니다. 그런 차단이 없다면, 기존 API에 의존하지 않고 처음부터 새 API의 타당성을 입증해야 합니다.
만약 기존 API들이 어떤 정보에 대한 접근을 제공하지만 그 접근을 막기 위해 해당 API들을 변경할 계획이 있다면, 새 API는 그 동일한 정보를 제공해서는 안 되며, 그러한 정보를 제공하려면 추가적인 접근 차단을 포함하여 접근이 적절하도록 해야 합니다.
예를 들어, 브라우저들은 서로 다른 분할들 간의 신원 연결 능력을 점차 제거하고 있습니다. 새로운 API가 문맥 간 식별(인식)을 다시 가능하게 하는 기능을 추가하지 않는 것이 중요합니다.
누군가에 관한 많은 정보 조각들이 공개될 경우 프라이버시 해를 초래할 수 있습니다. 예를 들어:
특정 정보 조각의 민감성은 사람마다 다를 수 있습니다. 민감한 정보가 공개되었거나 공개될 가능성이 있으면 사람들은 취약해질 수 있습니다; 1.2 취약성를 참조하십시오.
데이터 권리만으로는 웹의 모든 프라이버시 원칙을 만족시키기에 충분하지 않지만, 이 권리들은 자기결정권을 지원하고 책임성을 향상시키는 데 도움을 줍니다. 이러한 권리들에는 다음이 포함됩니다:
이 권리에는 자신에 대해 수집되거나 추론된 정보가 무엇인지 검토하고, 자신에 관한 정보를 수집한 행위자들이 누구인지 발견할 수 있는 능력이 포함됩니다. 결과적으로 사람들에 관한 정보를 포함한 데이터베이스는 비밀로 유지될 수 없으며, 사람들에 대해 수집된 데이터는 그 사람들에 의해 의미있게 발견 가능해야 합니다.
한 사람은 서비스 이용을 완전히 종료하든 그렇지 않든 자신에 관한 정보를 삭제할 권리가 있습니다. 다만 어떤 데이터를 삭제할 수 있는지는 이 두 경우 사이에 다를 수 있습니다. 웹에서는 한 사람이 자신의 장치에서, 서버에서, 또는 둘 다의 데이터를 삭제하길 원할 수 있으며, 데이터의 위치가 항상 그 사람에게 명확하지 않을 수 있습니다.
이동성은 다양한 데이터 관행을 가진 서비스들에 대해 사람의 선택을 지원하는 데 필요합니다. 상호운용성 표준은 효과적인 재사용을 위해 필수적입니다. 사용자 데이터 전송에는 Portability-Threat-Model에 설명된 보안 및 프라이버시 위험이 수반됩니다.
자신에 관한 데이터가 시스템에 올바르게 반영되도록 보장하기 위한 수정권.
자신에 관한 데이터에 근거한 자동화된 의사결정으로부터 자유로울 권리(right to be free from automated decision-making).
중대한 결과를 초래하는 일부 종류의 의사결정에 대해서는 자동화된 프로파일링에서 자신을 제외할 수 있는 권리에 프라이버시 이익이 있습니다. 예를 들어, 일부 서비스는 사람에 대해 수집된 데이터를 바탕으로 상품의 가격(가격 차별)이나 신용 또는 보험 제공을 변경할 수 있습니다. 이러한 변경은 중요할 수 있고(예: 재정적), 그 결정이 부정확하거나 불공정하다고 여기는 사람들에게는 반감의 대상이 될 수 있습니다. 또 다른 예로, 일부 서비스는 카메라 데이터에 대해 실행되는 얼굴 인식 알고리즘을 기반으로 사용자의 정체성, 인간성 또는 존재에 대한 추론을 도출할 수 있습니다. 얼굴 인식 알고리즘과 학습 세트는 오류가 있고 특정 편향을 보일 수 있으므로 사람들은 그러한 자동화된 인식에 근거한 결정에 따르기를 원하지 않을 수 있습니다.
사람들은 동의에 대한 결정을 변경하거나 자신에 관한 데이터의 이후 사용에 대해 이의를 제기할 수 있습니다. 데이터 권리는 사람이 수집 시점의 일회성 선택이 아니라 지속적인 통제를 가질 필요가 있음을 의미합니다.
OECD 개인정보 원칙 [OECD-Guidelines], [Records-Computers-Rights], 및 [GDPR] 등은 사람들이 데이터 주체로서 가지는 많은 권리들을 설명합니다. 이러한 사람들의 데이터에 대한 참여 권리는 자율성에 내재되어 있습니다.
데이터는 그 데이터만으로 또는 사용 가능한 다른 정보와 결합해서도 그 데이터로 설명되는 어떤 사람을 직접 또는 간접적으로 식별할 수 없다는 높은 수준의 확신이 존재할 때 비식별화되었다고 합니다. 많은 지역 규정은 데이터가 비식별화되었다고 간주되기 위한 추가 요건을 정의하지만, 그러한 요건을 최고 수준의 프라이버시 보호로 간주해서는 안 됩니다. 그룹과 관련된 추가 고려사항들은 집단적 프라이버시 이슈 섹션에서 다룹니다.
제어된 비식별화 데이터라 함은 다음과 같은 경우를 말합니다:
제어된 비식별화 데이터를 포함하는 다양한 상황은 서로 다른 통제를 요구할 것입니다. 예를 들어, 만약 그 제어된 비식별화 데이터가 오직 한 행위자에 의해 처리된다면, 전형적인 통제에는 데이터에 사용된 식별자들이 해당 데이터셋에 고유하도록 하고, 그 데이터에 접근할 수 있는 어떤 사람(예: 그 행위자의 직원)이 데이터를 추가로 공유하지 못하도록 (예: 법적 조건에 기반하여) 차단하며, 재식별이나 이 데이터와 관련된 다른 데이터셋의 결합을 방지하기 위한 기술적 조치가 존재하도록 하는 것 등이 포함됩니다.
일반적으로 목표는 제어된 비식별화 데이터가 사용될 때 익명성의 유지 보장을 위한 기술적·절차적 수단이 보존되도록 적절한 감독과 책임성의 정도를 제공하는 방식으로 사용되도록 하는 것입니다.
이 제어된 비식별화 데이터가 여러 행위자 간에 공유될 때는 더 어렵습니다. 이러한 경우, 모범 사례를 대표하는 전형적인 통제의 좋은 예로는 다음을 보장하는 것이 포함됩니다:
데이터에 사용된 식별자가 직접적이고 배타적으로 제1 당사자(사람이 직접 상호작용하는 행위자)의 관리 하에 있고, 식별자와 데이터를 매칭하지 못하도록 엄격한 통제로 보호되는지;
이러한 식별자들이 제3자와 공유될 때에는 그 제3자에 고유하도록 만들어져 여러 제3자에게 공유될 경우 서로 매칭할 수 없도록 하는지;
어떤 제3자도 그 데이터를 제1 당사자와의 상호작용을 통해 얻은 것 이외의 다른 데이터와 매칭할 수 없다는 강한 확신이 존재하는지;
재식별이나 이 데이터를 포함하는 다른 데이터셋의 결합을 방지하는 기술적 조치가 존재하는지;
해당 데이터를 공유하는 제1 당사자와 제3자 간에 데이터가 공유되는 제한된 목적을 설명하는 계약 조건이 존재하는지.
제어된 비식별화 데이터 자체만으로는 데이터 처리를 적절한 것으로 만들기에 충분하지 않다는 점에 유의하십시오.
프라이버시 원칙들은 종종 개인에게 권리를 확장하는 방식으로 정의됩니다. 그러나 어떤 경우에는 어떤 원칙이 적용될지 결정하는 것이 그룹을 대신하여 집단적으로 결정하는 것이 최선일 수 있습니다. 집단적 의사결정은 다음의 경우 고려되어야 합니다:
처리되는 데이터에 따라 정당한 다양한 형태의 집단적 의사결정이 있습니다. 이러한 형태는 다양한 행정 수준의 정부 기관, 표준화 기구, 노동자 단체 협상체, 시민 사회 포럼 등이 될 수 있습니다. 집단적 의사결정은 개인에게 프라이버시 노동을 떠넘기는 것보다 더 나을 수 있지만 만능 해결책은 아닙니다. 의사결정 기구는 신중히 설계되어야 하며, 예를 들어 Institutional Analysis and Development 프레임워크를 사용하는 것 등을 고려해야 합니다.
이 원칙이 1.2.1 보호자를 가진 취약한 사람들에게 어떻게 적용되는지에 대한 자세한 내용은 해당 항목을 참조하십시오.
컴퓨팅 장치에는 설치 및 구성 권한을 갖기 위해 장치에 대한 특권 접근 권한을 가진 관리자가 있습니다. 장치의 소유자는 장치를 전체적으로 관리할 수 있도록 관리자에게 권한을 부여할 수 있습니다. 일부 사용자 에이전트 구현은 로그인된 계정에 따라 특정 사용자 에이전트를 관리하도록 관리자를 지정할 수도 있습니다.
때로는 장치를 사용하는 사람이 장치를 소유하지 않거나 관리자 접근 권한이 없을 수 있습니다(예: 고용주가 직원에게 장치를 제공하는 경우; 친구가 손님에게 장치를 빌려주는 경우; 또는 부모가 어린 자녀에게 장치를 제공하는 경우). 다른 경우에는 장치의 소유자이자 주 사용자가 관리자 접근 권한을 가진 유일한 사람이 아닐 수도 있습니다.
이러한 관계는 권력 불균형을 수반할 수 있습니다. 아이는 부모가 제공한 장치 외에는 어떤 컴퓨팅 장치에도 접근하기 어려울 수 있습니다. 학대의 희생자는 파트너가 장치에 대한 관리자 접근 권한을 갖지 못하게 막을 수 없을 수도 있습니다. 직원은 직장을 유지하기 위해 고용주의 장치를 사용하기로 동의해야 할 수 있습니다.
장치 소유자는 장치가 의도한 방식으로 사용되도록 할 이해관계와 때로는 책임을 가질 수 있지만, 장치를 사용하는 사람은 장치를 사용하는 동안에도 프라이버시 권리를 가집니다. 이 원칙은 두 가지 방식으로 이 프라이버시 권리를 시행합니다:
어떤 관리자 요청은 직원이나 자녀 같은 특정 종류의 사용자에게는 합리적일 수 있지만 친구나 친밀한 파트너 같은 다른 종류의 사용자에게는 합리적이지 않을 수 있습니다. 사용자 에이전트는 관리자가 무엇을 알게 될 것인지 설명하여 다양한 사용자가 적절히 대응할 수 있도록 해야 합니다.
디지털 남용은 디지털 수단을 통해 사람을 학대하는 것입니다. 온라인 괴롭힘은 "해로운 행동을 통해 개인이나 그룹을 온라인에서 광범위하거나 심각하게 표적화하는 것"으로 정의되며 [PEN-Harassment] 이는 남용의 한 형태입니다. 괴롭힘은 특히 소셜 미디어를 통해 널리 퍼져 있는 문제로, 모든 웹 사용자가 영향을 받을 수 있지만 LGBTQ 사람들, 여성, 인종 또는 민족적 소수자들, 장애인들, 취약한 사람들 및 기타 소외된 그룹에게는 더 심각하고 그 결과가 더 큰 영향을 미칠 수 있습니다.
괴롭힘은 프라이버시 자체의 침해일 뿐만 아니라 다른 프라이버시 침해에 의해 가능해지거나 악화될 수 있습니다.
괴롭힘에는 원치 않는 정보 전송(원치 않는 정보); 타인에게 특정인을 연락하거나 괴롭히도록 지시하는 행위("도그파일링"); 개인에 관한 민감 정보의 공개; 개인에 대한 허위 정보 게시; 사칭; 모욕; 위협; 그리고 혐오적이거나 모욕적인 발언 등이 포함될 수 있습니다.
식별 정보 또는 연락처 정보의 공개(일명 "doxxing")는 종종 추가 공격자들이 지속적인 원치 않는 정보를 보내 괴롭힘을 가하도록 유발하는 데 사용될 수 있습니다. 위치 정보의 공개는 개인의 물리적 안전이나 공간을 침해하는 데 사용될 수 있습니다.
보고 메커니즘은 완화 수단이지만, 호스트나 중재자들이 남용에 협조적이거나 동조적인 경우에는 괴롭힘을 막지 못할 수도 있습니다.
효과적인 보고는 다음을 필요로 할 가능성이 큽니다:
원치 않는 정보는 스팸과 같이 개별적으로는 보통 무해하지만 집합적으로 성가시게 되는 메시지부터 명확하고 충격적이며 폭력적인 이미지의 전송까지 광범위한 원치 않는 통신을 포함합니다.
시스템 설계자들은 원치 않는 정보를 보내는 것을 더 어렵게 또는 더 비용이 들게 만들고, 발신자들의 책임성을 높이기 위한 조치를 취해야 합니다.
목적을 위해 설계된 기능들은 특정 목적에만 또는 주로 유용한 기능을 제공함으로써 이러한 원칙들을 촉진합니다. 목적 지향 기능은 사람들에게 목적을 설명하기 쉽게 만들고 데이터의 가능한 부차적 사용을 제한할 수 있습니다. 목적 지향 기능을 구축할 때는 고수준 API와 저수준 API 간의 트레이드오프를 고려하십시오.
제어된 비식별화 데이터는 명시된 목적과 호환되는 방식으로 추가 목적에 사용될 수 있습니다.
투명성은 동의에 필요한 조건이지만 충분하지는 않습니다. 관련 설명 정보에는 누가 데이터를 접근하는지, 어떤 데이터가 접근되는지(해당 데이터로 추론되거나 결합될 수 있는 가능성을 포함) 및 데이터가 어떻게 사용되는지가 포함됩니다. 투명성이 사람들에게 의미 있으려면 설명 정보는 관련 문맥에서 제공되어야 합니다.
권한을 수반할 수 있는 새로운 웹 기능을 설계할 때, 권한이 필요한지 그리고 그 권한을 어떻게 의미있게 만들 것인지 고려하십시오 [Adding-Permissions].
과거 워크숍들은 웹에서 더 나은 권한에 대한 필요성을 탐구했습니다:
프라이버시 관련 관행의 기계 판독 가능 표현은 사용자 에이전트가 사람들을 돕기 위해 일반적 결정을 내리는 데 필요합니다. 이는 사람들이 매번 웹사이트를 방문할 때 문서를 읽을 수 있거나 읽고 싶어한다고 잘못 의존하는 것보다 더 낫습니다. 기계 판독 가능 표현은 또한 연구자와 규제 기관이 데이터 수집 및 처리를 발견, 문서화 및 분석하여 해로울 수 있는 사례를 식별하는 것을 더 용이하게 함으로써 집단적 거버넌스를 촉진합니다.
접근하기 쉬운 평이한 언어로 된 프라이버시 관련 관행의 제시는 사람들이 특정 경우에 정보에 입각한 결정을 내릴 수 있도록 하기 위해 필요합니다. 사이트, 사용자 에이전트, 및 기타 행위자들은 모두 접근 가능한 형식으로 프라이버시 관련 관행을 사람들에게 제시해야 할 수 있습니다.
비투명한 방식의 식별(인식) 방법들은 사용자에게 보이지 않아 사용자 통제를 약화시키기 때문에 해롭습니다 [Unsanctioned-Tracking]. 데이터를 최소화하고 데이터 요청을 명시적으로 만드는 기능들을 설계하면 탐지 가능성을 가능하게 할 수 있으며, 이는 브라우저 지문 채집에 대한 중요한 완화책인 투명성의 한 형태입니다.
사람의 진정한 선호와 일치하지 않는 처리를 위해 동의를 얻으려는 시도는 그 사람에게 원치 않는 프라이버시 노동을 부과하고, 사람들이 나중에 후회할 동의를 잘못 주게 만들 수 있습니다.
어떤 행위자는 그 사람이 충분히 정보에 기반해 동의를 할 수 있을 가능성이 낮다면 동의를 묻지 말아야 합니다. 사람이 동의를 묻기 위해 충분히 정보에 기반해 있다고 간주할 수 있는지 여부를 고려할 때, 행위자들은 그들이 요구하는 처리 내용을 이해하는 데 필요한 시간과 노력이 얼마나 될지 현실적으로 평가해야 합니다. 복잡한 정책에 대한 링크를 단순히 제공하는 것은 그 사람이 정보에 기반해 있다고 보기 어렵습니다.
사용자를 중단시키는 동의 요청의 대안 예시는 다음과 같습니다:
사이트의 대상 사용자층과 범주의 정보 공유 규범을 고려하고 사이트 목적에 적절한 동의만 요청하기. (예: 사진 공유 사이트의 사용자는 업로드한 작품 공유에 대한 동의를 요구받을 것으로 기대할 수 있습니다.) 사이트는 데이터가 어떻게 처리되는지에 대한 사람들의 기대를 조사하기 위해 사용자 연구를 고려해야 합니다.
요청을 문맥화하는 어떤 행동을 사용자가 할 때까지 동의 프롬프트를 지연시키기 — 이는 또한 정보에 입각한 응답을 돕습니다.
한 사람이 다른 사람들에 관한 데이터를 공유할 수 있습니다(예: 여러 사람이 포함된 사진). 그 사람이 그 데이터의 처리를 동의했다 해서 다른 사람들이 자동으로 동의한 것은 아닙니다.
알림 및 기타 방해성 UI는 주의를 끌기 위한 강력한 수단이 될 수 있습니다. 사용 중인 운영체제에 따라 알림은 브라우저 문맥 밖(예: 일반 알림 트레이)에 나타나거나 장치를 진동시키거나 경고음을 울릴 수도 있습니다. 모든 강력한 기능과 마찬가지로 알림은 오용될 수 있으며 성가심을 유발하거나 행위를 조작하는 데 사용되어 자율성을 감소시킬 수 있습니다.
사용자 에이전트는 어떤 웹 사이트가 경고를 표시하도록 권한을 부여받았는지 감시하고 이러한 권한을 취소할 수 있는 UI를 제공해야 합니다. 사용자 에이전트는 또한 알림 수신 권한의 초기 요청에 대해 품질 지표를 적용해야 합니다(예: 첫 방문 시 사이트가 권한을 요청하는 것을 허용하지 않기).
웹 사이트는 알림 전송 권한을 요청할 때 사용자에게 어떤 특정 종류의 정보를 받을 것으로 기대할 수 있는지, 그리고 알림을 끄는 방법을 알려야 합니다. 웹 사이트는 사용자가 충분한 지식(예: 어떤 종류의 알림에 가입하는지에 대한 정보)을 가질 가능성이 낮을 때 알림 전송 권한을 요청해서는 안 됩니다. 그런 정보가 제공될 가능성이 낮다면 사용자 에이전트는 완화책(예: 알림 API의 잠재적 악용에 대한 경고)을 적용해야 합니다. 권한은 문맥에서 요청되어야 합니다.
사람들은 자신이 공유하는 비공개 정보의 양을 제한하거나, 이미 공유된 데이터의 사용을 제한하도록 행위자에게 요청하거나, 데이터를 삭제하도록 요청할 자유가 있어야 합니다. 어떤 사람이 자신의 데이터 사용 권한을 거부하거나 철회하는 것을 선택할 때, 보복은 부적절합니다.
서비스 운영에 필수적인 데이터가 보류될 때 서비스를 종료하는 것은 보복이 아닙니다. 그러나 데이터 보류가 해당 데이터의 사용과 무관한 조치로 이어진다면 이는 보복일 수 있습니다. 보복 행위의 예는 다음과 같습니다:
동의를 철회하는 과정을 동의를 주는 것보다 더 번거롭게 만드는 것;
사람들이 선택을 다시 고려하도록 위협, 괴롭힘 또는 속임수(예: dark-patterns)를 사용하는 것;
데이터 사용과 무관한 서비스를 거부하는 것.
행위자들은 데이터를 자동으로 수집하는 방법을 자동화하는 데 시간과 에너지를 투자할 수 있고, 제품을 설계하여 사람들이 정보를 공개하도록 만드는 것이 공개하지 않는 것보다 훨씬 쉽도록 할 수 있습니다. 반면에 사람들은 보통 옵션, 반복 프롬프트, 및 기만적 패턴을 수동으로 헤쳐나가야 합니다. 많은 경우, 정보의 부재 — 즉 어떤 사람이 일부 정보를 제공하지 않기로 거부하는 것 — 도 식별 가능하거나 노출될 수 있습니다. 또한 API들은 사람들의 유용한 기능 접근을 막는 경직된 방식으로 정의되거나 구현될 수 있습니다. 예를 들어, 내가 이번 주말에 방문할 도시에서 식당을 찾고 싶을 때, 내 지리 위치가 강제로 GPS와 일치하도록 설정되어 있으면 식당 찾기 사이트가 현재 위치에서만 검색을 허용할 수 있습니다. 다른 경우에는 사이트가 데이터 최소화 원칙을 준수하지 않아 요구하는 정보가 실제로 필요한 것보다 많을 수 있습니다. 이 원칙은 사람들이 자신의 데이터를 최소화하도록 지원합니다.
사용자 에이전트는 사람들이 원하는 신원을 제시하고 자신이나 자신의 장치에 관한 정보를 자신이 제어하는 방식으로 제공하는 것을 간단하게 만들어야 합니다. 이는 사람들이 은둔 상태로 살도록 돕고([Lost-In-Crowd], [Obscurity-By-Design]), 자신에 관한 정보를 난독화하는 데 기여할 수 있습니다([Obfuscation]).
대신, API는 사람의 선호, 선택한 신원, 쿼리나 관심사, 또는 선택한 통신 스타일을 나타낼 수 있습니다.
예를 들어, 사용자 에이전트는 다음과 같은 방식으로 이 원칙을 지원할 수 있습니다:
사이트는 위협 모델링에 속임수를 포함시키고 웹 플랫폼 API가 사용자에 대해 일관성, 최신성 또는 정확성에 관한 어떠한 보장도 제공하지 않는다고 가정해야 합니다. 사람들은 사이트와 상호작용하기 위해 사용하는 장치와 소프트웨어를 종종 제어할 수 있습니다. 사이트 요청에 응답하여 사람들은 악의적이든 자기 보호적이든 다양한 이유로 제공하는 정보를 임의로 수정하거나 선택할 수 있습니다.
API가 참된 현재 값을 반환하도록 정의되어야 하는 드문 경우에도, 사용자는 여전히 테스트, 감시 또는 데이터 수집 형태(예: 브라우저 지문 채집)를 완화하기 위해 에이전트를 구성하여 다른 정보로 응답할 수 있습니다.
A 사람 (또는 사용자 또는 데이터 주체)는 자연인을 의미합니다. 이 문서 전반에서 우리는 주로 인간임을 상기시키기 위해 사람 또는 사람들이라는 표현을 사용합니다. 한편 사용자라는 용어를 쓸 때는 특정 시점에 주어진 시스템을 사용하고 있는 특정 사람을 가리킵니다.
A 취약한 사람은 특정 문맥에서 자신의 선택 능력이 보통보다 더 쉽게 박탈될 수 있는 사람을 말합니다. 이들은 더 강한 기본 프라이버시 보호를 받아야 하며 시스템과의 다양한 상호작용에 대해 동의할 수 없는 것으로 간주될 수도 있습니다. 사람들은 여러 이유로 취약할 수 있고, 특정 문맥에서만 취약할 수도 있습니다. 예를 들어, 어린이는 여러 문맥에서 취약할 수 있지만, 고용주나 다른 행위자와 권력 불균형에 있는 사람은 그 행위자가 존재하는 문맥에서 취약할 수 있습니다. 1.2 취약성을 참조하십시오.
A 문맥은 사람들이 다른 행위자들과 상호작용하는 물리적 또는 디지털 환경이며, 그 사람들이 다른 문맥들과 구별되는 것으로 이해하는 환경을 의미합니다.
어떤 문맥은 누가 그것을 소유하거나 통제하는지로 정의되지 않습니다. 한 회사의 서로 다른 문맥 사이에서 데이터를 공유하는 것은, 동일한 데이터가 관련 없는 다른 행위자들 사이에서 공유되는 것과 마찬가지로 프라이버시 침해가 될 수 있습니다.
An 행위자는 한 사람이 합리적으로 단일한 "대상"으로 이해할 수 있는 존재입니다. 행위자는 개인일 수도 있고 회사, 협회, 정부 기관과 같은 집단적 존재일 수도 있습니다.
사용자 에이전트는 사람에게 어떤 오리진이나 사이트가 그들이 보고 있는 웹 페이지를 제공했는지 설명하는 경향이 있다. 이 행위자는 해당 오리진 또는 사이트에서 콘텐츠 및 데이터 처리에 대한 결정을 하거나 위임하는 사람이며, 웹 페이지의 퍼스트 파티(첫 번째 당사자)로 알려져 있다. 사람이 웹 페이지의 일부와 상호작용할 때, 그 상호작용의 퍼스트 파티는 일반적으로 해당 웹 페이지의 퍼스트 파티이다. 하지만, 만약 다른 행위자가 그 부분의 동작 방식에 대해 결정을 내리고, 현실적으로 합리적인 사람이 시간과 에너지를 들이면 이 다른 행위자가 이 통제력을 가지고 있음을 알게 될 수 있다면, 이 다른 행위자가 상호작용에 대한 퍼스트 파티가 된다.
누군가가 웹 페이지와의 상호작용에 관한 데이터를 캡처하면, 그 상호작용의 제1 당사자는 설사 다른 행위자가 처리를 하더라도 그 데이터가 어떻게 처리되는지에 대해 책임을 집니다.
A 제3자는 웹사이트를 방문하는 사람이나 그들이 상호작용할 것으로 예상하는 제1 당사자들 이외의 모든 행위자를 의미합니다.
우리는 개인 데이터를 식별되었거나 식별 가능한 사람과 직접적 또는 간접적으로 관련된 모든 정보로 정의합니다. 예를 들어 식별자를 통해 관련될 수 있습니다([GDPR], [OECD-Guidelines], [Convention-108]).
웹에서는 어떤 유형의 식별자가 보통 웹사이트에서 관찰되는 신원에 할당되며, 이는 자동화된 시스템이 그 사람에 관한 데이터를 저장하기 쉽게 만듭니다.
어떤 사람이 다른 데이터들과의 조합을 통해 합리적으로 식별되거나 재식별될 수 있다면, 두 데이터 세트 모두가 개인 데이터로 간주됩니다.
사람들은 특정 문맥에서 해당 문맥의 원칙을 따르는 행위자들이 정보를 제시하고 개인 데이터를 사용할 때 프라이버시를 가진다고 할 수 있습니다. 해당 문맥의 원칙이 지켜지지 않으면 프라이버시 침해가 발생합니다. 특정 상호작용이 원칙을 따를 때 우리는 그것을 적절하다고 말하고, 그렇지 않을 때는 부적절하다고 말합니다.
어떤 행위자가 데이터를 처리한다고 말할 때는, 자동화 수단이든 아니든 수집, 기록, 조직, 구조화, 저장, 적응 또는 변경, 검색, 조회, 이용, 전송을 통한 공개, 공유, 배포 또는 제공, 판매, 정렬 또는 결합, 제한, 삭제 또는 파기와 같은 작업을 수행하는 것을 의미합니다.
어떤 행위자가 데이터를 공유한다고 할 때는 그가 데이터를 다른 데이터 관리자(data controller)에게 제공하는 경우를 말합니다. 이 정의에 따르면, 자신의 서비스 제공업체에게 데이터를 제공하는 행위자는 이를 공유하는 것으로 보지 않습니다.
어떤 행위자가 데이터를 판매한다고 말할 때는, 가치 있는 무언가와 교환하여 데이터를 공유하는 경우를 의미합니다. 이 가치가 금전적이지 않더라도 판매에 해당합니다.
주어진 데이터 처리의 목적은 해당 처리의 예측되거나 의도된 또는 계획된 결과로, 주어진 문맥 내에서 달성되거나 목표로 삼는 것입니다. 목적은 설명될 때 해당 문맥에 익숙한 사람이 그 목적을 달성할 일부 수단을 선택할 수 있을 정도로 충분히 구체적이어야 합니다.
수단(means)은 특정 목적을 달성하기 위해 주어진 문맥에서 데이터가 처리되는 일반적인 방식을 의미합니다. 수단은 비교적 추상적이며 구현 세부사항까지 모두 지정하지 않습니다. 예를 들어, 어떤 사람의 선호를 복원하는 목적에 대해 수단은 식별자를 환경설정 저장소에서 조회하는 것이 될 수 있습니다.
데이터 관리자(data controller)는 데이터 처리의 수단과 목적을 결정하는 행위자입니다. 어떤 행위자가 서비스 제공업체가 아니라면 그 행위자는 데이터 관리자입니다.
서비스 제공업체 또는 데이터 처리자는 다음과 같습니다:
식별(Recognition)은 주어진 신원이 다른 신원과 동일한 사람에 해당한다는 것을 인식하는 행위입니다. 그 다른 신원은 다른 문맥에서 관찰되었을 수도 있고, 동일한 문맥에서 다른 시점에 관찰되었을 수도 있습니다. 식별은 확률적일 수 있으며, 두 신원이 동일한 사람에 해당할 높은 확률이 있다고 인식되는 경우에도 확실하지 않을 수 있습니다.
한 사람은 그들의 법적 신원이나 법적 신원의 특성이 포함되어 있든 없든 식별될 수 있습니다.
발생할 수 있는 여러 유형의 식별이 있습니다.
문맥 간 식별(Cross-context recognition)은 서로 다른 문맥들 사이의 식별을 의미합니다.
문맥 간 식별은 식별되는 사람이 합리적으로 식별이 일어날 것을 기대할 수 있고, 그 식별을 통제할 수 있는 경우에만 적절합니다.
한 사람이 두 개의 서로 다른 문맥(예: 이메일이나 전화번호)에서 식별 정보를 사용할 경우, 이것이 그들이 양쪽 문맥에서 같은 신원을 사용하고자 한다는 것을 자동으로 의미하지는 않습니다. 그들이 단일 신원을 사용하려 의도했음을 나타내는 다른 표시가 없는 한, 그 정보를 사용해 그들을 식별하는 것은 부적절합니다. 또한 문맥 간 식별을 돕기 위해 추가적인 식별 정보를 찾는 것도 부적절합니다.
문맥들 사이에서 사람들을 식별하는 시스템은 한 문맥에서 획득한 정보의 사용에 관한 원칙을 다른 문맥에서 획득한 정보의 사용 원칙을 침해하지 않도록 주의해야 합니다. 이는 특히 취약한 사람들에게 중요합니다. 다른 문맥들에서 그들을 식별하면 그들의 취약성을 드러내는 특성들이 노출될 수 있기 때문입니다. 예를 들어 치료사를 파티에서 만나면, 치료사는 평소와 다른 주제로 당신과 대화를 나누거나 심지어 당신을 모르는 척할 것으로 기대할 수 있습니다.
사이트 간 식별(Cross-site recognition)은 서로 다른 사이트들에서 신원들이 관찰될 때의 식별입니다. 일반적으로 사이트들이 서로 다른 문맥인 경우, 사이트 간 식별은 문맥 간 식별과 동일한 경우에 부적절합니다.
동일 사이트 내 식별(Same-site recognition)은 단일 사이트가 두 번 이상 방문된 경우에 한 사람을 식별하는 경우입니다.
만약 한 사람이 단일 사이트에 대해 서로 다른 방문에서 다른 신원을 사용할 것으로 합리적으로 기대하는데도 그 사이트가 그들을 어쨌든 식별한다면 프라이버시 피해가 발생합니다.
이들 범주가 서로 겹친다는 점에 유의하십시오: 사이트 간 식별은 보통 문맥 간 식별입니다(그리고 항상 식별하여 파티션들 간에 인식합니다); 그리고 동일 사이트 내 식별은 때때로 문맥 간 식별이 될 수 있으며(그리고 복수의 파티션을 포함할 수도 있고 아닐 수도 있습니다).
A 파티션(partition)은 사용자 에이전트가 사용자가 문맥을 이해하는 방식을 맞추려는 시도입니다. 사용자 에이전트는 사용자가 방문하는 사이트를 경험하는 방식을 완벽히 이해하지 못하므로, 파티션을 구성할 때 종종 문맥들 사이의 경계를 근사해야 합니다.
더 나은 정보가 없는 경우 파티션은 다음과 같이 정의될 수 있습니다:
iframes,
워커, 최상위 페이지 등)
하나의 사이트가 여러 문맥을 포함하는지를 사용자 에이전트가 감지하는 것은 어려울 수 있습니다. 사용자 에이전트가 이를 감지할 수 있을 때에는, 예를 들어 서브도메인이나 사이트 경로별로 신원을 분할하는 등 그에 따라 파티션을 조정해야 합니다. 사용자 에이전트는 사이트 내에서 문맥을 구별하는 능력을 향상시키기 위해 노력해야 합니다.
사용자 에이전트는 사용자가 의도하지 않는 한 파티션들 간에 식별되는 것을 방지해야 합니다.
사이트는 방문이 동일한 사람으로부터 왔는지 완전히 확신하지 못하더라도 피해를 유발할 수 있으므로, 사용자 에이전트는 이러한 확률적 식별을 방지하기 위한 조치도 취해야 합니다. 타깃 프라이버시 위협 모델을 다루는 Target Privacy Threat Model는 관련된 절충을 논의합니다 ([Privacy-Threat]).
사용자 에이전트가 사용자가 특정 사이트에서 특정 신원을 사용하고 있다는 것을 알 수 있다면, 그 활성 신원을 사용자에게 명확히 표시해야 합니다(예: 사용자가 Credential Management Level 1 같은 API를 통해 사이트에 로그인한 경우).
이 문서는 주로 정보 제공 목적이기 때문에 [RFC2119]의 엄격한 용어를 따르지 않습니다. 하지만 원칙을 서술할 때, "should"는 유효한 이유가 있을 경우 드물게 원칙을 예외로 둘 수 있음을 나타내기 위해 사용했고, "must"는 해당 원칙을 위반할 수 있는 정당한 상황이 없음을 의미함을 주의하여 사용했습니다.
이 문서에 포함된 일부 정의는 Tracking Preference Expression (DNT)의 작업을 기반으로 하고 있습니다.
아래의 분들은 이름 알파벳 순으로, 이 문서의 작성에 중요한 역할을 했으며 귀중한 기여를 해주셨습니다: Amy Guy, Ben Savage, Chris Needham, Christine Runnegar, Dan Appelquist, Don Marti, François Daoust, Ian Jacobs, Irene Knapp, Jonathan Kingston, Kyle Den Hartog, Mark Nottingham, Martin Thomson, Nick Doty, Peter Snyder, Sam Weiler, Shubhie Panicker, Tess O'Connor, 그리고 Wendy Seltzer.
이 명세에는 등재된 이슈가 없습니다.
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: