Chrome에서 서드 파티 쿠키 지원 중단에 대비하세요. 지금 사이트에 손상이 있는지 테스트합니다.

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

제3자

서드 파티란 무엇인가요?

완전히 독립된 웹사이트는 드뭅니다. HTTP Web Almanac에 따르면 대부분의 웹사이트(약 95%)에 일부 서드 파티 콘텐츠가 포함되어 있습니다.

연감에서는 서드 파티 콘텐츠를 공유 및 공개 출처에서 호스팅되는 콘텐츠로 정의하며, 이러한 콘텐츠는 다양한 사이트에서 널리 사용되고 개별 사이트 소유자의 영향을 받지 않습니다. 이러한 매체에는 이미지나 동영상, 글꼴, 스크립트와 같은 기타 미디어가 포함될 수 있습니다. 이미지와 스크립트는 다른 모든 것보다 많은 것을 차지합니다. 서드 파티 콘텐츠는 사이트 개발에 필수적이지는 않지만 유용할 수 있습니다. 웹 글꼴, 동영상의 삽입된 iframe, 광고 또는 자바스크립트 라이브러리 등 거의 확실하게 공개 공유 서버에서 로드된 항목을 사용하게 됩니다. 예를 들어 Google Fonts에서 제공하는 웹 글꼴을 사용하거나 Google 애널리틱스로 분석을 측정하거나, 소셜 네트워크에서 '좋아요' 버튼 또는 ' 계정으로 로그인' 버튼을 추가하거나, 지도 또는 동영상을 삽입하거나, 서드 파티 서비스를 통해 쇼핑 구매를 처리하거나, 서드 파티 모니터링 도구를 통해 개발팀의 오류 및 로깅을 추적할 수 있습니다.

개인 정보 보호를 위해 약간 다르고 덜 광범위한 정의를 고려하는 것이 좋습니다. 즉, 서드 파티 리소스, 특히 서드 파티 스크립트는 공유된 공개 출처에서 제공되고 그림과 같이 널리 사용되지만 사이트 소유자가 아닌 다른 사람이 작성한 것입니다. 서드 파티 저작권 측면은 사용자의 개인 정보를 타인으로부터 보호하는 방법을 고려할 때 핵심입니다. 이렇게 하면 존재하는 위험을 고려한 다음, 이러한 위험에 따라 서드 파티 리소스를 사용하는 방법과 사용 여부를 결정해야 합니다. 앞서 설명한 것처럼 이러한 것들을 통해 맥락을 이해하고 타협해야 하는 부분과 그 의미를 이해하는 데 도움이 됩니다.

이는 일반적으로 '서드 파티 리소스'를 논의할 때 의미가 없습니다. 퍼스트 파티와 서드 파티의 차이는 실제로 어떤 것이 사용되는 맥락에 관한 것입니다. 다른 웹사이트에서 로드된 스크립트는 서드 파티 리소스이며, 스크립트를 로드하는 HTTP 요청에 쿠키가 포함될 수 있지만, 이러한 쿠키는 실제로 '서드 파티 쿠키'가 아닙니다. 그냥 쿠키일 뿐이며, 스크립트가 '서드 파티'인지 '퍼스트 파티'인지는 스크립트가 사이트 페이지에 로드되는지 아니면 스크립트 소유자 사이트의 페이지에서 로드되는지에 따라 다릅니다.

서드 파티 리소스를 사용하는 이유는 무엇인가요?

서드 파티는 사이트에 기능을 추가할 수 있는 좋은 방법입니다. 이는 사용자에게 노출되는 기능이거나 오류 추적과 같이 보이지 않는 개발자 기능일 수 있지만 개발 부하를 줄일 수 있으며 스크립트 자체는 포함된 서비스의 개발팀이 다른 사람에 의해 유지관리됩니다. 이 모든 것은 웹의 구성 가능성, 즉 각 부분을 결합하여 합보다 큰 전체를 형성할 수 있기 때문입니다.

HTTP 아카이브의 Web Almanac에 자세한 설명을 제공합니다.

서드 파티는 이미지, 동영상, 글꼴, 도구, 라이브러리, 위젯, 추적기, 광고 등 웹페이지에 삽입할 수 있는 모든 것을 끝없이 제공합니다. 이를 통해 기술에 익숙하지 않은 사람도 콘텐츠를 만들어 웹에 게시할 수 있습니다. 서드 파티가 없었다면 웹은 오늘날 많은 사람들의 삶에 필수적인 풍성하고 몰입도 높은 복잡한 플랫폼이 아닌 매우 지루하고 텍스트 기반의 학문적 매체가 될 것입니다.

서드 파티 리소스로 무엇을 할 수 있나요?

일부 정보 액세스

웹사이트에서 제3자 리소스를 사용하는 경우 정보의 종류와 관계없이 일부 정보가 해당 제3자에게 전달됩니다. 예를 들어 다른 사이트의 이미지를 포함하는 경우 사용자의 브라우저가 수행하는 HTTP 요청은 페이지 URL과 함께 사용자의 IP 주소와 함께 리퍼러 헤더를 전달합니다.

크로스 사이트 추적

동일한 예를 계속 들어보겠습니다. 이미지가 서드 파티 사이트에서 로드될 때 이미지가 쿠키를 포함할 수 있고, 이 쿠키는 사용자가 다음번에 이미지를 요청할 때 서드 파티로 다시 전송됩니다. 즉, 서드 파티가 사이트에서 서비스가 사용되고 있음을 인지할 수 있으며, 이 사용자의 고유 ID가 포함된 쿠키를 다시 전송할 수 있습니다. 즉, 이후에 사용자가 내 사이트 또는 타사의 리소스를 포함하는 다른 사이트를 방문할 때 고유 ID 쿠키가 다시 전송됩니다. 이렇게 하면 서드 파티는 웹에서 사용자가 방문하는 위치(내 사이트, 동일한 서드 파티 리소스를 사용하는 다른 사이트)에 관한 로그를 구축할 수 있습니다.

크로스 사이트 추적은 서드 파티가 여러 웹사이트에서의 사용자 활동 로그를 수집할 수 있도록 허용합니다. 단, 이러한 웹사이트는 모두 동일한 서드 파티의 리소스를 사용하는 경우에 한합니다. 이러한 요소는 글꼴, 이미지 또는 스타일시트(모두 정적 리소스)일 수 있습니다. 또한 스크립트, 소셜 미디어 버튼, 광고와 같은 동적 리소스가 될 수도 있습니다. 포함된 스크립트는 동적이기 때문에 더 많은 정보를 수집할 수 있습니다. 즉, 사용자의 브라우저와 환경을 검사하고 데이터를 작성자에게 다시 전달할 수 있습니다. 소셜 미디어 삽입, 광고 또는 공유 버튼과 같이 스크립트로 표시되지 않는 동적 리소스와 같이 모든 스크립트가 이 작업을 어느 정도 수행할 수 있습니다. 인기 웹사이트에서 쿠키 배너의 세부정보를 살펴보면 사용자에게 추적 쿠키를 추가하여 사용자 활동을 파악하고 사용자의 프로필을 생성할 수 있는 조직 목록을 확인할 수 있습니다. 수백 개가 있을 수 있습니다. 제3자가 무료로 서비스를 제공한다면 이 데이터를 수집하여 수익을 창출하기 때문에 경제적으로도 이를 실현할 수 있습니다.

브라우저가 사용자를 보호해야 하는 개인 정보 보호 문제 유형에 관한 유용한 가이드는 타겟 개인 정보 보호 위협 모델입니다. 이 문서는 아직 이 문서 작성 시점에 논의 중인 문서이지만, 존재하는 개인 정보 보호 위협을 개략적으로 분류하여 설명합니다. 서드 파티 리소스의 위험은 주로 웹사이트가 여러 사이트에서 동일한 사용자를 식별할 수 있는 '원치 않는 크로스 사이트 인식'과 사용자가 민감하다고 생각되는 정보를 사이트에서 수집할 수 있는 '민감한 정보 공개'입니다.

