자체 검토 설문지: 보안 및 개인정보 보호

1. 소개

웹 플랫폼을 위한 새 기능을 설계할 때, 우리는 항상 작업의 보안 및 개인정보 보호 영향을 고려해야 합니다. 새로운 웹 기능은 항상 웹의 전반적인 보안과 개인정보 보호를 유지하거나 향상해야 합니다.

이 문서는 명세 작성자가 자신의 작업의 보안 및 개인정보 보호 영향을 검토하고, 아래 § 2.16 이 명세에는 "보안 고려사항"과 "개인정보 보호 고려사항" 절이 모두 있는가?에 설명된 대로 자신의 명세 안에 포함할 서술형 보안 고려사항 및 개인정보 보호 고려사항 절을 작성하는 데 도움을 주기 위한 질문 모음을 담고 있습니다. 또한 명세 작성자가 명세 작업 중 마주치는 보안 및 개인정보 보호 우려를 다루는 데 사용할 수 있는 완화 전략도 문서화합니다.

이 문서 자체도 진행 중인 작업이며, 이 문서가 (아직) 다루지 않는 보안 또는 개인정보 보호 우려가 있을 수 있습니다. 이 설문지가 물어야 할 보안 또는 개인정보 보호 우려를 발견하면 알려 주세요.

1.1. 설문지 사용 방법

설계 과정의 초기에, 변경하기가 더 쉬울 때 이 질문들을 검토하십시오. 개인정보 보호 및 보안 문제가 나중에야, 기능이 배포된 뒤에 발견되면, 설계를 변경하기가 훨씬 더 어렵습니다. 보안 또는 개인정보 보호 문제가 늦게 발견되면, 사용자 에이전트는 문제를 해결하기 위해 호환성을 깨는 변경을 채택해야 할 수 있습니다.

명세 작업을 하는 동안 이 질문들을 염두에 두십시오. 특히 시간이 지남에 따라 설계가 변경될 때, 이 설문지를 주기적으로 다시 살펴보고 질문들을 계속 고려하십시오.

1.2. 추가 리소스

Privacy WG가 발행한 Mitigating Browser Fingerprinting in Web Specifications [FINGERPRINTING-GUIDANCE] 문서는 브라우저 지문 채취에 대해 더 깊이 다루며, 이 문서와 함께 고려해야 합니다.

개인정보 보호 고려사항에 관한 IETF의 RFC인 [RFC6973]는 훌륭한 리소스이며, 특히 7절이 그렇습니다.

1.3. TAG, Privacy WG, Security IG, 그리고 이 설문지

Privacy Working Group 및 Security Interest Group에 개인정보 보호 및 보안 검토를 요청하기 전에, § 2.16 이 명세에는 "보안 고려사항"과 "개인정보 보호 고려사항" 절이 모두 있는가?에 설명된 대로 문서에 "보안 고려사항" 및 "개인정보 보호 고려사항" 절을 작성하십시오. 이 문서의 질문에 답하는 것이 그러한 절을 작성하는 데 도움이 되기를 바랍니다. 그러나 이 설문지를 그대로 그 절들에 복사하는 것은 적절하지 않습니다. 보안 및 개인정보 보호 검토 요청 방법에 대한 지침은 How to do Wide Review 문서에서 찾을 수 있습니다.

Technical Architecture Group (TAG)에 검토를 요청할 때에는, 이 문서의 질문에 대한 답변을 TAG에 제공해 주십시오. 그렇게 할 때 이 Markdown 템플릿이 유용할 수 있습니다.

2. 고려할 질문

2.1. 이 기능은 어떤 정보를 노출하며, 어떤 목적을 위한 것인가?

사용자 에이전트는 명확한 사용자 필요를 충족하는 데 필요한 경우에만 정보를 웹에 노출해야 합니다. 여러분의 기능은 웹사이트에 정보를 노출합니까? 그렇다면 이 정보를 노출하는 것이 사용자에게 어떤 이익을 줍니까? 사용자에게 가해지는 위험보다 사용자에게 주는 이익이 더 큽니까? 그렇다면 어떻게 그렇습니까?

다음도 참조하십시오

• Web Platform Design Principles § priority-of-constituencies

이 질문에 답할 때, 정보 공개 / 공유의 가능한 네 가지 영역 각각을 고려해 주십시오.

아래 하위 질문들에서는, 잠재적으로 식별 가능한 정보라는 용어를 같은 브라우저 버전을 사용하는 다른 사람들과 구별되는 브라우저 사용자에 대해 설명하는 정보라는 뜻으로 사용해 주십시오. 이러한 잠재적으로 식별 가능한 정보의 예에는 브라우저 사용자의 환경(예: 운영 체제 구성, 브라우저 구성, 하드웨어 기능)에 관한 정보와 사용자의 이전 활동 및 관심사(예: 브라우징 이력, 구매 선호도, 개인적 특성)가 포함됩니다.

1. 여러분의 명세가 일차 당사자에게 노출하는 정보 중 일차 당사자가 현재 쉽게 알아낼 수 없는 것은 무엇입니까.

2. 여러분의 명세가 제삼자에게 노출하는 정보 중 제삼자가 현재 쉽게 알아낼 수 없는 것은 무엇입니까.

3. 여러분의 명세가 일차 당사자에게 노출하는 잠재적으로 식별 가능한 정보 중 일차 당사자가 이미 접근할 수 있는 것은 무엇입니까(즉, 여러분의 명세가 어떤 식별 정보를 복제하거나 반영합니까).

4. 여러분의 명세가 제삼자에게 노출하는 잠재적으로 식별 가능한 정보 중 제삼자가 이미 접근할 수 있는 것은 무엇입니까.

2.2. 여러분의 명세의 기능은 의도한 기능을 구현하는 데 필요한 최소한의 정보만 노출합니까?

기능은 절대적으로 필요한 경우에만 정보를 노출해야 합니다. 기능이 필요한 것보다 더 많은 정보를 노출한다면, 왜 그렇게 하며, 같은 기능을 더 적은 정보 노출로 달성할 수 있습니까?

다음도 참조하십시오

• § 4.1 데이터 최소화

Content Security Policy [CSP]는 하나의 출처가 위반 보고서를 통해 다른 출처에 관한 세부 사항을 추론할 수 있게 함으로써 리디렉션 대상을 의도치 않게 교차 출처로 노출했습니다([HOMAKOV] 참조). 워킹 그룹은 결국 리디렉션 뒤 정책의 세분성을 줄여 위험을 완화했습니다.

2.3. 여러분의 명세의 기능은 개인정보, 개인 식별 정보(PII), 또는 그 둘 중 어느 하나에서 파생된 정보를 노출합니까?

개인정보는 사용자에 관한 모든 데이터 (예: 집 주소), 또는 별칭, 이메일 주소, 식별 번호처럼 사용자를 식별하는 데 사용될 수 있는 정보입니다.

참고: 개인정보는 개인 식별 정보 (PII)와 구별됩니다. PII는 법적 개념이며, 그 정의는 관할권마다 다릅니다. 비법적 맥락에서 사용될 때 PII는 일반적으로 사용자를 식별하는 데 사용될 수 있는 정보를 가리키는 경향이 있습니다.

개인정보, PII, 또는 파생 정보를 노출할 때, 명세 작성자는 사용자에게 발생할 수 있는 잠재적 피해를 방지하거나, 방지가 불가능한 경우 최소화해야 합니다.

