서드 파티란 무엇인가요?
완전히 독립된 웹사이트는 거의 없습니다. HTTP Web Almanac에 따르면 대부분의 웹사이트(약 95%)에 서드 파티 콘텐츠가 포함되어 있습니다.
연감에서는 서드 파티 콘텐츠를 공유 및 공개 출처에서 호스팅되는 콘텐츠로 정의하며, 이는 다양한 업계에서 널리 사용됩니다. 개별 사이트 소유자의 영향을 받지 않는 사이트가 표시됩니다 이러한 미디어는 이미지, 동영상, 글꼴, 스크립트 등의 기타 미디어일 수 있습니다. 이미지와 스크립트는 합쳐서 다른 모든 것을 합친 것보다 더 많은 것을 차지합니다. 제3자 콘텐츠는 사이트 개발에 꼭 필요하지는 않지만 그렇게 될 수도 있습니다. 웹 글꼴, 웹 글꼴, 웹 브라우저 등에서 로드한 것을 동영상, 광고 또는 JavaScript 라이브러리의 삽입된 iframe 예를 들어 Google Fonts에서 제공하는 웹 글꼴을 사용 중이라면 또는 Google 애널리틱스로 분석을 측정하려는 경우 소셜 네트워크의 '좋아요' 버튼이나 '다음으로 로그인' 버튼을 추가했을 수 있습니다. 지도 또는 동영상을 삽입하거나 제3자 서비스를 통해 쇼핑 구매를 처리할 수 있습니다. 오류를 추적하고 있을 수 있으며 서드 파티 모니터링 도구를 통해 자체 개발팀을 로깅할 수 있습니다.
개인 정보 보호를 위해 약간 다르지만 덜 광범위한 정의인 제3자 리소스 및 공유된 공개 출처에서 제공되며, 삽화처럼 널리 사용되고 있지만, 사이트 소유자가 아닌 다른 사람이 보게 됩니다. 제3자 저작권의 측면은 콘텐츠 보호 방법을 고려할 때 중요한 요소입니다. 사용자 다른 사람의 개인 정보 보호 이를 통해 어떤 위험이 있는지 고려한 다음, 경보 시스템을 사용할 방법 또는 서드 파티 리소스와 협력해야 합니다 이미 논의한 것처럼, 이러한 것들은 맥락을 이해하고 어떤 장단점을, 그들이 무엇을 의미하는지 이해하는 것이 중요합니다.
이는 '제3자 리소스'를 언급할 때의 의미가 아닙니다. 일반적으로 퍼스트 파티 데이터와 퍼스트 파티 쿠키의 어떤 것이 사용되는 맥락에 관한 것입니다. 다른 웹사이트에서 로드된 스크립트가 서드 파티입니다. 리소스를 포함하고 스크립트를 로드하는 HTTP 요청에 쿠키가 포함될 수 있지만, 이러한 쿠키는 실제로는 "제3자 쿠키"가 아닙니다. 쿠키일 뿐이며 '서드 파티' 쿠키도 또는 '퍼스트 파티' 스크립트가 스크립트 소유자 사이트의 페이지 또는 스크립트 소유자 사이트의 페이지입니다.
서드 파티 리소스를 사용하는 이유는 무엇인가요?
타사를 통해 사이트에 기능을 추가할 수 있습니다. 사용자에게 노출되거나 표시되지 않는 기능일 수 있습니다. 개발 부하를 줄여주고 스크립트 자체는 유지관리됩니다. 포함된 서비스의 개발팀입니다. 이 모든 것이 가능한 이유는 다음과 같이 웹을 구성할 수 있기 때문입니다. 여러 부분을 결합하여 그 합보다 큰 전체를 형성할 수 있다는 것을 의미합니다.
HTTP 아카이브의 웹 연감에 이에 대한 자세한 설명이 나와 있습니다.
서드 파티는 끊임없이 제공되는 이미지, 동영상, 글꼴, 도구, 라이브러리, 위젯, 추적기, 광고 등 웹페이지에 삽입할 수 있는 모든 것이 포함됩니다. 이렇게 하면 가장 비기술적으로도 웹에 콘텐츠를 만들고 게시할 수 있습니다. 서드 파티가 없다면 웹은 삶에 필수적인 풍부하고 몰입감 있으며 복잡한 플랫폼이 아닌 매우 지루하고 텍스트 기반의 학술적인 매체여야 합니다. 하고 있습니다.
서드 파티 리소스로 무엇을 할 수 있나요?
일부 정보 액세스
웹사이트에서 서드 파티 리소스를 사용하면 그 내용에 관계없이 일부 정보가 서드 파티에 전달됩니다. 예를 들어 다른 사이트의 이미지를 포함하는 경우 사용자의 브라우저에서 보내는 HTTP 요청은 리퍼러와 함께 전달됩니다. 헤더를 페이지 URL과 사용자의 IP 주소로 바꿉니다.
크로스 사이트 추적
동일한 예를 계속 들겠습니다. 제3자 사이트에서 이미지가 로드되는 경우 쿠키를 포함할 수 있으며 이 쿠키는 사용자가 다음에 해당 이미지를 요청하면 서드 파티로 다시 전송됩니다. 이는 서드 파티가 서비스가 사이트에서 사용되고 있으며, 잠재적으로 해당 사용자의 고유 ID와 함께 쿠키를 반환할 수 있습니다. 즉, 사용자가 다음에 내 사이트 또는 타사의 리소스가 포함된 다른 사이트를 방문할 때 고유하며 ID 쿠키가 다시 전송됩니다. 이렇게 하면 서드 파티가 해당 사용자가 방문하는 위치(예: 귀하의 사이트, 사용자가 방문한 다른 사이트)에 대한 로그를 웹 전체에서 동일한 제3자 리소스를 사용할 수 있습니다.
크로스 사이트 추적입니다. 이를 통해 서드 파티가 여러 웹사이트에서 사용자 활동 로그를 수집할 수 있습니다. 모든 웹사이트는 동일한 서드 파티의 리소스를 사용합니다. 정적 리소스인 글꼴, 이미지, 스타일 시트 등을 사용할 수 있습니다. 스크립트, 소셜 미디어 버튼, 광고와 같은 동적 리소스일 수도 있습니다. 포함된 스크립트를 통해 정보는 동적이기 때문에 사용자의 브라우저와 환경을 검사하고 해당 데이터를 작성자로 다시 전달할 수 있습니다. 스크립트로 표시되지 않는 동적 리소스(예: 소셜 미디어 삽입 또는 공유할 수 있습니다. 유명 웹사이트에서 쿠키 배너의 세부정보를 보면 를 통해 사용자의 활동 사진을 생성하여 해당 사용자의 프로필을 만들 수 있습니다. 거기 수백 개일 수 있습니다. 제3자가 무료로 서비스를 제공하는 경우 제3자가 경제적으로 이를 수행할 수 있는 한 가지 방법은 이 데이터를 수집하여 수익을 창출하기 때문입니다.
브라우저가 사용자를 보호해야 하는 개인 정보 보호 문제 유형에 관한 유용한 가이드는 타겟 개인 정보 보호 위협 모델입니다. 이 문서는 이 문서의 작성 시점에서 아직 논의되고 있지만 발생할 수 있습니다. 제3자 리소스의 위험은 주로 "원치 않는 크로스 사이트 인식"이며, 여기서 여러 사이트에서 동일한 사용자를 식별할 수 있는 웹사이트 및 사이트에서 정보를 수집할 수 있는 '민감한 정보 공개' 사용자가 민감하다고 생각하는 정보
이것이 주요 차이점입니다. 원치 않는 크로스 사이트 인식은 제3자가 민감한 정보를 추가로 수집하지 않더라도 나빠집니다. 개인 정보를 삭제할 수 없습니다. 사용자의 리퍼러 및 IP 주소에 대한 액세스 권한 얻기 쿠키 그 자체로 원치 않는 공개입니다. 서드 파티 리소스를 사용하면 사용 방법에 대한 계획 구성요소가 수반됩니다. 개인 정보를 보호하는 방식으로 보관하고 있습니다 작업 중 일부는 사이트 개발자가 맡고, 일부는 브라우저에 의해 수행됩니다. 사용자 에이전트 역할을 하며 즉, 민감한 정보가 공개되는 것을 방지하기 위해 사용자를 대신하여 작업하고 크로스 사이트 인식을 방지하세요 아래에서 브라우저의 취약점 완화 방법과 접근 방식을 자세히 살펴보겠습니다. 선택할 수 있습니다.
서버 측 서드 파티 코드
서드 파티에 대한 이전의 정의는 HTTP Almanac의 다소 클라이언트 측 접근 방식을 의도적으로 변경했습니다 (해당하는 경우). 제3자의 소유권을 포함시켜야 합니다. 왜냐하면 개인 정보 보호 관점에서 제3자는 무엇이든지 아는 사람이기 때문입니다. 정보를 얻을 수 있습니다
여기에는 서버에서 사용하는 서비스를 제공하는 제3자뿐 아니라 클라이언트도 포함됩니다. 개인 정보 보호 콘텐츠 서드 파티 라이브러리 (예: NPM, Composer 또는 NuGet에 포함된 라이브러리)도 이해하는 것이 중요합니다. 종속 항목이 데이터를 경계 외부로 전달하나요? 로깅 서비스나 원격 호스팅 데이터베이스로 데이터를 전달하는 경우 '휴대전화 홈'도 포함하는 라이브러리가 이러한 콘텐츠는 사용자의 저작권 개인 정보 보호 감사가 필요합니다 서버 기반의 서드 파티는 일반적으로 여러분이 사용자 데이터를 제공해야 합니다. 그것이 노출되는 데이터를 더 잘 제어할 수 있다는 것을 의미합니다. 반면에 클라이언트 기반의 서드 파티인 스크립트 또는 HTTP 리소스는 가져온 웹 기반 페이지는 해당 프로세스 없이 사용자로부터 직접 일부 데이터를 수집할 수 있습니다. 영향을 줄 수 있습니다 이 모듈의 대부분은 이러한 클라이언트 측 서드 파티를 식별하는 방법과 관련이 있습니다. 광고를 포함시키고 노출하기로 선택한 경우, 이는 가능한 미디에이션이 거의 없기 때문입니다. 그만한 가치가 있음 서버 측 코드의 보안을 고려하여 해당 코드로부터의 아웃바운드 통신을 이해하고 있습니다. 정확한 방법에 대한 자세한 내용은 여기에서 다루지 않으며 서버 설정에 따라 크게 달라집니다. 이는 보안 및 개인 정보 보호 입장의 또 다른 부분입니다.
제3자 파트너에게 주의해야 하는 이유는 무엇인가요?
서드 파티 스크립트와 기능은 매우 중요하며, 웹 개발자로서 우리의 목표는 그러한 것들을 통합하는 것입니다. 그들에게서 등을 돌리면 안 돼요! 하지만 잠재적인 문제가 있습니다. 서드 파티 콘텐츠는 성능 문제를 일으킬 수 있으며 신뢰 경계 내부에서 외부 서비스를 가져오기 때문에 보안 문제가 발생합니다. 하지만 서드 파티는 콘텐츠가 개인 정보 보호 문제를 일으킬 수도 있습니다.
웹에서 타사 리소스에 대해 이야기할 때, 무엇보다도 보안 문제라고 생각하면 도움이 됩니다. 제3자가 회사로부터 데이터를 훔칠 수 있는 상황과 개인 정보 보호 문제와 대조를 이룹니다. 포함된 서드 파티가 사용자의 액세스 권한을 도용하거나 데이터를 수집할 수 없습니다.
보안 문제의 예로는 '웹 스키머'가 있습니다. 개인 정보를 도용하는 등 신용카드 정보를 사용자가 신용카드 정보를 입력하는 페이지에서 신용카드 정보를 훔쳐서 악의적인 서드 파티로부터 보호할 수 있습니다. 이러한 스키머 스크립트를 만드는 사람은 스크립트를 숨길 위치를 매우 창의적으로 찾아냅니다. 요약에서는 스키머 스크립트가 어떻게 작동하는지 사이트 로고, 파비콘, 소셜 미디어 네트워크에 사용되는 이미지와 같은 서드 파티 콘텐츠에 숨겨진 콘텐츠 인기 있는 라이브러리(예: jQuery, Modernizr, Google 태그 관리자), 사이트 위젯(예: 실시간 채팅 창), CSS 파일 등이 있습니다.
개인 정보 보호 문제는 약간 다릅니다. 이러한 서드 파티는 혜택의 일부입니다. 사용자의 권한을 개발자는 사용자가 그들을 신뢰할 수 있다는 확신이 있어야 합니다. 사용하는 서드 파티가 오용하거나, 삭제하거나 발견하기 어렵게 만들거나, 정보 유출을 겪거나, 그러면 사용자는 이를 단순한 신뢰가 아닌 개발자의 서비스에 대한 신뢰가 있습니다. 그것은 나의 평판과 관계입니다. 그렇기 때문에 스스로에게 질문해 보는 것이 중요합니다. 어떻게 해야 할까요?
제3자 파트너의 예로는 어떤 것이 있나요?
이 세션에서는 일반적으로 다양하지만 실제로는 다양한 종류가 있으며 액세스하는 사용자 데이터의 양도 다릅니다.
예를 들어 다른 서버에서 로드된 <img> 요소를 HTML에 추가하면 서버에 다른 정보가 제공됩니다.
<iframe> 또는 <script> 요소를 추가하는 것보다 더 효율적입니다. 이는 전체 목록이라기보다는 예시일 뿐이며
사이트에서 사용할 수 있는 다양한 유형의 제3자 항목 간의 차이를 이해하는 데 도움이 됩니다.
크로스 사이트 리소스 요청
크로스 사이트 리소스는 <iframe>나 <script>이 아닌 다른 사이트에서 로드된 사이트의 모든 항목입니다. 예
<img>, <audio>, <video>, CSS에 의해 로드된 웹 글꼴, WebGL 텍스처가 포함됩니다. 이들은 모두 HTTP 요청을 통해 로드되며
앞서 설명한 것처럼 이러한 HTTP 요청에는 다른 사이트에서 이전에 설정한 모든 쿠키, 요청하는 사용자의 IP 주소
현재 페이지의 URL을 리퍼러로 사용합니다. 모든 서드 파티 요청에는 지금까지 이 데이터가 기본적으로 포함되어 있었지만
'Google
서드 파티 브라우저 보호' 더 설명하겠습니다.
교차 사이트 iframe 삽입
<iframe>를 통해 페이지에 삽입된 전체 문서는 trifecta 외에도 브라우저 API에 대한 추가 액세스를 요청할 수 있습니다.
쿠키, IP 주소 및 리퍼러의 세부정보를 확인할 수 있습니다. <iframe> 페이지에서 사용할 수 있는 API와 이러한 API에서 액세스를 요청하는 방법은 브라우저에 따라 다릅니다.
현재 변경 중입니다. '권한 정책'을 참고하세요. 포함된 API 액세스를 줄이거나 모니터링하기 위해 현재 진행 중인 노력을 확인하려면
문서
크로스 사이트 JavaScript 실행
<script> 요소를 포함하면 페이지의 최상위 컨텍스트에서 크로스 사이트 JavaScript가 로드되고 실행됩니다. 즉,
퍼스트 파티 스크립트가 실행하는 모든 작업에 대한 완전한 액세스 권한을 가집니다. 브라우저 권한은 여전히 이 데이터를 관리하지만
따라서 사용자 위치를 요청하려면 여전히 사용자 동의가 필요합니다. 하지만 페이지에 있는 정보나
이러한 스크립트에서 자바스크립트 변수를 읽을 수 있으며, 여기에는 서드 파티로 전달되는 쿠키뿐만 아니라
사용자 사이트 전용 쿠키도 포함됩니다. 마찬가지로 서드 파티 스크립트가 Google 게시자 페이지에
페이지는 내 코드와 동일한 모든 HTTP 요청을 할 수 있습니다. 즉, 백엔드 API에 fetch() 요청을 하여 데이터를 가져올 수 있습니다.
종속 항목에 서드 파티 라이브러리 포함
앞서 설명한 것처럼 서버 측 코드에는 서드 파티 종속 항목도 포함될 수 있으며, 이러한 종속 항목은 개발자의 자체 종속 항목과 구별이 불가능합니다. 그 힘으로 코드를 사용합니다. GitHub 저장소 또는 프로그래밍 언어 라이브러리 (npm, PyPI, Composer 등)에서 가져온 코드 다른 코드가 읽을 수 있는 것과 동일한 데이터를 모두 읽을 수 있습니다.
서드 파티 파트너 파악
따라서 제3자 공급업체 목록과 그들의 개인정보 보호, 데이터 수집 및 사용자에 대한 이해가 필요합니다. 도움이 될 수 있습니다 그러면 그러한 이해가 얼마나 유용하고 중요한지에 대한 일련의 절충의 일부가 됩니다. 사용자에 대한 요구를 얼마나 거슬리고 불편하거나 조용히 하는지와 균형을 이룬 서비스입니다. 서드 파티 콘텐츠는 사이트 소유자가 해야 하는 어려운 작업을 대신 해주며 핵심 역량에 집중할 수 있도록 해 줍니다. 따라서 이러한 단점을 감수하고 일부 사용자 편안함과 개인 정보 보호를 희생하여 더 나은 사용자 경험을 제공하는 것은 가치가 있습니다. 하지만 사용자 환경과 개발자 환경을 혼동하지 않는 것이 중요합니다. "개발자 팀이 앱을 빌드하는 것이 서비스' 사용자에게 매력적인 스토리가 아닙니다.
이러한 이해를 얻는 방법은 감사 과정입니다.
서드 파티 감사
제3자가 수행하는 작업을 이해하는 것이 바로 감사 과정입니다. 기술적으로든 비기술적으로든 이 작업을 수행할 수 있습니다. 전체 컬렉션에 대해 설정할 수 있습니다
기술 외 감사 실행
첫 번째 단계는 비기술적입니다. 공급업체의 개인 정보 보호 정책을 읽어 보세요. 서드 파티 리소스를 포함하는 경우 개인정보처리방침을 확인하세요. 이 문서들은 길고 법률 문구로 가득하며, 일부 문서에서는 몇 가지 접근 방식을 사용할 수 있습니다. 이전 모듈에서 특별히 경고하지 않은 표현을 사용함 수집된 데이터의 삭제 방법 및 시기 사용자의 관점에서 보면 제3자를 포함하여 귀하의 사이트에서 수집된 정보는 본 개인정보처리방침의 적용을 받습니다. 사용자가 목표가 투명하고 사용자가 달성한 목표를 이해하지 못하면 데이터 개인 정보 보호에 대한 기대치 사용자가 선택한 제3자가 수행하는 모든 행위에 대해 책임을 물을 수 있습니다. 만약 그들의 개인 정보 보호 정책을 개인 정보 보호 정책에 언급하면 사용자의 신뢰하고 대체 공급업체가 있는지 고려합니다.
이는 나중에 논의되는 기술 감사와 함께 유용하게 사용할 수 있는 것으로, 있습니다. 비즈니스상의 이유로 통합 중인 서드 파티 리소스 (예: 광고 네트워크)를 알고 있어야 합니다. 또는 삽입된 콘텐츠 등은 포함되지 않도록 해야 합니다. 이 분야는 비기술적 있습니다. 또한 기술 감사에서는 제3자, 특히 기술보다는 서드 파티를 식별할 수 있습니다. 비즈니스 이유 (외부 구성요소, 분석, 유틸리티 라이브러리)보다 훨씬 크며, 해당 목록은 비즈니스 중심 서드 파티 파트너와 협업할 수 있습니다 여기서의 목표는 사이트 소유자가 사이트에서의 세 번째 요청 사항이 무엇인지 비즈니스 입장에서 법률 전문가의 자문을 구할 수 있고, 제3자 인벤토리를 통해 제3자 인벤토리를 통해 필요한 의무를 이행하고 있는지 확인합니다
기술 감사 실행
기술 감사를 위해서는 웹사이트의 일부로 해당 리소스를 사용하는 것이 중요합니다. 즉, 종속 항목을 로드하지 않고 그렇게 검사할 수 있습니다 종속 항목이 실제 웹사이트의 일부로 어떻게 작동하는지 확인하세요. '테스트' 또는 '개발' 모드가 아닌 공개 인터넷에 배포되는 것입니다 자신의 웹사이트를 신규 사용자 로그인하지 않고 계약을 저장하지 않도록 새 프로필에서 브라우저를 열고 사이트를 방문해 봅니다.
사용자 계정을 제공하는 경우 자신의 사이트에서 새 계정에 가입합니다. 디자인팀에서 이 신규 사용자를 조정합니다.
획득 프로세스를 설명하지만 개인 정보 보호 관점에서 접근하는 것이 도움이 될 수 있습니다. 단순히 클릭을 하지 마세요.
"동의" 이용약관, 쿠키 경고 또는 개인정보처리방침 자체 서비스를 사용하는 태스크 직접 설정
개인 정보를 공개하거나 추적 쿠키를 사용하지 않고, 그렇게 할 수 있는지, 그리고 그 것이 얼마나 어려운 일인지 확인할 수 있습니다.
또한 브라우저 개발자 도구를 확인하여 액세스 중인 사이트와 전송되는 데이터를 확인하는 것도 도움이 될 수 있습니다.
확인할 수 있습니다. 개발자 도구는 별도의 HTTP 요청 목록을 제공하며 (일반적으로 '네트워크'라는 섹션에 있음)
유형별로 그룹화된 요청 (HTML, CSS, 이미지, 글꼴, JavaScript, JavaScript에서 시작된 요청)입니다. 또한
각 요청의 도메인을 표시하는 새 열을 추가합니다.
이 열에는 몇 곳의 장소와 연락되고 있는지,
'서드 파티 요청'이 제3자만 표시합니다. Content-Security-Policy
감사를 실시해야 하며, 이에 대해서는 자세히 설명합니다.)
Simon Hearne의 'Request Map Generator' 도구를 이용하면 하위 요청을 처리합니다.
또한 이 시점에서 비기술 부문 감사의 일부로 확인된 비즈니스 중심적인 제3자 파트너를 포함할 수 있습니다. 즉, 자원을 사용하기 위해 재정적 관계가 있는 회사의 목록. 여기서 목표는 귀하가 사용한다고 생각되는 제3자 목록 (재무 및 법적 기록)과 실제로 사용 중인 제3자 목록을 일치시킬 수 있습니다. (웹사이트의 제3자 HTTP 요청 확인) 각 비즈니스에 대해 셋째, 기술적인 아웃바운드 요청을 하는 당사자를 의미합니다. 제3자에 대한 기술 감사에서 요청을 확인할 수 없는 경우 테스트를 수행할 때 그 이유를 파악하고 이에 따라 테스트를 진행하는 것이 중요합니다. 리소스가 특정 국가, 특정 기기 유형 또는 로그인한 사용자에 대해서만 로드되도록 할 수 있습니다. 이렇게 하면 감사하고 모든 아웃바운드 액세스가 있는지 확인하세요. (또는 서드 파티를 식별하여 비용만 지불하고 사용하지 않는 리소스를 모두 제공하므로 항상 재무 부서의 활력을 불어넣을 수 있습니다.)
감사에 참여하고자 하는 제3자에게 요청 목록의 범위를 좁힌 다음 개별 요청에는 모든 세부정보, 특히 해당 요청으로 전달된 데이터가 표시됩니다. 또한 코드가 시작한 서드 파티 요청이 다른 많은 서드 파티 요청을 시작하는 것이 일반적입니다. 이러한 추가 타사도 '가져옵니다'. 명시해야 합니다. 이 작업은 힘들지만 가치가 있으며 기존 분석에 삽입할 수도 있습니다. 프런트엔드 개발 팀은 이미 프런트엔드 개발 팀의 요청을 감사하고 있을 것입니다. 문제를 해결하고 성능을 개선하기 위해 데이터를 통합하고 개인 정보 보호 감사를 통해 이 프로세스를 더 쉽게 처리할 수 있습니다.
<ph type="x-smartling-placeholder">
권장사항
로그인하지 않고 저장된 동의 내용이 없도록 새 사용자 프로필로 브라우저를 엽니다. 그런 다음 브라우저를 엽니다 Network 패널에서 모든 발신 요청을 확인합니다. 각 요청의 도메인을 표시하는 새 열을 추가하고 '서드 파티 요청' 서드 파티가 있는 경우 체크박스를 선택합니다. 그런 다음 아래를 실행합니다.
- 사이트를 방문합니다.
- 사용자 계정을 제공하는 경우 새 계정에 가입합니다.
- 생성된 계정을 삭제해 보세요.
- 사이트에서 일반적인 작업을 한두 번 수행합니다. 정확히 그 결과는 사이트 작업에 따라 다르지만 대부분의 사용자가 수행하는 일반적인 작업을 선택합니다.
- 특히 서드 파티 종속 항목과 관련이 있는 것으로 알려진 작업을 한두 개 실행해 봅니다. 여기에는 다른 사용자와 소셜 미디어, 결제 절차 시작, 다른 사이트의 콘텐츠 삽입 등이 있습니다.
이러한 각 작업을 수행할 때 Network 패널을 확인하여 내 소유가 아닌 도메인에서 요청된 리소스의 기록을 만드세요. 변경할 수 있습니다. 다음은 귀하의 서드 파티 파트너입니다. 이렇게 하기 위한 좋은 방법은 브라우저 네트워크 도구를 사용하여 네트워크를 캡처하는 것입니다. HAR 파일에서 로그를 요청할 수 있습니다
HAR 파일 및 캡처
HAR 파일은 페이지에서 수행한 모든 네트워크 요청의 표준화된 JSON 형식입니다. 특정 페이지의 HAR 파일을 가져오는 방법은 다음과 같습니다.
Chrome
브라우저 DevTools를 열고 (메뉴 > 도구 더보기 > 개발자 도구) 네트워크 패널로 이동하여 페이지를 로드 (또는 새로고침)한 다음 오른쪽 상단의 제한 없음 드롭다운 메뉴 근처에 있는 아래쪽 화살표 저장 기호를 선택합니다.
Firefox
브라우저 개발자 도구 (메뉴 > 도구 더보기 > 웹 개발자 도구)를 열고 네트워크 패널로 이동하여 페이지를 로드 (또는 새로고침)한 다음 톱니바퀴 아이콘을 클릭합니다. 메뉴에서 Save All As HAR(모두 HAR로 저장)을 선택합니다.**
Safari
브라우저 개발자 도구를 엽니다 (메뉴 > 개발 > Web Inspector 표시). 개발 메뉴가 없는 경우 다음에서 사용 설정합니다. 메뉴 > Safari > 환경설정 > 고급 > 메뉴 바에서 개발 메뉴 표시를 선택한 경우 네트워크 패널로 이동하여 페이지를 로드 (또는 새로고침)합니다. 오른쪽 상단 (로그 보존 오른쪽)에서 내보내기를 선택합니다. 창을 확대해야 할 수도 있습니다.
제3자에게 전달되는 내용을 '요청' 섹션에도 기록할 수 있습니다. 단, 이러한 데이터는 난독화되어 있고 유용하게 해석할 수 없습니다.
서드 파티 통합 시 권장사항
사이트에서 사용하는 서드 파티에 대한 자체 정책을 설정할 수 있습니다. 즉, 관행에 따라 사용하는 광고 제공업체를 변경하거나, 쿠키 동의 팝업이 얼마나 성가시거나 방해가 되는지 또는 사이트에서 소셜 미디어 버튼을 사용할지 이메일의 추적 링크 또는 utm_campaign 링크를 사용하여 Google 애널리틱스에서 트윗을 추적합니다. 고려해야 할 한 가지 측면 사이트 개발은 분석 서비스의 개인 정보 보호 및 보안 상태입니다. 일부 분석 서비스는 명시적 보상 판매 개인 정보를 보호하고 있습니다. 자체적으로 개인 정보 보호 기능을 추가하는 서드 파티 스크립트를 사용하는 방법도 자주 있습니다. 사용자 경험을 개선하고자 하는 첫 번째 팀이 아닙니다. 제3자 데이터 수집으로부터 보호하며, 이미 해결책이 될 수 있습니다 마지막으로, 많은 서드 파티 제공업체가 과거보다 데이터 수집 문제에 더 민감하게 반응하고 있습니다. 또한 사용자 보호 모드를 사용 설정하는 기능이나 매개변수를 추가할 수도 있습니다. 다음은 몇 가지 예입니다.
소셜 미디어 공유 버튼을 추가하는 경우
HTML 버튼을 직접 삽입해 보세요. https://sharingbuttons.io/ 사이트에 잘 설계된 예가 있습니다. 또는 일반 HTML 링크를 추가할 수도 있습니다. 단점은 '공유 횟수'를 잃게 되고 통계를 파악하고 고객을 분류하여 확인할 수 있습니다 이는 서드 파티 제공업체를 이용하는 것과 더 적은 분석 데이터를 수신하는 것 사이의 절충안을 보여주는 예입니다.
좀 더 일반적으로, 서드 파티에서 제공하는 일종의 대화형 위젯을 삽입하는 경우 해당 서드 파티로 연결합니다. 이는 사이트에 인라인 환경이 없지만 공유에 대한 결정이 바뀌었음을 의미합니다. 이러한 데이터는 귀하가 원하는 방식으로 상호작용할지 여부를 선택할 수 있습니다.
예를 들어 다음과 같이 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!&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를 지원합니다. 이 API는 지정된 경우
동영상 또는 삽입된 콘텐츠로 연결되는 링크는 썸네일과 제목을 포함한 프로그래매틱 세부정보를 반환합니다. TikTok의 oEmbed 지원
(자세한 내용은 https://developers.tiktok.com/doc/embed-videos 참조)
다음 명령어를 사용하여 (수동 또는 프로그래매틱 방식으로) TikTok 동영상 링크(https://www.tiktok.com/@scout2015/video/6718335390845095173)를 동영상에 대한 JSON 메타데이터로 변환할 수 있습니다.
https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173, 따라서 썸네일을 검색
있습니다. WordPress는 주로 이를 사용하여 oEmbed를 요청합니다. 표시할 수 있습니다. 이를 프로그래매틱 방식으로 사용할 수 있습니다.
'파사드' 는 양방향 동영상으로 표시되며 사용자가 클릭하면 양방향 동영상으로 삽입되거나 연결되도록 전환됩니다.
분석 스크립트를 삽입할 때
애널리틱스는 사용자에 대한 정보를 수집하여 분석할 수 있도록 설계되었습니다. 애널리틱스 시스템은 기본적으로 Google 애널리틱스 같은 외부 서버에서 손쉽게 액세스 및 사용자에 대한 데이터를 수집하고 표시하는 서비스 구현해 보겠습니다. https://matomo.org/와 같은 자체 호스팅 애널리틱스 시스템도 있지만 서드 파티 솔루션을 사용하는 것이 좋습니다 하지만 자체 인프라에서 이러한 시스템을 실행하면 데이터 수집을 줄일 수 있습니다. 자체 생태계를 벗어나지 않기 때문입니다. 반면에 데이터를 관리하고 삭제하고 정책을 설정하는 작업도 수행할 수 있습니다. 사용자의 책임입니다 크로스 사이트 추적과 관련된 많은 우려는 추적이 은밀하게 이루어지고 데이터를 수집하지 않아도 되는 서비스를 사용하는 부작용으로 사용할 수 있습니다. 분석 소프트웨어는 사이트 소유자에게 사용자에 대해 알리기 위해 데이터를 수집하도록 설계되었습니다.
역사적으로, 거대한 어망과 같이 모든 것에 대해 가능한 모든 데이터를 수집하는 접근 방식 나중에 흥미로운 패턴을 찾아 분석해야 합니다 이러한 사고방식은 많은 부분을 불안감과 불안감을 유발했습니다. 데이터 수집에 대해 자세히 알아보겠습니다. 이제 많은 사이트에서 먼저 물어볼 질문을 파악하고 구체적이고 제한된 데이터를 수집하여 이러한 질문에 답하십시오.
일부 제3자 서비스가 내 사이트 및 다른 사이트에서 사용되고 내가 제3자 서비스를 사이트에 포함하여 제3자 서비스가 작동하는 경우, 각 사용자에 대해 쿠키를 설정한다면 사용자가 원치 않는 크로스 사이트 인식을 수행할 수 있다는 점을 고려하는 것이 중요합니다. 즉, 사이트 전반에서 사용자를 추적하는 것입니다. 일부는 있을 수도 있고 그렇지 않을 수도 있지만, 이 문서의 개인 정보 보호 입장은 그렇게 생각하거나 달리 알아야 할 합당한 이유가 없다면 실제로 크로스 사이트 추적을 수행합니다. 그 자체가 이러한 서비스를 피해야 하는 이유는 아니지만 장단점을 평가할 때 고려해야 할 사항입니다. 도움이 될 수 있습니다
과거에는 분석에서 얻는 단점은 사용 여부를 결정하는 것뿐이었습니다. 즉, 모든 데이터를 수집하고 그 대가로 개인 정보를 침해합니다. 유용한 정보 및 계획을 얻거나 통계를 완전히 포기하는 데 도움이 됩니다. 그러나 이제는 더 이상 그렇지 않으며, 두 극단 사이의 중간 지점에 있을 것입니다. 분석 서비스 제공업체에서 제한을 위한 구성 옵션을 확인하세요. 수집하는 데이터의 양과 저장 기간을 줄일 수 있습니다. 기술 감사 기록이 있으므로 감사의 관련 섹션을 다시 실행하여 이러한 구성을 변경해도 변경사항이 적용되었는지 확인할 수 있습니다. 수집되는 데이터의 양이 줄어듭니다. 기존 사이트에서 이렇게 전환하는 경우 사용자를 위해 작성할 수 있는 정량화 가능한 측정 방법을 마련하는 것입니다. 예를 들어 Google 애널리틱스에는 다양한 선택 (따라서 기본적으로 사용 중지됨)이 있습니다. 개인 정보 보호 기능을 제공합니다. 이 중 다수는 현지 데이터 보호법을 준수하는 데 도움이 될 수 있습니다. Google 설정 시 고려해야 할 몇 가지 옵션 분석에는 수집된 데이터 (관리 > 추적 정보 > 데이터 보관)에 대한 보관 기간을 기본값인 26개월보다 낮게 설정하는 기능이 포함됩니다. 부분 IP 익명처리와 같은 보다 기술적인 솔루션을 사용 가능하게 합니다 (자세한 내용은 https://support.google.com/analytics/answer/9019185 참고).
개인 정보를 보호하는 방식으로 서드 파티 사용
지금까지 애플리케이션의 설계 단계에서 사용자를 제3자로부터 보호하는 방법과 이 애플리케이션이 수행할 작업을 계획하는 것입니다 특정 서드 파티를 전혀 사용하지 않기로 결정하는 것도 이 계획의 일환으로 사용 감사도 이 카테고리에 속합니다. 그것은 개인 정보 보호 입장에 대한 결정을 내리는 것입니다. 그러나 이러한 의사 결정이 본질적으로 그다지 세분화되어 있지 않습니다. 특정 제3자 파트너와 협력하거나 협력하지 않는 것은 미묘한 차이로 결정되지 않습니다. 그 중간에 특정 서드 파티 서비스가 필요하거나 사용할 계획인 것을 원할 가능성이 훨씬 높지만 고의든 실수로든 개인 정보 침해 경향을 완화합니다. 다음은 '빌드 시간'에 사용자를 보호하는 작업입니다. 예상치 못한 피해를 줄이기 위한 보호 장치를 추가하는 것입니다. 이 모든 것이 게재 시 제공할 수 있는 새로운 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에 개인 정보가 포함되어 있을 수 있으므로 이는 개인 정보 보호 문제가 될 수 있습니다.
제3자가 사용할 수 있게 되면 해당 개인 정보가 제3자에게 전달됩니다. 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: same-origin를 지정하면
리퍼러 정보를 서드 파티에 전달 (또는 자체 출처를 포함한 다른 사람에게 전달하지 않으려면 Referrer-Policy: no-referrer).
(이는 개인 정보 보호와 유틸리티 간 균형을 잘 보여주는 예입니다. 새로운 기본값은 이전보다 개인 정보를 훨씬 더 보호하지만
개괄적인 정보를 분석 제공업체 등 여러분이 선택한 제3자에게 제공합니다.)
이 헤더를 명시적으로 지정하면 브라우저 기본값에 의존하기보다는 정책이 무엇인지 정확히 알 수 있기 때문에 유용합니다.
헤더를 설정할 수 없는 경우 <head>에서 메타 요소를 사용하여 전체 HTML 페이지의 리퍼러 정책을 설정할 수 있습니다.
<meta name="referrer" content="same-origin"> 특정 서드 파티가 우려되는 경우 referrerpolicy를 설정할 수도 있습니다.
<script>, <a>, <iframe> 등 개별 요소의 속성: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">
Content-Security-Policy
'CSP'라고도 하는 Content-Security-Policy 헤더는 외부 리소스를 로드할 수 있는 위치를 나타냅니다.
이 악성코드는 교차 사이트 스크립팅 공격과 스크립트 삽입을 방지하여 주로 보안 목적으로 사용되지만,
정기 감사와 함께 선택한 서드 파티가 데이터를 전달할 수 있는 위치도 제한될 수 있습니다.
이는 사용자 환경이 좋지 않을 수 있습니다. 서드 파티 스크립트 중 하나가 서버에서 종속 항목을 로드하기 시작하면 출처가 목록에 없으면 해당 요청이 차단되고 스크립트가 실패하며 애플리케이션이 실패할 수 있습니다. 또는 적어도 JavaScript 실패 대체 버전으로 축소되어야 합니다. 이는 CSP가 보안을 위해 구현될 때 유용하며 이는 교차 사이트 스크립팅 문제로부터 보호하는 것입니다 (이를 위해서는 엄격한 CSP 사용). 페이지에서 사용하는 모든 인라인 스크립트를 알게 되면 스크립트의 목록을 만들거나 해시 값을 계산하거나 임의의 값을 추가할 수 있습니다. ('nonce')를 사용한 다음 해시 목록을 콘텐츠 보안 정책에 추가합니다. 이렇게 하면 목록에 없는 경우일 수 있습니다. 이 내용은 사이트의 프로덕션 프로세스에 반영되어야 합니다. 페이지의 스크립트에는 nonce를 포함하거나 해시가 빌드의 일부로 계산되도록 할 수 있습니다. 자세한 내용은 strict-csp에 대한 도움말을 참조하세요.
다행히 브라우저는 관련 헤더 Content-Security-Policy-Report-Only를 지원합니다. 이 헤더가 제공되면
제공된 정책을 위반하는 URL은 차단되지 않지만 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에서 자세한 내용을 확인하세요.
권장사항
게재된 페이지에 이 HTTP 헤더(Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control)를 추가합니다.
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자에게 연락되고 있으며 시간 경과에 따른 변화를 추적할 수 있습니다. 이렇게 하면
기술 감사에 추가되지 않고 새로 추가된 서드 파티도 신고됩니다.
예상한 도메인에 대한 보고를 중단하도록 헤더를 업데이트하는 것도 중요하지만
때때로 기술 감사를 실시합니다 (Content-Security-Policy 접근 방식은 전달되는 어떤 데이터가 전달되는지 플래그를 지정하지 않고
요청이 생성되었음을 알립니다.
매번 또는 모든 페이지에 게재되는 페이지에 추가할 필요는 없습니다. 수신하는 페이지 응답 수 조정하기 이를 통해 보고서 양이 많지 않은 대표 샘플을 확인할 수 있습니다.
권한 정책
Feature-Policy라는 이름으로 도입된 Permissions-Policy 헤더는 개념상 Content-Security-Policy와 유사합니다.
강력한 브라우저 기능에 대한 액세스가 제한됩니다. 예를 들어, 가속도계, 초당 요청 수의 기기 등과 같은 기기 하드웨어의 사용을
카메라 또는 USB 기기에서 전체 화면으로 전환하거나 동기식 XMLHTTPRequest를 사용할 수 있는 권한과 같은 하드웨어 이외의 기능을 제한하는 데 사용됩니다.
이러한 제한은 최상위 수준 페이지에 적용하거나 (로드된 스크립트가 이러한 기능을 사용하지 못하도록 하기 위해) 또는
iframe을 통해 로드되는
하위 프레임 페이지가 포함되어 있습니다 이러한 API 사용 제한은 브라우저 디지털 지문 수집에 관한 것이 아닙니다. 서드 파티가 방해가 되는 작업 (예: 강력한 API 사용, 팝업 창 열기)을
권한 창)에 액세스할 수 있습니다. 이는 표적 개인 정보 보호 위협 모델에 의해 '침입'으로 정의됩니다.
Permissions-Policy 헤더는 (기능, 허용된 출처) 쌍 목록으로 지정됩니다. 따라서 다음과 같습니다.
Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*
이 예시에서는 이 페이지('self') 및 원본 example.com의 <iframe>가 navigator.geolocation API를 사용하도록 허용합니다.
JavaScript에서 시작 이 페이지와 모든 서브프레임이 전체 화면 API를 사용할 수 있도록 허용하며, 이 페이지를 포함한 모든 페이지를 금지합니다.
카메라에서 동영상 정보를 읽을 수 없습니다. 자세한 내용과 가능한 예 목록은 여기에서 확인할 수 있습니다.
권한-정책 헤더가 처리하는 기능 목록은 방대하며 수시로 변할 수 있습니다. 현재 목록은 다음과 같습니다. https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md에서 유지관리합니다.
권장사항
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=()
웹브라우저에 내장된 개인 정보 보호 기능 이해하기
'빌드 시간' 외에도 '디자인 시간' 또한 '런타임'에 발생하는 개인 정보 보호 기능도 있습니다. 즉, 개인 정보 보호는 사용자 보호를 위해 브라우저 자체에 구현된 여러 기능 사용자가 직접 제어하거나 사이트에서 활용할 수 있는 기능은 아닙니다. 개발자(개발자가 제품 기능임)이지만 이러한 제품 기능에 대한 결정이 사이트에 영향을 미칠 수 있으므로 반드시 알아두어야 할 기능입니다. 를 사용해야 합니다. 대기하는 클라이언트 측 JavaScript가 있는 경우 이러한 브라우저 보호가 사이트에 어떤 영향을 미칠 수 있는지에 대한 예를 보여드리겠습니다. 페이지 설정을 계속하기 전에 서드 파티 종속 항목이 로드되고 서드 파티 종속 항목은 전혀 로드되지 않는 경우 페이지 설정이 완료되지 않을 수 있으므로 사용자에게 절반만 로드된 페이지가 표시됩니다.
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 )을 참조하세요.
- 제3자 쿠키는 사이트 제한이 있기 때문에 각 사이트는 기본적으로 별도의 쿠키 보관함을 가지고 있으며 Mozilla는 이를 'Total Cookie Protection'이라고 합니다.
차단될 수 있는 항목을 파악하고 문제를 디버그하려면 주소 표시줄의 방패 아이콘을 클릭하거나 Firefox에서 about:protections (데스크톱)을 방문하세요.
Safari
- 서드 파티 쿠키는 기본적으로 차단됩니다.
- 지능형 추적 방지 기능의 일부로
Safari는 다른 페이지로 전달되는 리퍼러를 특정 페이지가 아닌 최상위 사이트가 되도록 줄입니다(
https://something.example.com,https://something.example.com/this/specific/page가 아님). - 브라우저
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가 필요한 이유는 무엇인가요?
브라우저 제품의 새로운 개인 정보 보호 기능과 정책은 사용자 개인 정보를 보호하는 데 도움이 되기는 하지만 문제도 수반됩니다. 많은 웹 기술은 다른 목적으로 설계 및 사용되지만, 크로스 사이트 추적에 사용할 수 있습니다. 예를 들어 우리가 매일 사용하는 많은 ID 제휴 시스템이 서드 파티 쿠키를 사용합니다. 게시자가 광고 솔루션을 서드 파티 쿠키를 기반으로 구축되었습니다. 많은 사기 감지 솔루션에서 디지털 지문 수집을 사용합니다. 대상 서드 파티 쿠키와 디지털 지문 수집이 사라지면 이러한 사용 사례에 어떤 일이 일어날까요?
브라우저가 사용 사례를 구별하고 개인 정보 보호를 위반하는 사용을 안정적으로 구분하는 것이 어렵고 오류가 발생하기 쉽습니다. 있습니다. 이러한 이유로 대부분의 주요 브라우저에서는 사용자 보호를 위해 서드 파티 쿠키 및 디지털 지문 수집을 차단했거나 차단하려고 했습니다. 있습니다.
새로운 접근 방식이 필요합니다. 서드 파티 쿠키가 단계적으로 폐지되고 디지털 지문 수집이 완화됨에 따라 개발자에게는 특별히 설계된 API가 필요합니다. . 목표는 애플리케이션을 설계하고 크로스 사이트 추적에 사용할 수 없는 API 이전 섹션에서 설명한 브라우저 기능과 달리 이러한 기술은 교차 브라우저 API가 되고자 합니다.
API 제안의 예
다음 목록은 포괄적이지 않고 논의되는 내용의 일부일 뿐입니다.
서드 파티 쿠키에 구축된 기술을 대체하기 위한 API 제안의 예:
수동적 추적 기반의 기술을 대체하기 위한 API 제안의 예:
- 사기 감지 사용 사례: 신뢰 토큰
향후 서드 파티 쿠키 없이 향후 다른 API의 기반이 될 수 있는 다른 제안의 예는 다음과 같습니다.
또한 지금까지 브라우저별 은밀한 추적 완화 방법을 시도하기 위해 또 다른 유형의 API 제안이 등장하고 있습니다. 그중 하나가 개인 정보 보호 예산입니다. 이러한 다양한 Chrome에서 처음에 제안한 API는 개인 정보 보호 샌드박스라는 포괄적인 용어에 속하며 사용 사례도 있습니다.
Global-Privacy-Control은 사용자가 정보를 공유하는 사이트와 통신하려고 하는 헤더입니다. 수집된 개인 정보가 다른 사이트와 공유되지 않도록 하기 위해 이는 중단된 기능인 Do Not Track과 유사합니다.
API 제안 상태
이러한 API 제안 대부분은 아직 배포되지 않았거나, 플래그 이면에서 또는 실험을 위한 제한된 환경에만 배포됩니다.
이 공개 개발 단계는 중요합니다. 브라우저 공급업체와 개발자는 이러한 API가 의도한 대로 작동하는지 여부도 확인할 수 있습니다. 개발자, 브라우저 공급업체, 기타 생태계 행위자가 이 단계를 사용합니다. API의 설계를 반복합니다
현재 제안된 새 API에 대한 최신 정보는 개인 정보 보호 그룹의 GitHub 제안 목록을 참고하시기 바랍니다.
이러한 API를 사용해야 하나요?
제품이 서드 파티 쿠키 또는 디지털 지문 수집과 같은 기술을 기반으로 직접 빌드되었다면 이러한 새 API를 직접 사용해 보고 실험해 보고 토론 및 API 설계에 자신만의 경험을 반영해야 합니다. 그 밖의 모든 경우에는 이 문서를 작성하는 시점에 새로운 API에 대한 모든 세부정보를 알 필요는 없지만, 앞으로 진행될 내용을 알고 있는 것이 좋습니다.