이는 주요 차이점입니다. 원치 않는 교차 사이트 인식은 서드 파티에서 민감한 정보를 추가로 수집하지 않더라도 사용자의 신원을 제어할 수 없게 되기 때문에 좋지 않습니다. 사용자의 리퍼러, IP 주소, 쿠키에 대한 액세스 권한을 얻는 것은 그 자체로 원치 않는 공개입니다. 서드 파티 리소스 사용은 개인 정보를 보호하는 방식으로 해당 리소스를 사용하는 방법에 대한 계획 구성요소와 함께 수반됩니다. 이러한 작업 중 일부는 사이트 개발자가 담당하고, 일부는 브라우저에서 사용자 에이전트 역할을 수행합니다. 즉, 에이전트가 사용자를 대신하여 민감한 정보 공개 및 원치 않는 크로스 사이트 인식을 피하도록 하는 것입니다. 아래에서는 브라우저 수준 및 사이트 개발 수준의 완화 및 접근 방법을 자세히 살펴보겠습니다.

서버 측 서드 파티 코드

서드 파티에 관한 이전 정의에서는 HTTP Almanac의 클라이언트 측 접근 방식을 보고서에 적합하게 의도적으로 변경하여 서드 파티 소유권을 포함하도록 합니다. 개인 정보 보호 관점에서 볼 때 서드 파티는 개발자가 아닌 사용자에 관해 모든 것을 아는 모든 사람입니다.

여기에는 클라이언트뿐만 아니라 서버에서 사용하는 서비스를 제공하는 제3자가 포함됩니다. 개인 정보 보호 측면에서 서드 파티 라이브러리 (예: NPM, Composer 또는 NuGet에서 포함된 항목)도 이해하는 것이 중요합니다. 종속 항목이 경계 외부로 데이터를 전달하나요? 로깅 서비스 또는 원격 호스팅 데이터베이스에 데이터를 전달하는 경우, 라이브러리의 작성자에게 '전화 홈'도 포함하는 경우, 사용자의 개인 정보를 침해할 수 있으므로 감사가 필요할 수 있습니다. 서버 기반 서드 파티는 일반적으로 사용자 데이터를 제공해야 합니다. 즉, 서드 파티가 노출되는 데이터는 개발자가 더 잘 제어할 수 있습니다. 반면 클라이언트 기반의 제3자(웹사이트에 포함되어 있고 사용자의 브라우저에서 가져온 스크립트 또는 HTTP 리소스)는 수집 프로세스를 중재하지 않아도 사용자로부터 직접 일부 데이터를 수집할 수 있습니다. 이 모듈에서는 사용자를 포함하고 노출하기로 선택한 클라이언트 측 서드 파티를 식별하는 방법에 대해 다룹니다. 미디에이션의 범위가 더 적기 때문입니다. 하지만 서버 측 코드의 아웃바운드 통신을 이해하고 예기치 않은 코드를 로깅하거나 차단할 수 있도록 서버 측 코드를 보호하는 것이 좋습니다. 정확한 방법에 관한 세부정보는 여기서 다루지 않으며 서버 설정에 따라 크게 달라지지만 이는 보안 및 개인 정보 보호 입장의 또 다른 부분입니다.

제3자 파트너와 협력할 때 주의해야 하는 이유는 무엇인가요?

서드 파티 스크립트와 기능은 매우 중요하며, 웹 개발자의 목표는 이러한 것을 버리지 않고 통합하는 것입니다. 그러나 잠재적인 문제가 있습니다. 타사 콘텐츠는 성능 문제를 일으킬 수 있으며, 외부 서비스를 신뢰 경계 내부로 가져오기 때문에 보안 문제가 발생할 수도 있습니다. 하지만 서드 파티 콘텐츠로 인해 개인 정보 보호 문제가 발생할 수도 있습니다.

웹에서 서드 파티 리소스에 관해 이야기할 때 무엇보다도 보안 문제는 서드 파티가 회사의 데이터를 훔칠 수 있는 보안 문제라고 생각하는 것이 유용합니다. 개인 정보 보호 문제는 무엇보다도 내가 포함한 제3자가 귀하 또는 제3자의 동의 없이 사용자 데이터를 훔치거나 획득하는 개인 정보 보호 문제입니다.

보안 문제의 예로는 '웹 스키머'가 신용카드 정보를 훔치는 경우(사용자가 신용카드 세부정보를 입력하는 페이지에 포함된 서드 파티 리소스)가 신용카드 세부정보를 도용하여 악의적인 제3자에게 보낼 수 있습니다. 이런 스키머 스크립트를 만드는 개발자들은 이 스크립트를 숨기는 데 매우 창의력을 발휘합니다. 한 가지 요약에서는 사이트 로고, 파비콘, 소셜 미디어 네트워크에 사용되는 이미지, jQuery, Modernizr, Google 태그 관리자와 같은 인기 라이브러리, 실시간 채팅 창과 같은 사이트 위젯, CSS 파일과 같은 서드 파티 콘텐츠에서 스키머 스크립트가 어떻게 숨겨져 있는지 설명합니다.

개인 정보 보호 문제는 조금 다릅니다. 이러한 서드 파티는 혜택의 일부이므로 사용자의 신뢰를 유지하려면 사용자가 이러한 서드 파티를 신뢰할 수 있다는 확신이 있어야 합니다. 이용 중인 서드 파티에서 사용자에 관한 데이터를 수집한 후 오용하거나, 삭제 또는 검색이 어렵거나, 정보 유출이 발생하거나, 사용자의 기대를 위반하는 경우, 사용자는 이를 서드 파티뿐만 아니라 개발자의 서비스에 대한 신뢰가 깨지는 것으로 인식할 가능성이 높습니다. 온라인상에서 내 평판과 관계를 형성해야 합니다. 그렇기 때문에 사이트에서 사용하고 있는 서드 파티를 신뢰할 수 있는지 자문해 보는 것이 중요합니다.

제3자의 예로는 어떤 것이 있나요?

여기서는 '서드 파티'에 대해 일반적으로 논의하지만 실제로는 종류도 다양하며 액세스하는 사용자 데이터의 양도 다릅니다. 예를 들어 다른 서버에서 로드된 <img> 요소를 HTML에 추가하면 <iframe> 또는 <script> 요소를 추가하는 것과는 다른 사용자 정보가 해당 서버에 제공됩니다. 이러한 목록은 전체 목록이 아니라 예시일 뿐이지만 사이트에서 사용할 수 있는 다양한 유형의 서드 파티 항목 간의 차이점을 이해하는 데 도움이 됩니다.

크로스 사이트 리소스 요청

크로스 사이트 리소스는 다른 사이트에서 로드되고 <iframe> 또는 <script>가 아닌 사이트의 모든 것을 의미합니다. 예를 들어 <img>, <audio>, <video>, CSS에 의해 로드된 웹 글꼴, WebGL 텍스처가 있습니다. 이러한 쿠키는 모두 HTTP 요청을 통해 로드되며, 앞서 설명한 것처럼 이러한 HTTP 요청에는 다른 사이트에서 이전에 설정한 쿠키, 요청하는 사용자의 IP 주소, 현재 페이지의 URL이 리퍼러로 포함됩니다. 지금까지 모든 서드 파티 요청에는 기본적으로 이 데이터가 포함되었지만, '서드 파티 브라우저 보호 기능 이해'에 자세히 설명된 것처럼 다양한 브라우저에서 서드 파티로 전달된 데이터를 줄이거나 격리하려는 노력도 있습니다.

교차 사이트 iframe 삽입