인증을 위해 생체 데이터 (지문이나 망막 스캔 등)를 수집하는 기능은 이 생체 데이터를 웹에 직접 노출해서는 안 됩니다. 대신, 생체 데이터를 사용하여 출처 간에 공유되지 않는 임시 키를 조회하거나 생성하고, 그 키를 출처에 안전하게 노출할 수 있습니다. [WEBAUTHN]

개인정보, PII, 또는 그 파생물은 의미 있는 사용자 동의 없이 출처에 노출되어서는 안 됩니다. 많은 API는 의미 있는 사용자 동의를 얻기 위해 Permissions API를 사용합니다. [PERMISSIONS]

웹 플랫폼에 추가되는 각 권한 프롬프트는 사용자가 모든 권한 프롬프트의 내용을 무시할 위험을 증가시킨다는 점을 유념하십시오. 권한 프롬프트를 추가하기 전에, 의미 있는 사용자 동의를 얻기 위해 덜 방해적인 방법을 사용할 수 있는 선택지를 고려하십시오. [ADDING-PERMISSION]

<input type=file>은 개인정보를 포함하는 문서를 웹사이트에 업로드하는 데 사용될 수 있습니다. 이는 기본 네이티브 플랫폼의 파일 선택기를 사용하여 별도의 권한 프롬프트 없이도 파일과 그 내용이 웹사이트에 노출된다는 점을 사용자가 이해하도록 합니다.

다음도 참조하십시오

• § 4.3 명시적 사용자 중재

• Web Platform Design Principles § consent

2.4. 여러분의 명세의 기능은 민감한 정보를 어떻게 처리합니까?

개인정보만이 민감한 정보의 유일한 종류는 아닙니다. 많은 다른 종류의 정보도 민감할 수 있습니다. 무엇이 민감한 정보인지 또는 아닌지는 사람마다, 장소마다 다를 수 있습니다. 어떤 사람이나 집단에 대해 알려져도 해롭지 않을 정보가 다른 사람이나 집단에 대해 알려지면 위험할 수 있습니다. 한 국가에서는 해롭지 않을 사람에 관한 정보가 다른 국가에서는 그 사람을 구금, 납치 또는 투옥하는 데 사용될 수 있습니다.

민감한 정보의 예에는 다음이 포함됩니다: 카스트, 시민권, 피부색, 자격 증명, 범죄 기록, 인구통계 정보, 장애 상태, 고용 상태, 민족성, 금융 정보, 건강 정보, 위치 데이터, 혼인 상태, 정치적 신념, 직업, 인종, 종교적 신념 또는 무신앙, 성적 선호, 그리고 트랜스 상태.

기능이 민감한 정보를 웹에 노출할 때, 그 설계자는 정보 노출 위험을 완화하기 위한 조치를 취해야 합니다.

위치 정보가 필요한 많은 사용 사례는 매우 대략적인 위치 데이터만으로도 충분히 제공될 수 있습니다. 예를 들어, 음식점을 추천하는 사이트는 사용자의 정확한 위치를 노출하는 대신 도시 수준의 위치 정보만으로도 사용자에게 충분히 서비스를 제공할 수 있습니다.

다음도 참조하십시오

• Web Platform Design Principles § do-not-expose-use-of-assistive-tech

2.5. 여러분의 명세가 노출하는 데이터는 사용자에게 명확하지 않을 수 있는 관련되지만 구별되는 정보를 담고 있습니까?

사용자가 출처와 데이터를 공유할 수 있게 하는 기능은, 그러한 데이터가 사용자의 인식, 이해 및 동의 없이 내장된, 어쩌면 숨겨진 정보를 포함하지 않도록 해야 합니다.

이미지나 비디오 파일 같은 문서에는 이미지, 비디오 또는 오디오가 언제 어디에서 캡처되었는지, 그리고 어떤 종류의 장치가 데이터를 캡처하거나 생성했는지에 관한 메타데이터가 들어 있는 경우가 많습니다. 업로드될 때, 이런 종류의 메타데이터는 사용자가 드러내려 하지 않은 정보, 예를 들어 사용자의 현재 또는 과거 위치와 사회경제적 상태를 출처에 드러낼 수 있습니다.

사용자 에이전트는 사용자가 이러한 데이터를 사이트와 공유할지 여부를 선택할 수 있게 해야 하며, 기본값은 그러한 데이터가 공유되지 않는 것이어야 합니다.

2.6. 여러분의 명세의 기능은 브라우징 세션 간에 지속되는 상태를 도입합니까?

웹 플랫폼에는 이미 출처가 정보를 저장하는 데 사용할 수 있는 많은 메커니즘이 포함되어 있습니다. 쿠키, ETag, Last Modified, localStorage, 그리고 indexedDB는 몇 가지 예에 불과합니다.

웹사이트가 브라우징 세션 간에 지속되는 방식으로 사용자의 장치에 데이터를 저장하도록 허용하면, 이 상태가 사용자의 인식이나 통제 없이 일차 또는 제삼자 맥락에서 사용자를 추적하는 데 사용될 수 있는 위험이 도입됩니다.

사용자 에이전트가 출처가 클라이언트 측 저장 메커니즘을 악용하지 못하도록 방지하는 한 가지 방법은, 출처가 저장한 데이터를 사용자가 지울 수 있는 기능을 제공하는 것입니다. 명세 작성자는 새로운 클라이언트 측 저장 메커니즘이 사용자의 통제 없이 도메인 간 사용자를 추적하는 데 오용될 수 없도록 하기 위해 유사한 보호 조치를 포함해야 합니다. 그러나 사용자에게 출처가 설정한 상태를 삭제할 수 있는 기능만 제공하는 것은 보통 충분하지 않습니다. 사용자는 브라우저 상태를 수동으로 지우는 일이 드물기 때문입니다. 명세 작성자는 전체 저장소 삭제 없이도 새로운 기능을 더 개인정보 보호 친화적으로 만드는 방법, 예를 들어 값의 고유성을 줄이거나, 값을 회전하거나, 기능이 필요한 것 이상으로 식별적이지 않게 만드는 방법을 고려해야 합니다.

또한 명세 작성자는 가능한 경우 자신의 기능이 브라우저 캐싱 기능과 어떻게 상호작용해야 하는지 신중하게 고려하고 명시해야 합니다. 출처가 캐시를 악용하여 사용자 동의 없이 사이트나 세션 간에 사용자를 식별하고 추적하는 것을 방지하기 위해 추가 완화 조치가 필요할 수 있습니다.

플랫폼별 DRM 구현 ([ENCRYPTED-MEDIA]의 콘텐츠 복호화 모듈 등)은 사용자를 식별하고 특정 미디어 조각에 대한 접근 권한을 부여받아야 하는지 판단하는 데 도움을 주기 위해 출처별 정보를 노출할 수 있습니다. 이러한 종류의 식별자는 남용을 어떻게 완화할 수 있는지 판단하기 위해 신중하게 평가되어야 합니다; 사용자가 쉽게 변경할 수 없는 식별자는 추적 관점에서 매우 가치가 있으며, 그러한 식별자를 능동적 네트워크 공격자로부터 보호하는 것은 필수적입니다.

2.7. 여러분의 명세의 기능은 기본 플랫폼에 관한 정보를 출처에 노출합니까?

(기본 플랫폼 정보에는 사용자 구성 데이터, 센서 같은 하드웨어 I/O 장치의 존재와 속성, 그리고 다양한 소프트웨어 기능의 가용성과 동작이 포함됩니다.)

그렇다면, 같은 정보가 출처 전반에 노출됩니까? 서로 다른 출처가 서로 다른 데이터를 보거나 같은 데이터를 봅니까? 데이터는 자주 변경됩니까, 드물게 변경됩니까? 여러 출처에 노출되는 드물게 변경되는 데이터는 그 출처들 사이에서 사용자를 고유하게 식별하는 데 사용될 수 있습니다. 이는 직접적일 수 있고 (정보 조각이 고유할 때) 간접적일 수도 있습니다 (그 데이터가 다른 데이터와 결합되어 지문을 형성할 수 있기 때문입니다). [FINGERPRINTING-GUIDANCE]

그러한 정보를 노출할지 여부를 고려할 때, 명세와 사용자 에이전트는 정보를 고립적으로 고려하지 말고, 그것을 플랫폼의 기존 지문 채취 표면에 추가하는 위험을 평가해야 합니다.

특정 정보 조각의 지문 채취 위험은 플랫폼마다 달라질 수 있음을 유념하십시오. 여러분이 사용하는 하드웨어 및 소프트웨어 플랫폼에서 일부 데이터의 지문 채취 위험은 다른 플랫폼에서의 지문 채취 위험과 다를 수 있습니다.

그러한 정보를 노출하기로 결정한 경우, 그러한 노출의 피해를 완화하기 위한 조치를 취해야 합니다.

때로는 애초에 데이터를 노출하지 않는 것이 올바른 답입니다(§ 4.6 기능 삭제 참조). 다른 경우에는, 지문 채취 가능성을 줄이는 것이 예를 들어 사용 가능한 리소스 목록의 순서를 정해 일관성을 보장하는 것처럼 간단할 수 있지만, 때로는 더 복잡한 완화 조치가 필요할 수 있습니다. 자세한 내용은 § 4 완화 전략을 참조하십시오.

여러분의 명세의 기능이 그러한 데이터를 노출하고 적절한 완화 조치를 정의하지 않는다면, 그러한 정보가 의미 있는 사용자 동의 없이 출처에 드러나지 않도록 해야 하며, 이를 명세의 보안 및 개인정보 보호 고려사항 절에 명확히 설명해야 합니다.

WebGL의 RENDERER 문자열은 일부 애플리케이션이 성능을 개선할 수 있게 합니다. 이는 또한 가치 있는 지문 채취 데이터입니다. 이러한 데이터를 출처에 노출하는 것을 고려할 때 이 개인정보 보호 위험을 신중히 저울질해야 합니다.

PDF 뷰어 플러그인 객체 목록은 거의 변하지 않습니다. 일부 사용자 에이전트는 이 인터페이스의 지문 채취 피해를 줄이기 위해 플러그인 목록의 직접 열거를 비활성화했습니다.

다음도 참조하십시오:

• 장치에 관한 식별 정보를 노출할 때 주의하기

• 장치를 선택하거나 열거하는 API를 노출할 때 주의하기

2.8. 이 명세는 출처가 기본 플랫폼에 데이터를 보낼 수 있게 합니까?

그렇다면, 어떤 종류의 데이터를 보낼 수 있습니까?

플랫폼은 전달된 데이터를 처리하는 방식이 서로 다르며, 이는 사용자에게 서로 다른 위험을 제기할 수 있습니다.

기본 플랫폼이 전달된 데이터를 안전하게 처리할 것이라고 가정하지 마십시오. 가능한 경우, 플랫폼에 전달되는 데이터의 종류를 제한하거나 구조화하여 공격을 완화하십시오.

2.9. 이 명세의 기능은 장치 센서에 대한 접근을 가능하게 합니까?

그렇다면, 센서에서 나오거나 센서에 관한 어떤 종류의 정보가 출처에 노출됩니까?

센서에서 나온 정보는 출처 간 지문 채취 벡터로 작용할 수 있습니다. 또한, 센서는 장치나 그 환경에 관한 민감한 무언가를 드러낼 수 있습니다.

센서 데이터가 비교적 안정적이고 출처 전반에 걸쳐 일관적이라면, 교차 출처 식별자로 사용될 수 있습니다. 두 사용자 에이전트가 같은 센서에서 나온 이러한 안정적 데이터를 노출한다면, 그 데이터는 교차 브라우저, 또는 잠재적으로 교차 장치 식별자로도 사용될 수 있습니다.

연구자들은 충분히 세밀한 자이로스코프를 마이크처럼 사용하는 것이 가능하다는 사실을 발견했습니다 [GYROSPEECHRECOGNITION]. 이는 자이로스코프의 샘플링 속도를 낮추어 완화할 수 있습니다.

주변광 센서는 공격자가 사용자가 특정 링크를 방문했는지 여부를 알아낼 수 있게 할 수 있습니다 [OLEJNIK-ALS].

배터리 상태처럼 비교적 짧은 수명의 데이터조차 식별자로 작용할 수 있습니다 [OLEJNIK-BATTERY].

2.10. 이 명세의 기능은 새로운 스크립트 실행/로드 메커니즘을 가능하게 합니까?

스크립트를 실행하거나 로드하는 새로운 메커니즘은 새로운 공격 표면을 가능하게 할 위험이 있습니다. 일반적으로 새 기능에 이것이 필요하다면 더 넓은 청중과 상의해야 하며, 기존 메커니즘을 사용할 수 있는지 또는 그 기능이 정말 필요한지 생각해야 합니다.

JSON modules는 데이터로만 취급될 것으로 예상되지만, 초기 제안은 공격자가 사용자가 모르는 사이에 이를 코드로 바꿔치기할 수 있게 했습니다. Import assertions가 이 취약점의 완화책으로 구현되었습니다.

2.11. 이 명세의 기능은 출처가 다른 장치에 접근할 수 있게 합니까?

그렇다면, 이 명세의 기능은 출처가 어떤 장치에 접근할 수 있게 합니까?

네트워크 연결을 통해서든 사용자의 기기에 대한 직접 연결(예: Bluetooth, NFC, 또는 USB)을 통해서든 다른 장치에 접근하는 것은 취약점을 노출할 수 있습니다. 이러한 장치 중 일부는 웹 연결을 염두에 두고 만들어지지 않았으며, 악의적 입력이나 웹에서의 사용에 대해 충분히 강화되어 있지 않을 수 있습니다.

사용자의 로컬 네트워크에 있는 다른 장치를 노출하는 것 또한 상당한 개인정보 보호 위험을 가집니다:

• 두 사용자 에이전트가 로컬 네트워크에 같은 장치를 가지고 있다면, 공격자는 두 사용자 에이전트가 같은 호스트에서 실행 중이거나 같은 물리적 위치에 있는 두 별도 사용자가 사용하고 있다고 추론할 수 있습니다.

• 사용자의 로컬 네트워크에 있는 장치를 열거하는 것은 공격자가 사용자 에이전트를 지문 채취하는 데 사용할 수 있는 상당한 엔트로피를 제공합니다.

• 이 명세의 기능이 로컬 네트워크 장치의 영구적 또는 장수명 식별자를 노출한다면, 사용자가 그러한 추적을 방지하기 위한 조치(예: 쿠키 및 기타 상태 기반 추적 메커니즘 삭제)를 취하더라도 공격자에게 시간이 지나도 사용자를 추적할 수 있는 방법을 제공합니다.

• 직접 연결은 다른 API가 제공하는 보안 검사를 우회하는 데에도 사용될 수 있습니다. 예를 들어, 공격자들은 WebUSB API를 사용해 초기 U2F API의 동일 출처 검사를 우회하여 하드웨어 보안 키에 있는 다른 사이트의 자격 증명에 접근했습니다. [YUBIKEY-ATTACK]