<iframe>를 통해 페이지에 삽입된 전체 문서는 쿠키, IP 주소, 리퍼러의 세 가지 외에도 브라우저 API에 대한 추가 액세스를 요청할 수 있습니다. <iframe>된 페이지에서 사용할 수 있는 API와 이러한 API에서 액세스를 요청하는 방법은 브라우저별로 다르며 현재 변경 중입니다. 삽입된 문서의 API 액세스를 줄이거나 모니터링하기 위한 현재의 노력은 아래의 '권한 정책'을 참고하세요.

크로스 사이트 자바스크립트 실행하기

<script> 요소를 포함하면 페이지의 최상위 컨텍스트에서 크로스 사이트 자바스크립트가 로드되고 실행됩니다. 즉, 실행되는 스크립트에서 자체 퍼스트 파티 스크립트의 모든 기능에 완전히 액세스할 수 있습니다. 브라우저 권한에서 이 데이터를 계속 관리하므로 사용자의 위치를 요청하려면 (예: 사용자 동의) 여전히 사용자 동의가 필요합니다. 하지만 페이지에 있거나 자바스크립트 변수로 사용할 수 있는 모든 정보는 이러한 스크립트에서 읽을 수 있으며, 여기에는 요청의 일부로 제3자에게 전달되는 쿠키뿐만 아니라 내 사이트 전용 쿠키도 포함됩니다. 마찬가지로 페이지에 로드된 서드 파티 스크립트가 자체 코드와 동일한 HTTP 요청을 수행할 수 있습니다. 즉, 백엔드 API에 fetch() 요청을 보내 데이터를 가져올 수 있습니다.

종속 항목에 서드 파티 라이브러리 포함

앞에서 설명한 것처럼 서버 측 코드에는 서드 파티 종속 항목도 포함될 수 있으며 이러한 종속 항목이 자체 코드와 구별되지 않습니다. GitHub 저장소나 프로그래밍 언어 라이브러리 (npm, PyPI, 작성기 등)에서 포함하는 코드는 다른 코드가 사용할 수 있는 데이터와 동일한 데이터를 모두 읽을 수 있습니다.

제3자 파트너에 대한 정보

이를 위해서는 제3자 공급업체의 목록과 제3의 공급업체의 개인 정보 보호, 데이터 수집, 사용자 환경 정책 및 정책을 이해해야 합니다. 이러한 이해는 서비스가 얼마나 유용하고 중요한지, 사용자의 요구를 얼마나 거슬리게 하거나, 불편하게 하거나, 불편하게 하는지와 균형을 이루는 절충점의 일부가 됩니다. 서드 파티 콘텐츠는 사이트 소유자가 하는 부담을 덜어내어 가치를 제공하고, 이를 통해 핵심 역량에 집중할 수 있습니다. 따라서 더 나은 사용자 경험을 위해 사용자의 편안함과 개인 정보 보호를 희생하는 것이 가치가 있습니다. 그러나 사용자 환경을 개발자 환경과 혼동하지 않는 것이 중요합니다. 그러나 '개발팀이 서비스를 더 쉽게 빌드할 수 있다'는 말은 사용자의 관심을 끌지 못합니다.

이 것을 이해하는 방법이 감사 과정입니다.

서드 파티 감사

서드 파티가 하는 일을 이해하는 것은 감사 절차입니다. 이 작업은 기술적, 비기술적 측면에서, 그리고 개별적인 서드 파티와 전체 컬렉션에 대해 수행할 수 있습니다.

기술 외적인 감사 실행

첫 단계는 기술 이외 부문입니다. 공급업체의 개인정보처리방침을 읽어보세요. 서드 파티 리소스가 포함된 경우 개인정보처리방침을 확인하세요. 이 문서는 길고 법률 문안으로 가득하며, 일부 문서에서는 지나치게 일반적인 설명, 수집된 데이터의 삭제 방법 또는 시기를 명시하지 않는 등 이전 모듈에서 특별히 경고를 받은 일부 접근 방식을 사용할 수 있습니다. 사용자의 관점에서 제3자를 포함하여 사이트에서 수집되는 모든 데이터에는 이러한 개인정보처리방침이 적용됨을 기억해야 합니다. 모든 작업을 올바르게 실행하더라도 목표를 투명하게 공개하고 사용자의 데이터 개인 정보 보호 및 민감도에 대한 사용자의 기대치를 넘어선 경우, 사용자는 개발자가 선택한 서드 파티가 한 모든 일에 대해서도 책임을 질 수 있습니다. 개인정보처리방침에 사용자의 신뢰를 떨어뜨릴 수 있어 자체 정책에서 언급하고 싶지 않은 내용이 있다면 다른 공급업체가 있는지 고려합니다.

이는 서로 정보를 제공하므로 이후에 설명할 기술 감사와 함께 유용하게 사용할 수 있습니다. 비즈니스 관계가 성립되므로 비즈니스 목적 (예: 광고 네트워크 또는 삽입된 콘텐츠)으로 통합하는 서드 파티 리소스를 알아야 합니다. 비기술적 감사를 시작하는 것이 좋습니다. 기술 감사는 또한 제3자, 특히 비즈니스상의 이유 (외부 구성요소, 분석, 유틸리티 라이브러리)를 위해 포함된 제3자를 식별할 가능성이 높으며 해당 목록은 비즈니스 중심 제3자 목록과 조인될 수 있습니다. 여기서 목표는 사이트 소유자가 사이트에 추가하는 제3자가 하는 일을 이해했다고 느끼고, 비즈니스로서 필요한 의무를 이행할 수 있도록 법률 자문가에게 이러한 제3자 인벤토리를 제시할 수 있도록 하는 것입니다.

기술 감사 실행

기술 감사에서는 리소스를 웹사이트의 일부로 현장에서 사용하는 것이 중요합니다. 즉, 테스트 하네스에 종속 항목을 로드하고 이러한 식으로 검사하면 안 됩니다. 종속 항목이 테스트 또는 개발 모드가 아닌 공개 인터넷에 배포된 실제 웹사이트의 일부로 어떻게 작동하는지 확인합니다. 자신의 웹사이트를 신규 사용자로 보는 것은 매우 도움이 됩니다. 로그인하지 않고 저장된 계약이 없는 안전한 새 프로필에서 브라우저를 열고 사이트를 방문합니다.

참고: 신규 사용자인 것처럼 사이트를 테스트한다는 것은 사이트에 관해 저장된 정보가 없는 상태에서 사이트를 조회한다는 의미입니다. 이러한 상황에서는 신규 사용자인 것처럼 웹사이트를 테스트하려고 할 때마다 새 프로필을 만드는 것이 좋습니다. 새 프로필을 만들어 다시 사용하지 마세요. 매번 새 프로필을 만든 후 삭제하세요. 이 과정은 주로 데스크톱 브라우저에서 빠르게 진행됩니다. Chrome, Edge, Firefox에 대한 문서를 참고하세요. Android 및 Safari용 Chrome은 새로운 빈 프로필 생성을 지원하지 않으므로 시크릿/시크릿 브라우징 모드로도 충분하지만, 일반적으로 시크릿/시크릿 브라우징 모드와 새로 만든 프로필을 사용하여 사이트를 테스트하는 것이 중요합니다.

사용자 계정을 제공하는 경우 자체 사이트에서 새 계정을 만듭니다. 디자인팀에서 이 새로운 사용자 획득 프로세스를 UX 관점에서 조정하겠지만 개인 정보 보호 관점에서 접근하는 것은 예시일 수 있습니다. 이용약관, 쿠키 경고, 개인정보처리방침에서 '동의'를 클릭하기만 해서는 안 됩니다. 개인 정보를 공개하거나 추적 쿠키를 사용하지 않고 자체 서비스를 사용하는 방법을 정하고, 그렇게 할 수 있는지, 그리고 얼마나 어려운지 확인하세요. 브라우저 개발자 도구에서 액세스 중인 사이트와 이러한 사이트로 전달되는 데이터를 확인하는 것도 도움이 될 수 있습니다. 개발자 도구는 별도의 HTTP 요청 목록을 제공하며 (일반적으로 '네트워크' 섹션에 있음) 여기에서 요청을 유형 (HTML, CSS, 이미지, 글꼴, 자바스크립트, 자바스크립트에서 시작된 요청)별로 그룹화하여 확인할 수 있습니다. 또한 각 요청의 도메인을 표시하는 새 열을 추가할 수도 있습니다. 이 열을 통해 몇 개의 다른 연락이 이루어지는지 확인할 수 있습니다. 또한 서드 파티만 표시하는 '서드 파티 요청' 체크박스도 있을 수 있습니다. Content-Security-Policy 보고를 사용하여 지속적 감사를 수행하는 것도 유용할 수 있습니다. 자세한 내용은 다음을 참고하세요.