Network Service Discovery API [DISCOVERY-API]는 장치에 대한 접근을 허용하기 전에 CORS 프리플라이트를 권장했으며, 사용자 에이전트가 어떤 형태의 권한 요청으로 사용자를 관여시킬 것을 요구합니다.

마찬가지로, Web Bluetooth [WEB-BLUETOOTH]는 Web Bluetooth § 3 개인정보 보호 고려사항에서 그러한 문제에 대한 광범위한 논의를 담고 있으며, 이는 유사한 작업의 예로 읽어볼 가치가 있습니다.

[WEBUSB]는 사용자 중재 / 프롬프트, 보안 출처, 그리고 기능 정책의 조합을 통해 이러한 위험을 다룹니다. 자세한 내용은 WebUSB API § 3 보안 및 개인정보 보호 고려사항을 참조하십시오.

2.12. 이 명세의 기능은 출처가 사용자 에이전트의 네이티브 UI에 대해 어느 정도 제어할 수 있게 합니까?

사용자 에이전트의 UI를 제어할 수 있게 하는 기능(예: 전체 화면 모드) 또는 기본 시스템을 변경하는 기능(예: 스마트폰 홈 화면에 ‘앱’을 설치)은 사용자를 놀라게 하거나 보안 / 개인정보 보호 제어를 가릴 수 있습니다. 여러분의 기능이 사용자 에이전트의 UI 변경을 허용한다면, 그것이 보안 / 개인정보 보호 제어에 영향을 줄 수 있습니까? 어떤 분석이 이 결론을 확인했습니까?

2.13. 이 명세의 기능은 어떤 임시 식별자를 생성하거나 웹에 노출합니까?

표준이 임시 식별자를 웹에 노출한다면, 그 식별자는 단명해야 하며 시간이 지남에 따라 사용자를 추적하는 데 사용될 위험을 완화하기 위해 일정한 주기로 회전해야 합니다. 사용자가 사용자 에이전트에서 상태를 지울 때, 이러한 임시 식별자도 지워져야 하며, 임시 식별자를 사용한 상태의 재상관을 방지해야 합니다.

이 명세의 기능이 임시 식별자를 생성하거나 웹에 노출한다면, 그것들은 어떻게, 언제, 어떤 엔티티에 노출되며, 얼마나 자주 회전됩니까?

임시 식별자의 예에는 TLS Channel ID, Session Tickets, 그리고 IPv6 주소가 포함됩니다.

Gamepad API [GAMEPAD]의 index 속성 — 0에서 시작하여 증가하고, 재설정되는 정수 — 는 개인정보 보호 친화적인 임시 식별자의 좋은 예입니다.

2.14. 이 명세는 일차 당사자와 제삼자 맥락에서의 동작을 어떻게 구별합니까?

기능의 동작은 사용자가 방문 중인 일차 당사자 출처에서 사용되는 맥락뿐만 아니라, 일차 당사자가 포함하는 임의의 제삼자가 사용하는 것의 영향도 고려되어야 합니다. 명세를 개발할 때, 페이지의 제삼자 리소스가 그것을 사용하는 영향과, 제삼자 리소스의 사용 지원을 명세 준수를 위한 선택 사항으로 해야 하는지 고려하십시오. 제삼자 리소스의 사용 지원이 적합성에 필수라면, 그 이유와 어떤 개인정보 보호 완화 조치가 마련되어 있는지 설명해 주십시오. 이는 제삼자가 기능을 남용하는 것으로 확인될 경우 사용자 에이전트가 특정 기능의 제삼자에 대한 가용성이나 기능성을 줄이는 조치를 취할 수 있으므로 특히 중요합니다.

2.15. 이 명세의 기능은 브라우저의 사생활 보호 브라우징 또는 시크릿 모드 맥락에서 어떻게 동작합니까?

대부분의 브라우저는 사생활 보호 브라우징 또는 시크릿 모드를 구현하지만, 제공하는 기능과 그 보호가 사용자에게 설명되는 방식은 크게 다릅니다 [WU-PRIVATE-BROWSING].

한 가지 공통점은 브라우저의 '일반' 상태와는 다른 상태 집합을 제공한다는 것입니다.

이 명세의 기능은 단일 사용자의 일반 모드와 사생활 보호 브라우징 / 시크릿 모드 간 활동을 상관시킬 수 있는 정보를 제공합니까? 명세의 기능은 사생활 보호 브라우징 / 시크릿 모드 세션이 끝난 뒤에도 지속될 정보를 사용자의 호스트에 기록하게 합니까?

두 가지에 대한 연구가 있었습니다:

• window.requestFileSystem() 같은 비표준화 방법을 사용하여 사용자 에이전트가 사생활 보호 브라우징 모드인지 감지하기 [RIVERA].

• 기능을 사용해 브라우저를 지문 채취하고 주어진 사용자의 사생활 보호 모드와 비사생활 보호 모드 세션을 상관시키기. [OLEJNIK-PAYMENTS]

명세 작성자는 가능한 한, 사이트가 사생활 보호 브라우징 모드의 존재를 감지할 수 있게 하지 않아야 합니다. Web Platform Design Principles § do-not-expose-use-of-private-browsing-mode

2.16. 이 명세에는 "보안 고려사항"과 "개인정보 보호 고려사항" 절이 모두 있습니까?

명세에는 구현자와 웹 개발자가 기능이 제시하는 위험을 이해하고 적절한 완화 조치가 마련되도록 하기 위해 "보안 고려사항"과 "개인정보 보호 고려사항" 절이 모두 있어야 합니다. 이 문서의 질문에 대한 답변은 그러한 절을 작성하는 데 도움이 되겠지만, 이 설문지를 그 절들에 그대로 복사하지 마십시오. 대신, 구현자와 웹 개발자에게 도움이 될 여러분의 명세에 특화된 문구를 작성하십시오.

[RFC6973]는 명세의 개인정보 보호 영향을 고려할 때 참조하기에 훌륭한 리소스이며, 특히 RFC6973의 7절이 그렇습니다. [RFC3552]는 보안 고려사항 절 작성에 대한 일반적인 조언을 제공하며, RFC3552의 5절에는 구체적인 요구사항이 있습니다.

일반적으로 이러한 절에는 여러분의 명세가 도입하는 기능의 개인정보 보호 및 보안 위험에 대한 명확한 설명이 포함되어야 합니다. 또한 명세의 다른 곳에서 완화된 위험을 문서화하고, 명세와 다르게 구현될 경우 취약점으로 이어질 가능성이 높은 세부 사항을 지적하는 것도 적절합니다.

여러분의 명세의 어떤 기능도 보안 또는 개인정보 보호 영향이 없어 보인다면, 예를 들어 다음과 같이 문서 안에 명시하십시오:

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

다만 대부분의 명세에는 브라우저의 지문 채취 표면에 적어도 어느 정도 영향을 미치는 기능이 포함된다는 점에 유의하십시오. 여러분의 명세가 예외라고 믿는다면, 그 주장을 정당화하는 것이 필요합니다.

2.17. 여러분의 명세의 기능은 출처가 기본 보안 보호를 낮출 수 있게 합니까?

여러분의 명세의 기능은 출처가 무언가를 달성하기 위해 보안 설정을 옵트아웃할 수 있게 합니까? 그렇다면, 이 기능들은 어떤 상황에서 그러한 하향 조정을 허용하며, 왜 그렇습니까?

이를 애초에 피할 수 있습니까? 그렇지 않다면, 이 하향 조정이 사용자 위험을 크게 증가시키지 않도록 완화 조치가 마련되어 있습니까? 예를 들어, [PERMISSIONS-POLICY]는 사이트가 신뢰할 수 없는 iframe이 그러한 기능을 사용하지 못하도록 하는 데 사용할 수 있는 메커니즘을 정의합니다.

2.18. 여러분의 기능을 사용하는 문서가 탐색 후 (파괴되는 대신) BFCache에서 살아 있게 유지되고, 향후 해당 문서로 돌아가는 탐색에서 잠재적으로 재사용될 때 무슨 일이 일어납니까?

사용자가 문서에서 다른 곳으로 탐색한 뒤, 문서는 비-"완전히 활성" 상태로 남아 "back/forward cache (BFCache)"에 보관될 수 있으며, 사용자가 해당 문서로 되돌아갈 때 재사용될 수 있습니다. 사용자의 관점에서, 비-완전히 활성 문서는 이미 폐기된 것이며, 따라서 사용자가 그 문서에서 떠난 뒤 발생하는 업데이트/이벤트, 특히 개인정보에 민감한 정보(예: 위치 정보)를 받아서는 안 됩니다.

또한 문서가 탐색 후에도 재사용될 수 있으므로, 어떤 것을 문서의 수명에 묶는다는 것은 탐색 후에도 그것을 재사용한다는 뜻이기도 함을 유의하십시오. 이것이 바람직하지 않다면, 완전히 활성 상태의 변경을 감지하고 필요에 따라 정리하는 것을 고려하십시오.

BFCached 문서를 처리하는 방법에 대한 더 자세한 지침은, Web Platform Design Principles § support-non-fully-active와 Supporting BFCached Documents 가이드를 참조하십시오.

참고: 문서는 BFcaching과 관련 없는 다른 이유로도 비-완전히 활성 상태가 될 수 있습니다. 예를 들어 문서를 담고 있는 iframe이 연결 해제될 때 그렇습니다. 우리의 조언은 모든 비-완전히 활성 문서를 같은 방식으로 처리해야 한다는 것입니다. 유일한 차이는 BFCached 문서는 다시 완전히 활성 상태가 될 수 있지만, 분리된 iframe의 문서는 영원히 비활성 상태로 남는다는 것입니다. 따라서 BFCache 사례에 특별히 주의를 기울일 것을 제안합니다.

2.19. 여러분의 기능을 사용하는 문서의 연결이 끊어지면 무슨 일이 일어납니까?

2.20. 여러분의 명세는 새로운 종류의 오류가 언제 어떻게 발생해야 하는지 정의합니까?

오류 처리, 그리고 어떤 조건이 오류 상태를 구성하는지는 의도치 않은 정보 누출과 개인정보 보호 취약점의 원천이 될 수 있습니다. 오류를 트리거하는 것, 오류에 어떤 정보가 포함되는지(또는 오류를 통해 배울 수 있는지), 그리고 애플리케이션의 어떤 당사자가 오류에 대해 알 수 있는지는 모두 사용자 개인정보 보호에 영향을 주거나(또는 약화시킬) 수 있습니다. 제안 작성자는 오류 처리를 통해 사용자 개인정보 보호와 보안이 해를 입지 않도록 보장하기 위해 이러한 각 차원을 신중히 생각해야 합니다.

오류 정의와 오류 처리가 사용자를 위험에 빠뜨릴 수 있는 방식의 일부 목록은 다음과 같습니다:

• 여러분의 명세가 특정 시스템 리소스가 사용 가능한지 여부에 근거한 오류 상태를 정의한다면, 애플리케이션은 그 오류 상태를 탐침으로 사용하여 그러한 시스템 리소스의 가용성에 대해 배울 수 있습니다. 이는 사용자 에이전트가 애플리케이션이 그러한 시스템 리소스에 대해 알게 하려 하지 않을 때 사용자 개인정보 보호에 해를 끼칠 수 있습니다.

• 명세는 종종 작성자가 애플리케이션의 문제를 식별하고 디버그하는 데 도움을 주기 위한 정보를 오류 객체에 포함합니다. 명세 작성자는 그러한 디버깅 정보가 어떤 정보를 노출하는지, 그리고 페이지의 어떤 행위자가 그 정보에 접근할 수 있는지(그리고 접근 가능한지)를 신중히 생각해야 합니다.

2.21. 여러분의 기능은 사이트가 사용자의 보조 기술 사용 여부를 알 수 있게 합니까?

명세 작성자는 보조 기술에 의존하는 웹 사용자가 웹을 사용할 때 고유한 위험에 직면한다는 점을 유념해야 합니다. 보조 기술의 사용은 그러한 웹 사용자가 다른 웹 사용자들 사이에서 두드러지게 만들 수 있으며, 원치 않는 재식별과 개인정보 보호 피해의 위험을 증가시킵니다. 마찬가지로 일부 웹사이트 운영자는 보조 기술에 의존하는 웹 사용자를 차별하려고 할 수 있습니다.

따라서 기능 설계자와 명세 작성자는 웹사이트가 보조 기술 사용에 대해 무엇을, 그리고 어느 정도까지 알 수 있는지를 제한하도록 신중하고 세심해야 합니다. 명세 작성자는 자신의 기능이 보조 기술 사용에 대해 드러내는 명시적 및 암시적 정보를 최소화해야 합니다. 보조 기술에 관한 명시적 정보의 예에는 장치 식별자나 모델명이 포함됩니다. 보조 기술 사용에 관한 암시적 정보의 예에는 마우스, 키보드 또는 터치 스크린으로는 생성되기 어려운 사용자 상호작용 패턴이 포함될 수 있습니다.

[wai-aria-1.3]은 작성자가 보조 기술로 페이지를 더 쉽게 탐색할 수 있게 하기 위해 사용할 수 있는 추가 마크업을 정의합니다. 이 명세에는 사이트 작성자가 특정 콘텐츠가 보조 기술로부터 숨겨져야 함을 나타내는 데 사용할 수 있는 aria-hidden 속성이 포함되어 있습니다.

악의적인 사이트 작성자는 사용자가 보조 기술을 사용하고 있는지 알아내기 위해 aria-hidden 속성을 남용할 수 있습니다. 예를 들어 특정 페이지 콘텐츠는 보조 기술에 드러내면서, 다른 사용자에게는 매우 다른 페이지 콘텐츠를 보여줄 수 있습니다. 그러면 악의적인 사이트 작성자는 사용자가 어떤 콘텐츠와 상호작용했는지, 따라서 보조 기술이 사용되고 있었는지 여부를 사용자의 행동에서 추론할 수 있습니다.

2.22. 이 설문지는 무엇을 물었어야 했습니까?

이 설문지는 모든 것을 망라하지 않습니다. 개인정보 보호 검토를 완료한 뒤, 이 설문지를 엄격히 읽고 응답하는 것만으로는 드러나지 않았을 여러분의 명세의 개인정보 보호 측면이 있을 수 있습니다. 그런 경우라면, 그러한 개인정보 보호 우려를 전달하고, 이 측면을 다루었을 개선된 질문이나 새로운 질문을 생각해낼 수 있는지 알려 주십시오.

설문지가 무엇을 물었어야 했는지 알려 주기 위해 이슈를 등록하는 것을 고려해 주십시오.

3. 위협 모델

보안과 개인정보 보호를 고려할 때, 가능한 위험을 밝혀내는 방법인 위협 모델의 관점에서 생각하는 것이 편리합니다.

웹 플랫폼 기능을 개발할 때 고려해야 할 몇 가지 구체적인 개인정보 보호 우려가 있습니다 [RFC6973]:

• 감시: 감시는 개인의 통신이나 활동을 관찰하거나 모니터링하는 것입니다.