Simon Hearne의 'Request Map Generator' 도구도 공개적으로 사용 가능한 페이지에서 만드는 모든 하위 요청을 개략적으로 파악하는 데 유용할 수 있습니다.

또한 비기술적 감사의 일부로 확인된 비즈니스 중심 제3자(즉, 리소스를 사용하기 위해 재정적 관계가 있는 회사의 목록)를 포함할 수 있습니다. 여기서 목표는 재무 및 법적 기록에서 사용 중인 것으로 판단되는 서드 파티 목록과 실제로 사용 중인 목록을 일치시키는 것입니다(웹사이트에서 생성하는 서드 파티 HTTP 요청을 확인하여). 각 비즈니스 제3자에 대해 어떤 기술적 아웃바운드 요청이 이루어지는지 식별할 수 있어야 합니다. 비즈니스 관계로 확인된 서드 파티에 대한 기술 감사에서 요청을 식별할 수 없는 경우 이유를 파악하고 이를 바탕으로 테스트에 참여해야 합니다. 서드 파티 리소스는 특정 국가, 특정 기기 유형 또는 로그인한 사용자에 대해서만 로드되었을 수 있습니다. 이렇게 하면 감사할 사이트 영역 목록이 확대되고 모든 아웃바운드 액세스가 표시됩니다. (또는 비용을 지불하고 사용하지 않는 서드 파티 리소스를 식별하여 항상 재무 부서를 응원할 수도 있습니다.)

감사에 포함할 제3자에 대한 요청 목록의 범위를 좁히고 나면 개별 요청을 클릭하면 모든 세부정보, 특히 해당 요청으로 전달된 데이터가 표시됩니다. 또한 코드가 시작한 서드 파티 요청이 이후 수많은 다른 서드 파티 요청을 시작하는 경우도 매우 흔합니다. 이러한 추가 제3자도 귀하의 개인정보처리방침으로 '가져옵니다'. 이 작업은 힘들지만 가치가 있으며 기존 분석에 삽입할 수 있는 경우가 많습니다. 프런트엔드 개발팀은 이미 WebPageTest 또는 Lighthouse와 같은 기존 도구를 사용하여 성능상의 이유로 요청을 감사하고 있어야 하며, 데이터 및 개인 정보 보호 감사를 해당 프로세스에 통합하면 더 쉽게 수행할 수 있습니다.

web.dev 요청 맵 — web.dev의 매우 간소화된 요청 맵으로, 다른 서드 파티 사이트 등을 요청하는 서드 파티 사이트를 보여줍니다.

권장사항

로그인하지 않고 저장된 계약이 없는 새로운 사용자 프로필로 브라우저를 엽니다. 그런 다음 브라우저 개발 도구 네트워크 패널을 열어 모든 발신 요청을 확인합니다. 각 요청의 도메인을 표시할 새 열을 추가하고, 서드 파티 요청(있는 경우)만 표시하려면 '서드 파티 요청' 체크박스를 선택합니다. 다음 안내를 따르세요.

사이트를 방문합니다.
사용자 계정을 제공하는 경우 새 계정에 가입합니다.
만든 계정을 삭제해 보세요.
사이트에서 일반적인 액션을 1~2회 수행합니다. 구체적인 작업은 사이트 활동에 따라 다르지만 대부분의 사용자가 수행하는 일반적인 작업을 선택합니다.
특히 서드 파티 종속 항목이 관련되어 있다고 생각되는 한두 가지 작업을 수행합니다. 소셜 미디어에 콘텐츠를 공유하거나, 결제 흐름을 시작하거나, 다른 사이트의 콘텐츠를 삽입하는 등의 작업을 예로 들 수 있습니다.

이러한 각 작업을 수행할 때 설명된 대로 네트워크 패널을 확인하여 내 소유가 아닌 도메인에서 요청된 리소스를 기록합니다. 여기에는 일부 서드 파티가 있습니다. 이렇게 하는 좋은 방법은 브라우저 네트워크 도구를 사용하여 네트워크 요청 로그를 HAR 파일로 캡처하는 것입니다.

HAR 파일 및 캡처

HAR 파일은 페이지에서 보낸 모든 네트워크 요청의 표준화된 JSON 형식입니다. 특정 페이지의 HAR 파일을 가져오는 방법은 다음과 같습니다.

Chrome

브라우저 DevTools를 열고 (메뉴 > 도구 더보기 > 개발자 도구) Network 패널로 이동하여 페이지를 로드 (또는 새로고침)한 후 오른쪽 상단의 No throttling 드롭다운 메뉴 근처에 있는 아래쪽 화살표 저장 기호를 선택합니다.

Firefox

브라우저 개발자 도구를 열고 (메뉴 > 도구 더보기 > 웹 개발자 도구) 네트워크 패널로 이동하여 페이지를 로드 (또는 새로고침)한 후 제한 드롭다운 메뉴 옆의 오른쪽 상단에 있는 톱니바퀴 기호를 선택합니다. 메뉴에서 Save All as HAR(모두 HAR로 저장)을 선택합니다**.

Safari

브라우저 개발자 도구를 열고 (메뉴 > 개발 > 웹 검사기 표시, 개발 메뉴가 없는 경우 메뉴 바에서 메뉴 > Safari > 환경설정 > 고급 > 개발 메뉴 표시에서 사용 설정), Network 패널로 이동하여 페이지를 로드 (또는 새로고침)한 후 오른쪽 상단 (로그 보존 오른쪽, 창을 확대해야 할 수 있음)에서 Export를 선택합니다.

자세한 내용은 요청 섹션에서 서드 파티에 전달되는 내용을 기록할 수도 있지만 이 데이터는 난독화되어 유용하게 해석되지 않는 경우가 많습니다.

서드 파티 통합 시 권장사항

사이트에서 사용하는 서드 파티에 대한 자체 정책을 설정할 수 있습니다. 서드 파티의 관행에 따라 사용하는 광고 제공업체를 변경하거나 쿠키 동의 팝업이 얼마나 성가시거나 방해가 되는지, 사이트에서 소셜 미디어 버튼을 사용할지, 이메일의 링크 또는 Google 애널리틱스에서 트윗을 추적할지 utm_campaign 링크를 추적할지 여부 등을 변경할 수 있습니다. 사이트를 개발할 때 고려해야 할 한 가지 측면은 분석 서비스의 개인 정보 보호 및 보안 상태입니다. 일부 분석 서비스는 개인 정보 보호를 명시적으로 상쇄합니다. 종종 개인 정보 보호 기능을 추가하는 서드 파티 스크립트를 사용하는 방법도 있습니다. 사용자의 개인 정보를 개선하고 서드 파티 데이터 수집으로부터 사용자를 보호하려는 첫 번째 팀이 아니기 때문에 이미 해결책이 있을 수 있습니다. 마지막으로 많은 서드 파티 제공업체가 과거보다 데이터 수집 문제에 더 민감하므로 사용자 보호 모드를 강화하는 기능이나 매개변수를 추가할 수 있는 경우가 많습니다. 다음은 몇 가지 예입니다.

소셜 미디어 공유 버튼을 추가할 때