• 저장 데이터 침해: 무단 또는 부적절한 접근으로부터 저장 데이터를 보호하기 위한 적절한 조치를 취하지 않는 최종 시스템.

• 침입: 침입은 한 사람의 삶이나 활동을 방해하거나 중단시키는 침해적 행위로 구성됩니다.

• 오귀속: 오귀속은 한 개인과 관련된 데이터나 통신이 다른 개인에게 귀속될 때 발생합니다.

• 상관: 상관은 한 개인과 관련되거나 결합될 때 그 특성을 얻게 되는 다양한 정보 조각의 결합입니다.

• 식별: 식별은 정보를 특정 개인과 연결하여 개인의 신원을 추론하거나 개인의 신원 추론을 가능하게 하는 것입니다.

• 2차 사용: 2차 사용은 개인에 대해 수집된 정보를 그 정보가 수집된 목적과 다른 목적을 위해 개인의 동의 없이 사용하는 것입니다.

• 공개: 공개는 다른 사람들이 그 개인을 판단하는 방식에 영향을 미치는 개인에 관한 정보의 폭로입니다.

• 배제: 배제는 개인이 다른 사람들이 자신에 대해 가지고 있는 데이터를 알 수 있게 하고 그 처리와 사용에 참여할 수 있게 하지 못하는 것입니다.

완화 조치 절에서, 이 문서는 이러한 위험을 완화하기 위해 적용할 수 있는 여러 기술을 개괄합니다.

아래에는 웹 기능을 개발할 때 고려해야 할 몇 가지 넓은 종류의 위협이 열거되어 있습니다.

3.1. 수동적 네트워크 공격자

수동적 네트워크 공격자는 사용자와 그들이 통신하는 서버 사이의 선을 지나가는 비트에 대한 읽기 접근 권한을 가집니다. 그녀는 바이트를 수정할 수는 없지만, 그것들을 수집하고 분석할 수 있습니다.

인터넷의 분산된 특성과 사용자 활동에 대한 일반적인 관심 수준 때문에, 여러분이 지금 사용하고 있는 프록시, 라우터, 서버의 네트워크를 돌아다니는 거의 모든 암호화되지 않은 비트는 누군가가 읽고 있다고 가정하는 것이 합리적입니다. 이러한 공격자 중 일부가 암호화된 비트도 이해하려고 최선을 다하고 있을 가능성도 마찬가지로 높으며, 여기에는 나중의 암호해석을 위해 암호화된 통신을 저장하는 것도 포함됩니다 (다만 이는 훨씬 더 많은 노력이 필요합니다).

• IETF의 "Pervasive Monitoring Is an Attack" 문서 [RFC7258]는 이 가정이 개인정보 보호에 미치는 영향을 개괄하는 유용한 읽을거리입니다.

• 정부만이 유일한 우려는 아닙니다; 여러분의 동네 커피숍도 고객에 관한 정보를 수집하고 있을 가능성이 높고, 집의 ISP도 같은 일을 하고 있을 가능성이 높습니다.

3.2. 능동적 네트워크 공격자

능동적 네트워크 공격자는 사용자와 그들이 통신하는 서버 사이의 선을 지나가는 비트에 대해 읽기 및 쓰기 접근 권한을 모두 가집니다. 그녀는 데이터를 수집하고 분석할 수 있을 뿐만 아니라 전송 중인 데이터를 수정하여, Javascript, HTML 및 기타 콘텐츠를 마음대로 주입하고 조작할 수 있습니다. 이는 여러분이 생각하는 것보다 더 흔하며, 선의의 목적과 악의적 목적 모두에서 그렇습니다:

• ISP와 캐싱 프록시는 데이터 사용량을 줄이기 위한 노력의 일환으로 사용자에게 전달하기 전에 이미지를 정기적으로 캐시하고 압축합니다. 이는 휴대전화처럼 낮은 대역폭, 높은 지연 시간 장치를 사용하는 사용자에게 특히 유용할 수 있습니다.

• ISP는 덜 선의적인 목적을 위해 정기적으로 JavaScript [COMCAST]와 기타 식별자 [VERIZON]를 주입하기도 합니다.

• 여러분의 ISP가 이익을 위해 자신을 통과하는 상당량의 트래픽을 기꺼이 수정한다면, 국가 수준의 공격자가 수동적으로만 남아 있을 것이라고 믿기는 어렵습니다.

3.3. 동일 출처 정책 위반

동일 출처 정책은 웹 보안의 초석입니다; 한 출처는 다른 출처의 데이터에 직접 접근해서는 안 됩니다(이 정책은 [RFC6454]의 3절에서 더 형식적으로 정의됩니다). 이 정책의 귀결은 출처와 관련되지 않은 데이터, 예를 들어 사용자의 하드 드라이브 내용에는 어떤 출처도 직접 접근해서는 안 된다는 것입니다. 여러 종류의 공격은 이런 보호를 어떤 방식으로든 우회합니다. 예를 들어:

• 교차 사이트 스크립팅 공격은 공격자가 대상 출처의 맥락에서 공격자가 제어하는 코드를 실행하도록 출처를 속이는 것을 포함합니다.

• 교차 사이트 요청 위조 공격은 사용자 에이전트가 사용자를 대신하여 요청을 제출하게 함으로써, 사용자가 로그인한 사이트에서 사용자의 주변 권한을 행사하도록 속입니다.

• 데이터 누출은 정보 조각이 CORS 헤더 [CORS]를 통해 명시적으로, 또는 [TIMING] 같은 부채널 공격을 통해 암시적으로, 교차 출처에서 이용 가능하게 될 때 발생합니다.

3.4. 제삼자 추적

웹의 힘 중 하나는 페이지가 이미지부터 javascript까지 다른 제삼자의 콘텐츠를 가져와 사이트의 콘텐츠 및/또는 사용자 경험을 향상할 수 있다는 점입니다. 그러나 페이지가 제삼자의 콘텐츠를 가져오면, 본질적으로 일부 정보가 제삼자에게 누출됩니다 — referer 정보와 사용자를 추적하고 프로파일링하는 데 사용될 수 있는 기타 정보입니다. 여기에는 쿠키가 처음 저장한 도메인으로 다시 전송되어 교차 출처 추적을 가능하게 한다는 사실이 포함됩니다. 또한 제삼자는 웹페이지에 포함된 제삼자 Javascript를 통해 실행 권한을 얻을 수 있습니다. 페이지가 제삼자 콘텐츠의 위험을 완화하기 위한 조치를 취할 수 있고 브라우저가 주어진 페이지에서 일차 당사자와 제삼자 콘텐츠를 다르게 처리할 수 있지만, 새로운 기능이 일차 당사자 사이트가 아니라 제삼자에 의해 실행될 위험은 기능 개발 과정에서 고려되어야 합니다.

가장 단순한 예는 특정 조건, 예를 들어 사용자가 사이트에 로그인했는지 여부에 따라 다르게 동작하는 사이트로의 링크를 주입하는 것입니다. 이는 사용자가 해당 사이트에 계정을 가지고 있음을 드러낼 수 있습니다.

3.5. 합법적 오용

강력한 기능이 개발자에게 제공된다고 해서 모든 사용이 항상 좋은 생각이거나 정당화된다는 뜻은 아닙니다; 실제로 전 세계의 데이터 개인정보 보호 규정은 특정 데이터 사용에 제한을 둘 수도 있습니다. 일차 당사자의 맥락에서, 합법적인 웹사이트는 강력한 기능과 상호작용하여 사용자 행동이나 습관에 대해 알 수 있을 가능성이 있습니다. 예를 들어:

• 마우스 이동 추적 같은 메커니즘을 통해 웹사이트를 탐색하는 동안 사용자를 추적하기

• 사용 패턴에 기반한 사용자의 행동 프로파일링

• 웹캠이나 센서를 통해 가능한 것처럼 일차 당사자가 사용자의 시스템, 사용자 자신 또는 사용자의 주변 환경에 대해 알 수 있게 하는 강력한 기능에 접근하기

이 지점은 다른 것들과는 다르다는 점을 인정할 수밖에 없습니다 - 그리고 어떤 것이 가능하다고 해서 항상 수행되어야 한다는 뜻은 아니며, 개인정보 영향 평가나 윤리적 평가까지 고려해야 한다는 점을 강조합니다. 보안과 개인정보 보호를 염두에 두고 기능을 설계할 때, 사용 사례와 오용 사례가 모두 범위에 포함되어야 합니다.

4. 완화 전략

여러분의 명세에서 식별한 보안 및 개인정보 보호 위험을 완화하기 위해, 아래에 설명된 완화 조치 중 하나 이상을 적용하고 싶을 수 있습니다.

4.1. 데이터 최소화

최소화는 주어진 작업을 완료하는 데 필요한 만큼만 다른 통신 상대에게 정보를 노출하는 전략입니다. 더 구체적으로는, 사용자 중재 접근에서 명백했던 것보다 더 많은 정보에 접근을 제공하지 않거나, 정확히 어떤 정보가 제공되는지에 대해 사용자에게 어느 정도 통제권을 허용하는 것을 요구합니다.

예를 들어 사용자가 특정 파일에 대한 접근을 제공했다면, 그것을 나타내는 객체는 그 파일의 상위 디렉터리와 그 내용에 관한 정보를 얻을 수 있게 해서는 안 됩니다. 그것은 명백히 기대되는 바가 아니기 때문입니다.

데이터 최소화의 맥락에서는 서로 다른 당사자 사이에 어떤 데이터가 전달되는지, 데이터 항목과 식별자가 얼마나 지속적인지, 그리고 서로 다른 프로토콜 실행 사이에 상관 가능성이 있는지 묻는 것이 자연스럽습니다.

예를 들어, W3C Device APIs Working Group은 Privacy Requirements 문서에서 여러 요구사항을 정의했습니다. [DAP-PRIVACY-REQS]

데이터 최소화는 명세 작성자와 구현자뿐만 아니라, 최종 서비스를 배포하는 이들에게도 적용됩니다.

예로 마우스 이벤트를 생각해 보십시오. 페이지가 로드될 때, 애플리케이션은 마우스가 연결되어 있는지, 어떤 종류의 마우스인지 (예: 제조사와 모델), 어떤 기능을 노출하는지, 몇 개가 연결되어 있는지 등을 알 방법이 없습니다. 사용자가 상호작용에 필요하다고 판단해 마우스를 사용하기로 결정할 때에만 이 정보 중 일부가 이용 가능해집니다. 그리고 그때에도 최소한의 정보만 노출됩니다: 예를 들어 그것이 트랙패드인지 알 수 없으며, 오른쪽 버튼이 있을 수 있다는 사실도 사용될 때만 노출됩니다. 예를 들어 Gamepad API는 이러한 데이터 최소화 기능을 활용합니다. 웹 게임은 사용자 에이전트가 게임패드에 접근할 수 있는지, 몇 개가 있는지, 어떤 기능이 있는지 등을 알 수 없습니다. 사용자가 게임패드를 통해 게임과 상호작용하기를 원한다면 언제 그것을 작동시킬지 알고 있을 것이라고 단순히 가정합니다 — 그리고 그것을 작동시키면 애플리케이션이 동작하는 데 필요한 모든 정보(그 이상은 아님)가 제공됩니다.

마우스에 대해 기능이 지원되는 방식은 특정 이벤트가 발생할 때에만 마우스의 동작에 대한 정보를 제공하는 것입니다. 따라서 접근 방식은 이벤트 처리(예: 클릭, 이동, 버튼 누름 시 트리거)를 장치에 대한 유일한 인터페이스로 노출하는 것입니다.

기능이 노출하는 데이터를 최소화한 두 명세는 다음과 같습니다:

• [BATTERY-STATUS] 사용자 에이전트는 고정밀 판독값을 노출해서는 안 됩니다

• [GENERIC-SENSOR] 최대 샘플링 주파수 제한, 정확도 낮추기

4.2. 기본 개인정보 보호 설정

사용자는 기본값을 변경하지 않는 경우가 많습니다. 따라서 명세의 기본 모드가 노출되는 데이터와 식별자의 양, 식별 가능성, 지속성을 최소화하는 것이 중요합니다. 이는 프로토콜이 특정 환경에 맞게 조정될 수 있도록 유연한 옵션을 제공하는 경우 특히 그렇습니다.

4.3. 명시적 사용자 중재

기능의 보안 또는 개인정보 보호 위험을 명세에서 다른 방식으로 완화할 수 없다면, 구현자가 사용자에게 프롬프트를 표시하도록 선택적으로 허용하는 것이 가능한 최선의 완화책일 수 있습니다. 다만 그것이 개인정보 보호 위험을 완전히 제거하지는 않는다는 점을 이해해야 합니다. 명세가 구현자가 프롬프트를 표시하는 것을 허용하지 않는다면, 일부 사용자 에이전트가 더 개인정보 보호 친화적인 버전을 구현하기로 선택하면서 서로 다른 사용자 에이전트의 구현이 갈라질 수 있습니다.

기능 자체에 위험이 내재되어 있기 때문에 그 기능의 위험을 완화할 수 없을 수도 있습니다. 예를 들어, [GEOLOCATION]은 의도적으로 사용자의 위치를 드러냅니다; 사용자 에이전트는 일반적으로 사용자가 수락할지 선택할 수 있는 권한 프롬프트에 따라 이 기능에 대한 접근을 제한합니다. 이 위험은 개인 데이터나 식별자를 노출하는 기능에도 존재하며 고려되어야 합니다.

그러한 프롬프트를 설계하는 것은 어렵고, 권한이 제공되어야 하는 기간을 결정하는 것도 어렵습니다.

종종 최선의 프롬프트는 사용자 동작에 명확히 연결된 것입니다. 예를 들어 파일 선택기처럼, 사용자 동작에 응답하여 파일 선택기가 열리고 사용자가 개별 사이트에 특정 파일에 대한 접근 권한을 부여하는 경우입니다.

일반적으로 말해, 프롬프트의 기간과 시점은 노출되는 데이터가 제기하는 위험과 반비례해야 합니다. 또한 프롬프트는 다음과 같은 문제를 고려해야 합니다:

• 권한 요청은 어떻게 범위가 지정되어야 합니까? 특히 임베드된 제삼자 iframe이 요청하는 경우에는 어떻게 해야 합니까?

• 지속성은 최상위/임베드된 출처 쌍에 기반해야 합니까, 아니면 다른 범위에 기반해야 합니까?

• 프롬프트가 데이터를 필요로 하는 맥락에서, 그리고 왜 프롬프트가 나타나는지 사용자에게 명확한 시점에 발생하고 있음을 어떻게 확신할 수 있습니까.

• 사용자에게 프롬프트를 표시하기 전에 권한의 영향을 설명하기, 접근 가능하고 지역화된 방식으로 -- _누가_ 요청하는지, _무엇_을 요청하는지, _왜_ 그것이 필요한지?