HTML 버튼을 직접 삽입해 보세요. https://sharingbuttons.io/ 사이트에 잘 설계된 예가 포함되어 있습니다. 또는 일반 HTML 링크를 추가할 수도 있습니다. 단점은 '공유 수' 통계와 Facebook 분석에서 고객을 분류할 수 있는 능력을 잃게 된다는 것입니다. 이는 서드 파티 제공업체를 사용하는 것과 적은 분석 데이터를 수신하는 것 사이의 균형점을 보여주는 예입니다.

일반적으로 서드 파티에서 일종의 대화형 위젯을 삽입할 때 해당 서드 파티로 연결되는 링크를 대신 제공할 수 있는 경우가 많습니다. 즉, 사이트에 인라인 환경이 없지만 서드 파티와의 데이터 공유에 관한 결정이 개발자 대신 사용자가 선호하는 상호작용 여부를 선택할 수 있습니다.

예를 들어 다음과 같이 Twitter와 Facebook에 대한 링크를 추가하여 mysite.example.com에서 서비스를 공유할 수 있습니다.

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

Facebook에서는 공유할 URL 지정을 허용하고 Twitter에서는 URL 및 일부 텍스트 지정을 허용합니다.

동영상을 퍼갈 때

동영상 호스팅 사이트의 동영상을 퍼가는 경우 퍼가기 코드에서 개인 정보 보호 옵션을 찾아보세요. 예를 들어 YouTube의 경우 삽입 URL의 youtube.com를 www.youtube-nocookie.com로 대체하여 삽입 페이지를 보는 사용자에게 추적 쿠키가 설치되지 않도록 합니다. YouTube에서 공유/퍼가기 링크를 생성할 때 '개인 정보 보호 강화 모드 사용'을 선택할 수도 있습니다. 이는 서드 파티가 제공하는 보다 안전한 사용자 보호 모드를 사용하는 좋은 예입니다. (https://support.google.com/youtube/answer/171780에서 자세한 내용과 YouTube의 기타 퍼가기 옵션에 대해 자세히 알아보세요.)

다른 동영상 사이트에는 이와 관련된 옵션이 적습니다. 예를 들어 TikTok에는 추적 없이 동영상을 삽입할 수 있는 방법이 없습니다. 대안을 사용하여 동영상을 직접 호스팅할 수도 있지만 특히 많은 기기를 지원하기 위해 더 많은 작업이 필요할 수 있습니다.

앞에서 설명한 대화형 위젯과 마찬가지로 삽입된 동영상을 제공하는 웹사이트의 링크로 대체할 수 있는 경우가 많습니다. 이 경우 동영상은 인라인으로 재생되지 않으며 사용자와 함께 시청할지 여부를 선택할 수 있으므로 상호작용성이 떨어집니다. 이는 대화형 콘텐츠를 트리거하려면 사용자 작업이 필요한 항목으로 동적으로 대체하기 위한 이름인 '퍼사드 패턴'의 예로 사용할 수 있습니다. 삽입된 TikTok 동영상을 TikTok 동영상 페이지로 연결되는 일반 링크로 대체할 수 있지만 약간의 작업을 하면 동영상의 썸네일을 가져와 표시하고 링크로 만들 수 있습니다. 선택한 동영상 제공업체에서 추적 없이 동영상을 삽입할 수 있는 쉬운 방법을 지원하지 않더라도, 많은 동영상 호스트가 oEmbed를 지원합니다. oEmbed는 동영상 또는 삽입된 콘텐츠의 링크가 주어지면 썸네일과 제목을 포함한 프로그래매틱 세부정보를 반환합니다. TikTok은 oEmbed를 지원합니다(자세한 내용은 https://developers.tiktok.com/doc/embed-videos 참고). 즉, TikTok 동영상 https://www.tiktok.com/@scout2015/video/6718335390845095173의 링크를 https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173를 사용하여 (수동 또는 프로그래매틱 방식으로) 해당 동영상에 대한 JSON 메타데이터로 변환하여 표시할 썸네일을 가져올 수 있습니다. 예를 들어 WordPress는 삽입된 콘텐츠의 oEmbed 정보를 요청하는 데 이 기능을 주로 사용합니다. 이를 프로그래매틱 방식으로 사용하여, 대화형처럼 보이는 '퍼사드'를 표시하고, 사용자가 동영상을 클릭하기로 하면 대화형 동영상을 삽입하거나 동영상으로 연결하도록 전환할 수 있습니다.

분석 스크립트를 삽입할 때

애널리틱스는 분석이 가능하도록 사용자에 대한 정보를 수집하도록 설계되어 있습니다. 애널리틱스 시스템은 기본적으로 액세스 및 사용자에 대한 데이터를 수집하고 표시하는 서비스이며, 구현 용이성을 위해 Google 애널리틱스와 같은 서드 파티 서버에서 수행됩니다. https://matomo.org/와 같은 자체 호스팅 분석 시스템도 있지만 이를 위해 서드 파티 솔루션을 사용하는 것보다 더 많은 작업이 필요합니다. 그러나 자체 인프라에서 이러한 시스템을 실행하면 자체 생태계를 벗어나지 않으므로 데이터 수집을 줄일 수 있습니다. 반면 해당 데이터를 관리 및 삭제하고 관련 정책을 설정하는 것은 개발자의 책임입니다. 크로스 사이트 추적에 대한 우려는 은밀하고 은밀하게 수행되거나 데이터 수집을 아예 포함할 필요가 없는 서비스 사용의 부작용으로 인해 발생하는 경우가 많습니다. 애널리틱스 소프트웨어는 사이트 소유자에게 사용자 정보를 제공하기 위해 데이터를 수집하도록 설계되어 있습니다.

역사적으로 거대한 낚시 그물과 같이 모든 것에 대해 가능한 모든 데이터를 수집한 다음, 나중에 흥미로운 패턴을 찾아내는 접근 방식이 있었습니다. 이러한 사고방식으로 인해 이 과정의 1부에서 다룬 데이터 수집에 대해 불안해하고 불안감을 느꼈습니다. 이제는 많은 사이트가 먼저 어떤 질문을 해야 할지 판단한 다음 이러한 질문에 답하기 위해 구체적이고 제한된 데이터를 수집합니다.

내 사이트 및 다른 사이트에서 일부 서드 파티 서비스를 사용하고, 사이트의 자바스크립트를 사이트에 포함시켜 작동하여 각 사용자의 쿠키를 설정하는 경우, 이러한 서드 파티 서비스가 원치 않는 크로스 사이트 인식을 실행하고 있을 수 있다는 점을 고려해야 합니다. 즉, 사이트 전체에서 사용자를 추적합니다. 일부는 없을 수도 있고 일부는 아닐 수도 있지만, 여기서는 개인 정보 보호 입장은 달리 생각하거나 알아야 할 타당한 이유가 없는 한 이러한 서드 파티 서비스가 실제로 크로스 사이트 추적을 실행하고 있다고 가정하는 것입니다. 그 자체가 이러한 서비스를 피해야 할 이유는 아니지만 서비스 사용의 장단점을 평가할 때 고려해야 합니다.

과거에는 분석 사용 여부를 선택할 뿐입니다. 즉, 유용한 정보와 계획을 얻는 대가로 모든 데이터를 수집하고 개인 정보 보호를 침해하거나 통계를 완전히 포기하는 것이었습니다. 그러나 이것은 더 이상 사실이 아니며, 이제 이러한 두 극단 사이에 중간 지점이 생기는 경우가 많습니다. 수집 데이터를 제한하고 저장 양과 기간을 줄이는 구성 옵션은 분석 제공업체에 문의하세요. 앞에서 설명한 기술 감사 기록이 있으므로 해당 감사의 관련 섹션을 다시 실행하여 이러한 구성을 변경하면 실제로 수집되는 데이터의 양이 줄었는지 확인할 수 있습니다. 기존 사이트에서 이 방식으로 전환하는 경우 사용자를 위해 작성할 수 있는 정량화 가능한 측정값을 얻게 됩니다. 예를 들어 Google 애널리틱스에는 여러 가지 선택 (기본적으로 사용 중지됨) 개인 정보 보호 기능이 있으며 이 중 다수는 현지 데이터 보호법을 준수하는 데 도움이 될 수 있습니다. Google 애널리틱스를 설정할 때 고려해야 할 몇 가지 옵션으로는 수집된 데이터의 보관 기간 (관리자 > 추적 정보 > 데이터 보관)을 26개월 기본값보다 낮게 설정하고 부분 IP 익명처리와 같은 기술 솔루션 사용 설정 등이 있습니다 (자세한 내용은 https://support.google.com/analytics/answer/9019185 참조).

개인 정보를 보호하는 방식으로 서드 파티를 사용하는 경우

지금까지 애플리케이션의 설계 단계에서 서드 파티로부터 사용자를 보호하는 방법과 애플리케이션의 기능을 계획하는 방법을 알아봤습니다. 특정 서드 파티를 아예 사용하지 않기로 결정하는 것도 이 계획의 일부이며, 사용 감사도 이 카테고리에 속합니다. 즉, 개인 정보 보호 입장에 대한 결정을 내리는 것과 관련이 있습니다. 그러나 이러한 결정은 본질적으로 매우 세분화되지 않습니다. 특정 서드 파티를 사용하거나 사용하지 않기로 하는 것은 미묘한 결정이 아닙니다. 특정 서드 파티 제품을 요구하거나 사용할 계획이지만, (고의적이든 실수든) 개인 정보 침해 경향을 완화하려는 두 가지 사이에서 고안이 필요할 가능성이 훨씬 더 높습니다. 이는 '빌드 시간'에 사용자를 보호하는 작업입니다. 즉, 예상치 못한 피해를 줄이는 보호 장치를 추가합니다. 이들은 모두 페이지를 제공할 때 제공할 수 있는 새로운 HTTP 헤더이며, 사용자 에이전트에 특정 개인 정보 보호 또는 보안 입장을 취하도록 힌트를 주거나 지시할 수 있습니다.

리퍼러 정책

권장사항

strict-origin-when-cross-origin 또는 noreferrer 정책을 설정하여 다른 사이트에 연결하거나 페이지에서 하위 리소스로 로드할 때 다른 사이트가 리퍼러 헤더를 수신하지 못하도록 합니다.

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

또는 서버 측(예: Express의 경우)

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

필요한 경우 특정 요소 또는 요청에 대해 완만한 정책을 설정합니다.

사용자 개인 정보가 보호되는 이유

기본적으로 브라우저에서 전송하는 각 HTTP 요청은 링크, 삽입된 이미지, 스크립트와 같은 요청을 시작하는 페이지의 URL이 포함된 Referer 헤더를 전달합니다. 이는 개인 정보 보호 문제일 수 있습니다. URL에는 개인 정보가 포함될 수 있고 이러한 URL은 서드 파티가 사용할 수 있는 개인 정보가 서드 파티에 전달되기 때문입니다. Web.dev에서는 비공개 데이터가 포함된 URL의 몇 가지 예를 표시합니다. 사용자가 https://social.example.com/user/me@example.com에서 내 사이트를 방문했다는 사실을 알고 있으면 이 사용자가 누구인지 알 수 있으며, 이는 확실한 유출입니다. 하지만 개인 정보를 노출하지 않는 URL도 이 특정 사용자 (사용자가 로그인한 경우 사용자가 알 수도 있는 사용자)가 다른 사이트를 통해 방문했다는 것을 노출하므로 이 사용자가 다른 사이트를 방문했음을 알 수 있습니다. 이는 그 자체로 사용자의 방문 기록에 대해 몰랐을 수 있는 정보의 노출입니다.

올바른 철자로 Referrer-Policy 헤더를 제공하면 이를 변경하여 참조 URL의 일부 또는 전부가 전달되지 않도록 할 수 있습니다. MDN은 전체 세부정보를 나열하지만 대부분의 브라우저는 이제 가정된 strict-origin-when-cross-origin 값을 기본으로 채택했습니다. 즉, 리퍼러 URL이 이제 서드 파티에 출처 (https://web.dev/learn/privacy이 아닌 https://web.dev)로만 전달됩니다. 이는 별도의 조치를 취할 필요 없이 유용한 개인 정보 보호 기능입니다. 하지만 리퍼러 정보를 서드 파티에 전달하지 않도록 (또는 자체 출처를 포함하여 누구에게도 전달되지 않도록 하려면 Referrer-Policy: no-referrer)하여 이 문제를 한층 더 강화할 수 있습니다.Referrer-Policy: same-origin (이는 개인 정보 보호와 유용성의 균형을 보여주는 좋은 예입니다. 새로운 기본값은 이전보다 개인 정보를 훨씬 더 안전하게 보호하지만, 여전히 분석 제공업체와 같이 사용자가 선택한 서드 파티에게 개략적인 정보를 제공합니다.)

이 헤더를 명시적으로 지정하는 것도 브라우저 기본값에 의존하지 않고 정책이 무엇인지 정확하게 알 수 있기 때문에 유용합니다. 헤더를 설정할 수 없다면 <head>(<meta name="referrer" content="same-origin">)의 메타 요소를 사용하여 전체 HTML 페이지의 리퍼러 정책을 설정할 수 있습니다. 특정 서드 파티가 우려되는 경우 <script>, <a> 또는 <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">와 같은 개별 요소에 referrerpolicy 속성을 설정할 수도 있습니다.

콘텐츠 보안 정책

'CSP'라고도 하는 Content-Security-Policy 헤더는 외부 리소스를 로드할 수 있는 위치를 지정합니다. 이 API는 주로 교차 사이트 스크립팅 공격 및 스크립트 삽입을 방지하여 보안 목적으로 사용되지만 일반 감사와 함께 사용할 경우 선택한 서드 파티가 데이터를 전달할 수 있는 위치를 제한할 수도 있습니다.

이는 사용자 환경이 저하될 수 있습니다. 서드 파티 스크립트 중 하나가 목록에 없는 출처에서 종속 항목을 로드하기 시작하면 요청이 차단되고 스크립트가 실패하며 애플리케이션이 이와 함께 실패할 수 있습니다(또는 JavaScript 실패 대체 버전으로 축소될 수 있음). 이는 교차 사이트 스크립팅 문제로부터 보호하는 일반적인 목적인 보안을 위해 CSP를 구현할 때 유용합니다. 이를 위해서는 엄격한 CSP를 사용해야 합니다. 페이지에서 사용하는 모든 인라인 스크립트를 알게 되면 스크립트 목록을 만들고 해시 값을 계산하거나 각각에 임의의 값('nonce'라고 함)을 추가한 다음 해시 목록을 콘텐츠 보안 정책에 추가할 수 있습니다. 이렇게 하면 목록에 없는 스크립트가 로드되지 않습니다. 이는 사이트의 프로덕션 프로세스에 포함되어야 합니다. 페이지의 스크립트에 nonce를 포함하거나 빌드의 일부로 계산된 해시가 있어야 합니다. 자세한 내용은 strict-csp 도움말을 참조하세요.

다행히 브라우저에서는 관련 헤더 Content-Security-Policy-Report-Only를 지원합니다. 이 헤더가 제공되면 제공된 정책을 위반하는 요청은 차단되지 않지만 JSON 보고서가 제공된 URL로 전송됩니다. 이러한 헤더는 Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/와 같고, 브라우저가 3p.example.com 이외의 모든 위치에서 스크립트를 로드하면 요청은 성공하지만 보고서는 제공된 report-uri로 전송됩니다. 일반적으로는 정책을 구현하기 전에 정책을 실험하는 데 사용되지만 여기에서는 '지속적인 감사'를 수행하는 방법으로 이를 사용하는 것이 좋습니다. 앞에서 설명한 정기 감사 외에도 CSP 보고를 사용 설정하여 예상치 못한 도메인이 나타나는지 확인할 수 있습니다. 이는 서드 파티 리소스가 자체 서드 파티 리소스를 로드하고 있다는 의미이며 이를 고려하고 평가해야 함을 의미할 수 있습니다. (물론 일부 크로스 사이트 스크립팅 악용이 보안 경계를 넘어섰다는 징후일 수도 있으며, 이 또한 알아두는 것이 중요합니다.)

Content-Security-Policy는 사용하기에 복잡하고 까다로운 API입니다. 이는 이미 알려져 있으며, 동일한 목표를 달성하지만 사용하기는 복잡하지 않은 '차세대' CSP를 구축하기 위한 작업이 진행 중입니다.아직 준비되지 않았지만, 향후의 방향을 확인하거나 설계에 참여하고 싶다면 https://github.com/WICG/csp-next에서 자세한 내용을 확인하세요.

권장사항

제공되는 페이지에 Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control HTTP 헤더를 추가합니다. JSON이 해당 URL에 게시되면 저장합니다. 저장된 데이터를 검토하여 다른 사용자가 내 웹사이트를 방문할 때 요청하는 서드 파티 도메인 모음을 가져옵니다. 예상한 도메인이 나열되도록 Content-Security-Policy-Report-Only 헤더를 업데이트하여 목록이 변경되는 시점을 확인합니다.

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

이유

이는 지속적인 기술 감사 과정의 일부입니다. 최초 기술 감사에서는 사이트에서 사용자 데이터를 공유하거나 전달하는 서드 파티 목록을 제공합니다. 그러면 이 헤더를 통해 페이지 요청이 현재 어떤 서드 파티에 연결되고 있는지 다시 보고하며, 개발자는 시간 경과에 따른 변경사항을 추적할 수 있습니다. 이를 통해 기존 제3자의 변경사항을 알릴 뿐만 아니라 기술 감사에 추가되지 않은 새로 추가된 제3자에 대한 플래그도 표시됩니다. 예상한 도메인에 대한 보고를 중단하도록 헤더를 업데이트하는 것도 중요하지만 경우에 따라 수동 기술 감사를 반복하는 것도 중요합니다. Content-Security-Policy 접근 방식은 전달된 데이터가 아니라 요청이 전송되었다는 플래그만 지정하기 때문입니다.

게재될 때마다 또는 모든 페이지에 추가할 필요는 없습니다. 헤더가 많은 페이지 응답에서 발생하는 페이지 응답을 낮춰 충분한 양의 보고서 샘플을 받을 수 있습니다.

권한 정책

Permissions-Policy 헤더 (Feature-Policy라는 이름으로 도입됨)는 개념상 Content-Security-Policy와 비슷하지만 강력한 브라우저 기능에 대한 액세스를 제한합니다. 예를 들어 가속도계나 카메라, USB 기기와 같은 기기 하드웨어의 사용을 제한하거나 전체 화면으로 전환하거나 동기식 XMLHTTPRequest를 사용할 수 있는 권한과 같은 하드웨어가 아닌 기능을 제한할 수 있습니다. 이러한 제한은 로드된 스크립트에서 이러한 기능을 사용하지 못하도록 하기 위해 최상위 수준 페이지 또는 iframe을 통해 로드된 서브프레임 페이지에 적용될 수 있습니다. 이러한 API 사용 제한은 실제로 브라우저 디지털 지문 수집에 관한 것이 아니며, 서드 파티가 방해가 되는 작업 (예: 강력한 API 사용, 권한 창 팝업)을 하지 못하도록 금지하는 것입니다. 이는 타겟 개인 정보 보호 위협 모델에서 '침입'으로 정의됩니다.

Permissions-Policy 헤더는 (기능, 허용된 출처) 쌍의 목록으로 지정됩니다.

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

이 예에서는 이 페이지 ('self')와 출처 example.com의 <iframe>가 JavaScript의 navigator.geolocation API를 사용할 수 있습니다. 이 페이지를 통해 이 페이지와 모든 하위 프레임이 전체 화면 API를 사용할 수 있으며, 이 페이지를 포함한 모든 페이지에서 카메라를 사용하여 동영상 정보를 읽을 수 없습니다. 여기에서 훨씬 더 자세한 내용과 가능한 예 목록을 확인할 수 있습니다.

Permissions-Policy 헤더에서 처리하는 기능 목록은 방대하며 바뀔 수 있습니다. 현재 목록은 https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md에서 유지됩니다.

도움말: Content-Security-Policy 값은 세미콜론으로 구분되지만 Permissions-Policy 값은 쉼표로 구분되고 Permissions-Policy 값은 대괄호로 묶여 있습니다. 세부정보는 권한 정책 설명에 명시되어 있습니다.

권장사항

Permissions-Policy를 지원하는 브라우저는 기본적으로 서브프레임의 강력한 기능을 허용하지 않으므로 이러한 기능을 사용 설정하려면 사용자가 조치를 취해야 합니다. 이 접근 방식은 기본적으로 비공개입니다. 사이트의 하위 프레임에 이러한 권한이 필요한 경우 선택적으로 해당 권한을 추가할 수 있습니다. 그러나 기본 페이지에 기본적으로 적용되는 권한 정책이 없으므로 기본 페이지에서 로드되는 스크립트 (서드 파티 스크립트 포함)는 이러한 기능을 사용하려고 하는 데 제한되지 않습니다. 이러한 이유로 기본적으로 모든 페이지에 제한적인 Permissions-Policy를 적용한 후 페이지에 필요한 기능을 점진적으로 다시 추가하는 것이 유용합니다.

Permissions-Policy가 영향을 미치는 강력한 기능의 예로는 사용자 위치 요청, 센서 (가속도계, 자이로스코프, 자기계 등), 전체 화면 사용 권한 요청, 사용자의 카메라 및 마이크 액세스 권한 요청 등이 있습니다. (변경) 전체 기능 목록은 위에 링크되어 있습니다.

안타깝게도 기본적으로 모든 기능을 차단한 다음 선택적으로 다시 허용하려면 모든 기능을 헤더에 나열해야 하므로 다소 부자연스럽게 느껴질 수 있습니다. 그럼에도 불구하고 이러한 Permissions-Policy 헤더부터 시작하는 것이 좋습니다. permissionspolicy.com/에는 이러한 헤더를 생성할 수 있는 편리한 클릭 가능한 생성기가 있습니다. 이 생성기를 사용하여 모든 기능을 사용 중지하는 헤더를 만들면 다음과 같은 결과가 발생합니다.

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

웹브라우저에서 기본 제공되는 개인 정보 보호 기능 이해

'빌드 시간' 및 '설계 시간' 보호 외에도 '런타임'에 적용되는 개인 정보 보호 기능이 있습니다. 즉, 사용자를 보호하기 위해 브라우저 자체에서 개인 정보 보호 기능이 구현됩니다. 이러한 기능은 사이트 개발자가 직접 제어하거나 활용할 수 있는 기능이 아니며 제품 기능입니다. 그러나 사이트가 브라우저에서 이러한 제품 관련 결정에 영향을 받을 수 있으므로 꼭 알아두어야 하는 기능입니다. 이러한 브라우저 보호 기능이 사이트에 미치는 영향을 예를 들어 설명하자면, 페이지 설정을 계속하기 전에 서드 파티 종속 항목이 로드될 때까지 기다리는 클라이언트 측 자바스크립트가 있고 해당 서드 파티 종속 항목이 전혀 로드되지 않는 경우 페이지 설정이 완료되지 않을 수 있으므로 사용자에게 절반만 로드된 페이지가 표시됩니다.

여기에는 Safari의 지능형 추적 방지(및 기본 WebKit 엔진), Firefox의 향상된 추적 보호 (및 해당 엔진인 Gecko)가 포함됩니다. 이로 인해 제3자가 사용자의 상세 프로필을 작성하기가 어려워집니다.

개인 정보 보호 기능에 관한 브라우저 접근 방식은 자주 변경되므로 최신 상태를 유지하는 것이 중요합니다. 다음 보호 조치 목록은 작성 시점에 올바른 것입니다. 브라우저는 다른 보호 기능을 구현할 수도 있습니다. 이 목록은 일부일 뿐 전체 목록이 아닙니다. 변경사항을 놓치지 않고 확인하는 방법은 권장사항 모듈을 참고하고 프로젝트에 영향을 줄 수 있는 변경사항은 향후 브라우저 버전으로 테스트해야 합니다. 시크릿/시크릿 브라우징 모드는 브라우저의 기본값과 다른 설정을 구현하는 경우가 있습니다 (예: 이러한 모드에서는 서드 파티 쿠키가 기본적으로 차단될 수 있음). 따라서 시크릿 브라우징을 사용하지 않는 경우 시크릿 모드에서 테스트해도 대부분의 사용자의 일반적인 탐색 환경이 반영되지 않을 수도 있습니다. 또한 다양한 상황에서 쿠키를 차단하면 쿠키뿐만 아니라 window.localStorage와 같은 다른 스토리지 솔루션도 차단될 수 있습니다.

Chrome

서드 파티 쿠키는 향후 차단될 예정입니다. 이 문서의 작성 시점을 기준으로 기본적으로 차단되지는 않습니다(단, 사용자가 이 기능을 사용 설정할 수 있음). 자세한 내용은 https://support.google.com/chrome/answer/95647을 참조하세요.
Chrome의 개인 정보 보호 기능, 특히 Google 및 서드 파티 서비스와 통신하는 Chrome의 기능은 privacysandbox.com/에 설명되어 있습니다.

에지

서드 파티 쿠키는 기본적으로 차단되지 않지만 사용자가 사용 설정할 수 있습니다.
Edge의 추적 방지 기능은 방문하지 않은 사이트의 추적기를 차단하며 알려진 유해한 추적기는 기본적으로 차단됩니다.

Firefox

서드 파티 쿠키는 기본적으로 차단되지 않지만 사용자가 사용 설정할 수 있습니다.
Firefox의 향상된 추적 보호는 추적 쿠키, 디지털 지문 수집 스크립트, cryptominer 스크립트, 알려진 추적기를 기본적으로 차단합니다. (https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track에서 자세한 내용을 확인하세요).
서드 파티 쿠키의 경우 사이트 제한이 있으므로 각 사이트는 기본적으로 별도의 쿠키 jar를 포함하고 있으며 사이트 간 상호 연결될 수 없습니다 (Mozilla에서는 이를 '전체 쿠키 보호'라고 합니다.

차단되는 항목에 관한 정보를 확인하고 문제를 디버그하려면 주소 표시줄의 방패 아이콘을 클릭하거나 데스크톱의 Firefox에서 about:protections 페이지를 방문하세요.

Safari

서드 파티 쿠키는 기본적으로 차단됩니다.
지능형 추적 방지 기능의 일부로 Safari는 다른 페이지로 전달되는 리퍼러를 특정 페이지가 아닌 최상위 사이트(https://something.example.com/this/specific/page가 아닌 https://something.example.com)로 줄입니다.
브라우저 localStorage 데이터는 7일 후에 삭제됩니다.

(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/에 이러한 기능이 요약되어 있습니다.)

차단되는 항목에 관한 정보를 얻고 문제를 디버그하려면 Safari 개발자 메뉴 (데스크톱)에서 '지능형 추적 방지 디버그 모드'를 사용 설정하세요. 자세한 내용은 https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/을 참고하세요.

API 제안

새 API가 필요한 이유는 무엇인가요?

브라우저 제품의 새로운 개인 정보 보호 기능과 정책은 사용자 개인 정보를 보호하는 데 도움이 되지만, 문제도 수반됩니다. 많은 웹 기술이 다른 목적으로 설계되고 사용되고 있음에도 불구하고 크로스 사이트 추적에 사용할 수 있습니다. 예를 들어 Google에서 매일 사용하는 많은 ID 제휴 시스템은 서드 파티 쿠키를 사용합니다. 오늘날 게시자가 수익을 얻기 위해 의존하는 수많은 광고 솔루션은 서드 파티 쿠키를 기반으로 구축되었습니다. 많은 사기 감지 솔루션이 디지털 지문 수집을 활용합니다. 서드 파티 쿠키와 디지털 지문 수집이 사라지면 이러한 사용 사례는 어떻게 되나요?

브라우저에서 사용 사례를 구분하고 개인 정보 보호 위반 용도를 다른 사용 사례와 확실하게 구분하기가 어렵고 오류가 발생하기 쉽습니다. 따라서 대부분의 주요 브라우저에서 사용자 개인 정보 보호를 위해 서드 파티 쿠키와 디지털 지문 수집을 차단했거나 그러한 의도를 갖고 있습니다.

새로운 접근 방식이 필요합니다. 서드 파티 쿠키가 단계적으로 지원 중단되고 디지털 지문 수집이 완화됨에 따라 개발자는 사용 사례를 충족하지만 개인 정보를 보호하는 방식으로 설계된 전용 API가 필요합니다. 목표는 크로스 사이트 추적에 사용할 수 없는 API를 설계하고 빌드하는 것입니다. 이전 섹션에서 설명한 브라우저 기능과 달리 이러한 기술은 교차 브라우저 API가 되고자 합니다.

API 제안의 예

다음 목록은 전체 목록이 아니며 논의 중인 일부 내용일 뿐입니다.

서드 파티 쿠키에 구축된 기술을 대체하기 위한 API 제안의 예는 다음과 같습니다.

ID 사용 사례: FedCM
광고 사용 사례: 비공개 클릭 측정, 상호 운용 가능한 비공개 기여 분석, 기여도 보고, Topics, FLEDGE, PARAKEET

수동 추적에 기반한 기술을 대체하기 위한 API 제안의 예는 다음과 같습니다.

사기 감지 사용 사례: 신뢰 토큰.

서드 파티 쿠키 없이 향후 다른 API가 활용할 수 있는 기타 제안의 예는 다음과 같습니다.

Storage Access API

또한 브라우저별 은밀한 추적 완화를 시도하기 위한 또 다른 유형의 API 제안이 등장하고 있습니다. 한 가지 예는 개인 정보 보호 예산입니다. 다양한 사용 사례에서 Chrome에서 처음 제안한 API는 개인 정보 보호 샌드박스라는 상위 용어로 제공됩니다.

Global-Privacy-Control은 수집된 개인 정보를 다른 사이트와 공유하지 않겠다고 사용자가 사이트에 알리는 데 사용하는 헤더입니다. 목적은 중단된 '추적 안함' 앱과 비슷합니다.

API 제안 상태

이러한 API 제안의 대부분은 아직 배포되지 않았거나, 플래그 뒤에 또는 실험용으로 제한된 환경에서만 배포됩니다.

이러한 공개 인큐베이션 단계는 중요합니다. 브라우저 공급업체와 개발자가 API가 유용한지, 실제로 API가 설계한 목적을 실제로 수행하는지에 관한 토론과 경험을 수집합니다. 개발자, 브라우저 공급업체, 기타 생태계 행위자는 이 단계를 사용하여 API 설계를 반복합니다.

현재 제안된 새로운 API에 관한 최신 정보는 개인 정보 보호 그룹의 GitHub 제안 목록에서 확인하실 수 있습니다.

이러한 API를 사용해야 하나요?

디지털 지문 수집과 같은 서드 파티 쿠키 또는 기술을 기반으로 제품을 직접 빌드한 경우 이러한 새 API를 사용하고 실험한 후 자체 경험을 논의하고 API 설계에 기여해야 합니다. 그 밖의 모든 경우에는 이 글을 작성하는 시점에 이러한 새 API에 관한 모든 세부정보를 알 필요는 없지만 예정된 내용을 숙지하고 있으면 좋습니다.