• 사용자가 프롬프트 시점에 요청을 거부하거나, 나중에 마음을 바꾸어 접근 권한을 철회하면 어떻게 됩니까.

이러한 프롬프트는 또한 데이터가 다른 당사자와 공유된 뒤 사용자가 자신의 데이터에 대해 어떤 통제권을 가지는지, 있다면 어떤 통제권인지에 대한 고려도 포함해야 합니다. 예를 들어, 사용자는 어떤 정보가 다른 당사자와 공유되었는지 확인할 수 있습니까?

4.4. 기능을 일차 당사자 출처로 명시적으로 제한하기

"제삼자 추적" 절에서 설명했듯이, 웹 페이지는 일차 당사자와 제삼자 콘텐츠를 하나의 애플리케이션으로 섞어, 제삼자 콘텐츠가 일차 당사자 콘텐츠와 같은 웹 기능 집합을 오용할 수 있는 위험을 도입합니다.

작성자는 기능의 사용 가능 범위를 명시적으로 지정해야 합니다:

• 기능이 임베드된 제삼자에게 제공되어야 하는 경우 -- 그리고 종종 일차 당사자가 이를 명시적으로 제어할 수 있어야 하는 경우 (iframe 속성이나 기능 정책 사용)

• 기능이 백그라운드에서 사용 가능해야 하는지, 아니면 최상위의 보이는 탭에서만 사용 가능해야 하는지.

• 기능이 오프라인 서비스 워커에서 사용 가능해야 하는지.

• 이벤트가 동시에 발생할지 여부

기능에 대한 제삼자 접근은 적합성을 위한 선택적 구현이어야 합니다.

4.5. 보안 맥락

여러분의 명세에서 식별한 주요 위험이 능동적 네트워크 공격자가 제기하는 위협이라면, 비보안 출처에 기능을 제공하는 것은 공격자가 프레임과 코드를 마음대로 주입할 수 있으므로 모든 출처에 그 기능을 제공하는 것과 같습니다. 기능을 사용하기 위해 암호화되고 인증된 연결을 요구하면 이런 종류의 위험을 완화할 수 있습니다.

보안 맥락은 수동적 네트워크 공격자로부터도 보호합니다. 예를 들어 페이지가 Geolocation API를 사용하고 센서가 제공한 위도와 경도를 비보안 연결을 통해 서버로 다시 보낸다면, 모든 수동적 네트워크 공격자는 사용자의 위치를 알 수 있으며, 사용자가 또는 다른 사람이 이를 감지할 수 있는 실질적인 경로가 없습니다.

그러나 보안 맥락을 요구하는 것만으로는 능동적 네트워크 공격자가 아닌 다른 위협 행위자로부터 오는 많은 개인정보 보호 위험이나 심지어 보안 위험을 완화하기에 충분하지 않습니다.

4.6. 기능 삭제

기능의 잠재적 부정적 보안 또는 개인정보 보호 영향을 완화하는 가장 단순한 방법은 그 기능을 삭제하는 것일 수 있습니다. 다만 일부 보안 또는 개인정보 보호 위험은 플랫폼에 기능을 추가함으로써 제거되거나 완화될 수 있다는 점을 유념해야 합니다. 명세의 모든 기능은 그렇지 않음이 입증될 때까지 보안 및/또는 개인정보 보호 위험을 잠재적으로 추가하는 것으로 보아야 합니다. 보안 또는 개인정보 보호 영향에 대한 완화책으로 기능 삭제를 논의하는 것은 기능, 그것이 필요한 최소한의 데이터만 노출하는지 여부, 그리고 다른 가능한 완화책 사이의 절충점을 밝히는 데 도움이 되는 유용한 연습입니다.

또한 사용자가 웹 페이지를 방문하는 것이 안전하다고 느끼는 전반적 인상에 대해 기능 추가가 누적적으로 미치는 영향도 고려하십시오. 웹사이트를 방문하는 것이 안전하다는 사용자의 이해를 복잡하게 하거나, 웹의 안전성에 대해 사용자가 이해해야 하는 것을 복잡하게 하는 일 (예: 덜 안전한 기능을 추가하는 것)은 사용자가 그 안전성에 대한 이해를 바탕으로 행동하거나, 존재하는 안전성을 올바르게 반영하는 방식으로 행동할 능력을 줄입니다.

모든 명세는 보안/개인정보 보호 공격 표면을 줄이고 최소화한다는 이유만으로도 가능한 한 작아지려고 해야 합니다. 그렇게 함으로써 우리는 특정 기능뿐만 아니라, 모듈(관련 기능 집합), 명세, 그리고 전체 웹 플랫폼의 전반적인 보안 및 개인정보 보호 공격 표면을 줄일 수 있습니다.

예

• Mozilla와 WebKit은 Battery Status API를 삭제했습니다

• Mozilla는 devicelight, deviceproximity 및 userproximity 이벤트를 삭제했습니다

4.7. 개인정보 영향 평가 수행

일부 기능은 민감한 데이터를 제공할 가능성이 있으며, 최종 개발자, 시스템 소유자 또는 관리자는 이를 인식하고 자신의 시스템 설계에서 그에 맞게 행동할 책임이 있습니다. 일부 사용은 개인정보 영향 평가 수행을 정당화할 수 있으며, 특히 개인과 관련된 데이터가 처리될 수 있는 경우 그렇습니다.

민감한 데이터를 노출하는 기능을 포함하는 명세는 API를 채택하는 웹사이트와 애플리케이션이 수집하는 데이터에 대한 개인정보 영향 평가를 수행하도록 권고하는 내용을 포함해야 합니다.

이를 수행하는 기능은 다음과 같습니다:

• [GENERIC-SENSOR]는 개인정보 영향 평가 수행을 고려할 것을 권고합니다

이러한 영향을 문서화하는 것은 조직에 중요하지만, 이를 조직에 부담시키는 데에는 한계가 있다는 점도 주목해야 합니다. 연구에 따르면 사이트는 명세의 보안/개인정보 보호 요구사항을 준수하지 않는 경우가 많습니다. 예를 들어, [DOTY-GEOLOCATION]에서는 연구된 웹사이트 중 어느 곳도 사이트가 위치 요청을 프롬프트하기 전에 사용자에게 개인정보 보호 관행을 알리지 않았다는 사실이 발견되었습니다.

감사의 말

이 문서에 기여해 준 Alice Boxhall, Alex Russell, Anne van Kesteren, Chris Cunningham, Coralie Mercier, Corentin Wallez, David Baron, Domenic Denicola, Dominic Battre, Jeffrey Yasskin, Jeremy Roman, Jonathan Kingston, Marcos Caceres, Marijn Kruisselbrink, Mark Nottingham, Martin Thomson, Michael(tm) Smith, Mike Perry, Nick Doty, Robert Linder, Piotr Bialecki, Samuel Weiler, Tantek Çelik, Thomas Steiner, Wendy Seltzer, 그리고 PING, Privacy Working Group, Security Interest Group, TAG의 많은 현재 및 이전 참여자들에게 깊이 감사드립니다.

bfcache를 명세 작성자가 고려하도록 돕는 편집을 해 준 Rakina Zata Amni에게 특별히 감사드립니다.

Mike West는 이 문서의 초기 버전을 작성하고 여러 해 동안 편집했습니다. Yan Zhu가 Mike로부터 이어받았고, 다시 Jason Novak와 Lukasz Olejnik이 그녀로부터 이어받았습니다. 현재 편집자들은 그들의 노고에 깊이 감사하고 있습니다. 우리가 이 문서를 (많이) 더 나쁘게 만들지 않았기를 바랍니다.