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

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

디지털 지문 수집

디지털 지문 수집은 사용자가 웹사이트를 재방문할 때 사용자를 식별하거나 여러 웹사이트에서 동일한 사용자를 식별하는 것을 의미합니다. 내 설정과 다른 사용자의 설정 간에 많은 특성이 다를 수 있습니다. 예를 들어 다른 유형의 기기와 브라우저를 사용하고 있고 화면 크기가 다르며 다양한 글꼴이 설치되어 있을 수 있습니다. 제가 'Dejavu Sans' 글꼴을 설치했지만 설치하지 않았다면 모든 웹사이트에서 해당 글꼴을 확인하여 여러분과 저의 차이점을 알 수 있습니다. 이러한 방식으로 디지털 지문이 수집됩니다. 이러한 데이터 포인트 모음을 빌드하며 각각은 사용자를 구분하는 더 많은 방법을 제공합니다.

보다 공식적인 정의는 다음과 같습니다. 디지털 지문 수집은 사용자 설정에서 분명하고 명확하지 않은 장기 지속 특성을 사용하여 가능한 한 많은 다른 사용자와 구별하는 작업입니다.

디지털 지문 수집이 사용자 개인 정보 보호를 저해하는 이유

사용자 디지털 지문 수집이 중요한 특이 사례가 일부 있습니다(예: 사기 감지). 그러나 디지털 지문 수집은 사이트 전반에서 사용자를 추적하는 데도 사용될 수 있으며, 사용자의 동의 없이 또는 사용자에게 충분한 정보를 제공하지 않는 잘못된 동의를 바탕으로 추적이 이루어지는 경우가 많습니다. 이렇게 하면 해당 사용자는 다소 불안해하며 오히려 배신감을 느끼는 경우가 많습니다.

디지털 지문 수집은 사용자를 은밀하게 구분할 방법을 찾는 것을 의미합니다. 디지털 지문은 동일한 웹사이트에 있는 동일한 사용자인지 인식하거나 동시에 서로 다른 두 브라우저 프로필에서 동일한 사용자를 인식하는 데 사용할 수 있습니다. 즉, 디지털 지문 수집을 사용하여 사이트 전반에서 사용자를 추적할 수 있습니다. 고유한 사용자별 ID로 쿠키를 저장하는 것과 같은 결정론적이고 명시적인 추적 메서드는 어느 정도 사용자가 관찰하고 제어할 수 있습니다. 이전 모듈에서 이러한 접근 방식 중 일부를 설명했습니다. 하지만 디지털 지문 수집은 은밀하고 변하지 않는 특성에 의존하며 겉으로 드러나지 않을 가능성이 높기 때문에 정확히 피하기는 어렵습니다. 이것이 '지문화'라고 하는 이유입니다 디지털 지문이든 손가락 끝부분이든 지문을 바꾸기란 가장 어려운 일입니다.

브라우저 공급업체는 사용자가 추적되는 것을 원하지 않는다는 것을 알고 있으며, 디지털 지문 수집을 제한하는 기능을 지속적으로 구현하고 있습니다(이전 모듈에서 소개한 부분도 있었음). 여기에서는 이러한 기능이 비즈니스 요구사항에 미칠 수 있는 영향과 개인 정보를 보호하는 방식으로 원하는 작업을 하는 방법을 알아봅니다. 이는 디지털 지문 수집 실행을 막는 방법이 아니라, 디지털 지문 수집에 대해 브라우저 보호가 미치는 영향에 관한 것이 아닙니다.

실제로 대부분의 개발자와 대부분의 기업은 사용자에 관한 정보를 수집할 필요가 없습니다. 앱에서 사용자에게 로그인을 요구하는 경우 사용자는 자신의 동의를 얻고 언제든지 일방적으로 선택 해제할 수 있는 방식으로 개발자에게 자신을 식별합니다. 이는 로그인한 사용자를 파악할 수 있는 개인 정보 보호 방법입니다. 앱에서 사용자에게 로그인을 전혀 요구하지 않을 수 있으며, 이렇게 하면 사용자의 개인 정보를 더욱 안전하게 보호할 수 있으며 필요한 데이터만 수집합니다.

의견을 제시하지

서드 파티의 디지털 지문 수집을 평가합니다. 서드 파티 모듈의 일부로 포함된 서드 파티 서비스 및 이러한 서비스에서 요청하는 웹 요청의 목록이 이미 있을 수 있습니다. 이러한 요청을 검사하여 어떤 데이터가 생성자로 다시 전달되는지 확인할 수 있습니다(있는 경우). 하지만 이는 어려운 경우가 많습니다. 디지털 지문 수집은 본질적으로 사용자 승인 대상이 아닌 데이터를 요청하는 은밀한 프로세스입니다.

또한 서드 파티 서비스 및 종속 항목의 개인정보처리방침을 읽고 디지털 지문 수집이 사용 중인지 확인하는 것이 좋습니다. '확정적 일치'와는 달리 '확률적 일치' 또는 일련의 확률적 일치 기술의 일부로 부합합니다.

디지털 지문 수집 방법

이러한 모든 속성의 개인적인 조합은 본인만의 고유한 특성이 될 수 있으며, 적어도 소수의 비슷한 사용자 그룹에 속하는 경우에는 은밀하게 사용자를 추적하는 데 사용할 수 있는 경우가 많습니다.

참고: 수동 및 능동 디지털 지문 수집

여기서 수동 지문 수집 기법과 능동 지문 수집 기술 간에 유용한 차이점이 있습니다. 수동적 디지털 지문 수집 기법은 기본적으로 웹사이트에 제공되는 정보를 사용하는 기법이고, 능동적 디지털 지문 수집 기법은 브라우저에서 추가 정보를 명시적으로 확인하는 기법입니다. 이 구분이 중요한 이유는 브라우저가 활성 기술을 감지 및 가로채거나 완화하려고 할 수 있기 때문입니다. API는 제한되거나 사용자에게 권한을 요청하는 대화상자 뒤에서 게이트웨이로 전환될 수 있습니다. 따라서 API가 사용 중임을 사용자에게 알리거나 사용자가 기본적으로 API를 거부하도록 허용할 수 있습니다. 수동적 기법은 웹사이트에 이미 제공된 데이터를 사용하는 기법입니다. 역사적으로 정보 슈퍼하이웨이의 초기에는 정보가 모든 사이트에 제공되었기 때문입니다. user-agent 문자열이 이에 대한 예로, 여기에 관해 더 자세히 살펴보겠습니다. 이 기능은 사용자의 브라우저, 버전, 운영체제에 대한 많은 정보를 제공하여 웹사이트에서 이를 기반으로 다른 정보를 표시할 수 있도록 하는 데 유용하다고 여겨졌습니다. 그러나 이로 인해 제공되는 구별되는 정보, 즉 한 사용자를 다른 사용자와 식별하는 데 도움이 되는 정보의 양이 늘어납니다. 따라서 이러한 정보는 더 이상 사용할 수 없게 되거나 최소한 고정되어 더 이상 구별이 불가능해집니다. 이 정보에 의존하는 경우(예: 사용자 에이전트에 따라 다른 코드 브랜치를 사용하는 경우) 브라우저가 해당 정보를 점점 동결하거나 중지함에 따라 이 코드가 손상될 수 있습니다. 여기서는 테스트가 최선의 방어책입니다 ( 나중에 참조).

부가 정보: 디지털 지문 수집 가능성 측정

이러한 각 데이터 포인트가 제공하는 정보의 양에 대한 기술적 측정은 엔트로피라고 하며 비트 단위로 측정됩니다. 가능한 값이 다양한 기능 (예: 설치된 글꼴 목록)은 총계에 많은 비트를 기여할 수 있으므로 구별되는 성능이 크지 않은 요소 (예: 사용 중인 운영체제)는 몇 개만 추가할 수 있습니다. HTTP Almanac은 기존의 디지털 지문 라이브러리가 여러 API의 응답을 '해시'로 결합하는 프로세스를 자동화하는 방법을 설명합니다. '해시'는 소수의 사용자 그룹(아마도 한 명일 수도 있음)만 식별할 수 있습니다. Maud Nalpas가 이 YouTube 동영상에서 이를 자세히 다루고 있지만 간단히 말해서 친구 목록에서 좋아하는 음악, 좋아하는 음식, 사용하는 언어가 나와 있지만 이름은 삭제되었다고 생각해 보세요. 어떤 사람의 목록이 친구 중에서 그 사람을 고유하게 식별하거나, 적어도 몇 사람으로 목록의 범위를 좁힐 가능성이 매우 높습니다. 이것이 바로 디지털 지문 수집의 작동 방식입니다. 좋아하는 것의 목록이 '해시'가 됩니다. 이 해시를 사용하면 연결되지 않은 서로 다른 두 사이트에서 사용자를 동일한 사람으로 식별하기가 더 쉬워집니다. 추적의 목표는 개인 정보 보호에 대한 사용자의 요구를 우회하는 것입니다.

브라우저는 디지털 지문 수집에 대해 어떤 조치를 취하나요?

무엇보다도 브라우저 공급업체는 웹사이트 (또는 웹사이트에 포함된 서드 파티)가 사용자를 위해 구별되는 디지털 지문을 계산하거나, 서로 다른 정보를 사용하여 디지털 지문의 고유성에 기여하는 다양한 방법을 잘 알고 있습니다. 이러한 방법 중 일부는 명시적이고 의도적인 방법 중 하나입니다. 예를 들어 사용자 에이전트 문자열은 주로 사용 중인 브라우저, 운영체제, 버전을 식별하므로 여러분과 내가 서로 다른 브라우저를 사용하는 경우 사용자와 저를 구분하는 데 도움이 됩니다. 글꼴 목록이나 브라우저에서 사용할 수 있는 동영상 및 오디오 기기와 같이 일부 방법은 의도적으로 디지털 지문이 될 수 있게 만들어지지는 않습니다. 브라우저에서 이러한 기기를 사용할 필요는 없으며 이름으로 기기 목록을 가져오기만 하면 됩니다. 그리고 일부는 캔버스 요소 글꼴의 앤티앨리어싱 정확한 픽셀 렌더링과 같이 출시 후에도 지문에 기여하는 것으로 확인되었습니다. 이 외에도 브라우저와 내 브라우저의 차이점에 따라 엔트로피가 추가되어 여러분과 저를 구분하고 웹사이트 전반에서 가능한 한 개인을 고유하게 식별하는 데 도움이 됩니다. https://amiunique.org에는 지문에 영향을 주는 기능이 길지만 매우 포괄적이지는 않으며, 사용자가 디지털 지문에 큰 관심을 가지고 있지 않더라도 지문에 대한 관심이 많지는 않지만 사용자가 디지털 지문에 큰 관심을 가지고 있지 않더라도 지문에 영향을 줄 것으로 기대하지 않는 기능 목록은 계속 늘어납니다.

강력한 특정 API를 지원하지 않음

사용자 지문 계산에 대한 이러한 모든 접근 방식에 대한 브라우저 공급업체의 응답은 이러한 API에서 사용 가능한 엔트로피의 양을 줄이는 방법을 찾는 것입니다. 가장 제한적인 옵션은 애초에 이를 구현하지 않는 것입니다. 이는 일부 주요 브라우저에서 다양한 하드웨어 및 기기 API (예: 클라이언트 측 웹 앱에서의 NFC 및 블루투스 액세스)에서 실행되었으며 디지털 지문 수집과 개인 정보 보호 문제가 구현되지 않은 이유로 언급되었습니다. 이는 분명히 앱과 서비스에 영향을 미칠 수 있습니다. API를 구현하지 않는 브라우저에서는 API를 전혀 사용할 수 없으며 이로 인해 일부 하드웨어 접근 방식이 제한되거나 완전히 차단될 수 있습니다.

사용자 권한 게이트웨이

브라우저 공급업체가 취하는 두 번째 접근 방식은 일종의 명시적인 사용자 권한 없이 API 또는 데이터 액세스를 방지하는 것입니다. 이 방법은 보안상의 이유로도 사용되는 경우가 많습니다. 웹사이트에서 사용자의 허가 없이 웹캠으로 사진을 찍을 수 없어야 합니다. 하지만 여기서는 개인 정보 보호와 보안의 관심사가 비슷할 수 있습니다. 누군가의 위치를 식별하는 것은 그 자체로 개인 정보 침해에 해당할 뿐만 아니라 지문의 고유성을 높이기도 합니다. 위치정보를 볼 수 있는 권한을 요청한다고 해서 위치가 해당 지문의 고유성을 더하는 추가 엔트로피가 줄어드는 것은 아니지만, 지문을 수집하기 위해 위치정보를 사용하는 것은 더 이상 겉으로 드러나지 않게 되므로 기본적으로는 이러한 위치정보를 사용하지 않게 됩니다. 디지털 지문 수집의 요점은 사용자를 은밀하게 구별하는 것입니다. 사용자를 식별하려고 한다는 사실을 사용자가 알 수 있도록 준비된 상태이면 디지털 지문 수집 기술이 필요하지 않습니다. 사용자에게 계정을 만들고 로그인하도록 하면 됩니다.

예측 불가능성 추가

경우에 따라 취하는 세 번째 접근 방식은 브라우저 공급업체가 API의 응답을 '퍼징'하여 API의 응답을 덜 세분화하여 식별성을 낮추는 것입니다. 이는 사용자로부터 데이터를 수집할 때 취할 수 있는 조치로 데이터 모듈의 무작위 응답 메커니즘의 일부로 설명되었습니다. 이는 식별 대상 데이터를 실수로 수집하는 일을 방지하기 위해서입니다. 브라우저 공급업체는 웹 앱 및 서드 파티에 제공되는 API 데이터에도 이 접근 방식을 사용할 수 있습니다. window.performance.now()의 페이지 성능을 측정하는 데 사용되는 매우 정확한 타이밍 API를 예로 들 수 있습니다. 브라우저는 이러한 값을 마이크로초 단위로 알고 있지만, 반환되는 값은 디지털 지문 수집에 사용되지 않도록 가장 가까운 20마이크로초 경계로 반올림하여 의도적으로 정밀도를 낮춥니다 (타이밍 공격을 피하기 위한 보안 목적). 여기서 목표는 API를 계속 유용하게 유지하되 응답을 덜 식별하게 하는 것입니다. 즉, 본질적으로 기기가 나에게 특이하기보다는 다른 사람의 기기처럼 보이게 하여 '허드 면역'을 제공하는 것입니다. 이런 이유로 Safari는 단순화된 버전의 시스템 구성을 제공합니다.

개인 정보 보호 예산 시행

개인 정보 보호 예산은 브라우저가 각 디지털 지문 수집 경로에서 드러난 정보를 추정하도록 제안하는 제안입니다. 브라우저에서는 아직 구현되지 않았습니다. 목표는 사용자 개인 정보를 보호하면서 강력한 API를 허용하는 것입니다. 개인 정보 보호 예산 제안서 자세히 알아보기

광범위한 테스트 환경 사용

이 모든 사항은 앱과 서비스를 빌드하는 방식에 영향을 미칩니다. 특히, 이 영역에서 브라우저와 플랫폼에 따라 응답과 접근 방식이 매우 다양합니다. 즉, 여러 다양한 환경에서 작업을 테스트하는 것이 중요합니다. 물론 이는 항상 중요한 일이지만 HTML 렌더링 또는 CSS는 엔진이 있는 브라우저나 플랫폼에 관계없이 특정 렌더링 엔진에 대해 일정할 것이라고 가정할 수 있습니다. 따라서 예를 들어 하나의 깜박임 기반 브라우저에서만 테스트하고 싶을 수 있습니다. 이는 정확히 API 사용과는 다릅니다. 렌더링 엔진을 공유하는 브라우저는 디지털 지문 수집에 대비해 API 노출 영역을 강화하는 방식이 크게 다를 수 있기 때문입니다.

의견을 제시하지

자체 분석과 대상을 확인하여 테스트할 때 우선순위를 두어야 하는 브라우저 집합을 파악하세요.
테스트하기 좋은 브라우저로는 Firefox, Chrome, Edge, 데스크톱의 Safari, Android의 Chrome 및 Samsung Internet, iOS의 Safari 등이 있습니다. 이렇게 하면 모바일 및 데스크톱 플랫폼 모두에서 세 가지 주요 렌더링 엔진 (Firefox의 Gecko, Chrome의 다양한 Blink, Edge, 삼성 인터넷, Webkit의 Webkit)을 테스트할 수 있습니다.
태블릿, 스마트시계, 게임 콘솔 등 일반적이지 않은 기기에서도 사이트를 사용할 수 있는 경우 해당 기기에서도 테스트하세요. 일부 하드웨어 플랫폼의 경우 브라우저 업데이트가 모바일 및 데스크톱에서 뒤처질 수 있습니다. 즉, 일부 API가 모바일 및 데스크톱 플랫폼의 브라우저에서 구현되지 않거나 사용하지 못할 수 있습니다.
사용자 개인 정보 보호를 동기 요소로 주장하는 하나 이상의 브라우저를 사용하여 테스트하세요. 사용 가능한 경우 Safari의 기술 미리보기, Chrome의 Canary, Firefox 베타 채널 등 가장 일반적인 브라우저의 출시 전 및 테스트 버전을 최대한 포함하세요. 이렇게 하면 API 중단 및 사용자에게 영향을 미치기 전에 사이트에 영향을 미치는 변경사항을 식별할 수 있습니다. 마찬가지로 제공되는 모든 분석과 관련하여 사용자 환경을 고려해야 합니다. 사용자층에 이전 Android 휴대전화가 많으면 이러한 휴대전화를 테스트에 포함해야 합니다. 대부분의 사람들은 개발팀이 제공하는 빠른 하드웨어와 최신 출시 버전을 가지고 있지 않습니다.
정리된 프로필과 시크릿/시크릿 브라우징 모드를 모두 사용하여 테스트하세요. 개인 프로필에 필요한 권한을 이미 부여했을 가능성이 높습니다. 질문에 대해 사이트에 대한 권한을 거부하면 어떻게 되는지 테스트합니다.
Firefox의 디지털 지문 보호 모드에서 페이지를 명시적으로 테스트합니다. 이렇게 하면 페이지에서 디지털 지문 수집을 시도하는 경우 권한 대화상자가 표시되거나 일부 API의 경우 퍼징 데이터가 반환됩니다. 이를 통해 서비스에 포함된 서드 파티가 지문 가능 데이터를 사용하고 있는지 또는 자체 서비스에서 디지털 지문 수집이 가능한 데이터를 사용하고 있는지 확인할 수 있습니다. 그런 다음 의도적인 퍼징이 필요한 작업을 더 어렵게 만드는지 여부를 고려할 수 있습니다. 적절하게 수정하여 다른 소스에서 해당 데이터를 얻거나, 데이터 없이 실행하거나, 덜 세분화된 데이터를 사용하는 것이 좋습니다.
앞서 서드 파티 모듈에서 설명한 것처럼 서드 파티 종속 항목을 감사하여 디지털 지문 수집 기법을 사용하는지 확인하는 것도 중요합니다. 수동적 디지털 지문 수집은 감지하기는 어렵지만 (서드 파티가 자체 서버에서 수행하는 경우에는 불가능합니다.) 디지털 지문 수집 모드에서는 일부 디지털 지문 수집 기법이 플래그가 지정될 수 있으며 navgator.userAgent를 사용하거나 예기치 않은 <canvas> 객체를 생성하려는 경우에도 정밀 조사가 필요한 일부 접근 방식이 드러날 수 있습니다. 또한 마케팅 또는 서드 파티를 설명하는 기술 자료에서 '확률적 일치'라는 용어를 사용하는 것도 좋은 방법입니다. 이는 디지털 지문 수집 기술을 사용한다는 의미일 수도 있습니다.

교차 브라우저 테스트 도구

개인 정보 보호를 위한 코드 테스트는 자동화하기가 어려우며, 수동으로 테스트할 때 확인해야 할 사항은 앞에서 설명했습니다. 예를 들어 사이트에서 액세스를 시도하는 API에 대해 사이트의 권한을 거부하면 어떻게 되며, 이 내용이 사용자에게 어떻게 표시되나요? 자동 테스트는 사이트가 사용자의 신뢰를 얻기 위한 것인지, 반대로 사용자의 신뢰를 얻기 위한 것인지, 아니면 무언가가 숨겨져 있다고 생각하도록 유도하는 것인지 판단할 수 없습니다.

그러나 사이트가 감사되면 최신 브라우저 버전 (또는 향후 '베타' 및 '미리보기' 버전)에서 손상된 부분이 없는지 확인하기 위한 API 테스트를 자동화할 수 있으며 대부분 기존 테스트 모음의 일부로 포함되어야 합니다. API 노출 영역 적용 범위로 작업할 때 자동 테스트 도구를 사용할 때는 대부분의 브라우저에서 사용 가능한 API와 기능을 어느 정도 제어할 수 있다는 점을 고려해야 합니다. Chrome은 Firefox와 마찬가지로 명령줄 전환을 통해 전환하며, 테스트 도구 설정에서 이 기능에 액세스할 수 있으면 API를 끄거나 켠 상태에서 특정 테스트를 실행할 수 있습니다. 예를 들어 실행할 때 브라우저 플래그를 추가하는 방법은 Cypress의 browser-launch 플러그인 및 Puppeteer의 launch.args 매개변수를 참고하세요.

대략적인 정보의 경우 사용자 에이전트 문자열만 사용

또 다른 예로, 브라우저는 웹이 시작된 이래로 HTTP User-Agent 헤더의 모든 요청과 함께 브라우저 자체에 대한 설명을 전송했습니다. 지금까지 사람들은 웹 개발자에게 사용자 에이전트 헤더의 콘텐츠를 사용하여 다양한 콘텐츠를 다양한 브라우저에 제공하지 말라고 권고해 왔습니다. 그동안 웹 개발자들은 어떤 경우든 어느 정도의 정당성을 덧붙여 왔습니다. 브라우저가 웹사이트에서 최적화되지 않은 환경을 제공하기 위해 특정 브라우저를 사용하는 것을 원하지 않기 때문에, 이 경우 모든 브라우저가 다른 모든 브라우저인 것처럼 위장하고 사용자 에이전트 문자열은 다음과 같이 표시됩니다.

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36.

이는 20여 년 전 최초의 우주비행사가 국제 우주 정거장에 탑승한 것과 동시에 출시된 브라우저인 Mozilla/5.0이라고 주장합니다. 사용자 에이전트 문자열은 물론 디지털 지문 수집에서 다양한 엔트로피의 역할을 하며, 지문 가능성을 줄이기 위해 브라우저 제조업체는 이미 사용자 에이전트 헤더를 고정했거나 고정하기 위해 노력하고 있습니다. 이는 API를 완전히 삭제하지 않고도 API가 제공하는 데이터를 변경하는 또 다른 예입니다. 빈 사용자 에이전트 헤더를 전송하면 사용자 에이전트 헤더가 있다고 가정하는 수많은 웹사이트가 손상됩니다. 일반적으로 브라우저는 브라우저에서 일부 세부정보를 삭제한 다음 그때부터 거의 변경되지 않은 상태로 둡니다. (Safari, Chrome, Firefox에서 이 현상을 확인할 수 있습니다.) 상세 디지털 지문 수집에 대한 이 같은 보호 조치는 기본적으로 사용자 에이전트 헤더가 정확하다고 보장할 수 없다는 의미입니다. 그렇게 하려면 대체 데이터 소스를 찾는 것이 중요합니다.

명확히 하자면 사용자 에이전트의 데이터가 완전히 사라지지는 않지만, 더 세부적인 수준에서 사용할 수 있거나 오래되었지만 변하지 않는 숫자가 보고될 수 있어 부정확할 수도 있습니다. 예를 들어 Firefox, Safari, Chrome에서는 모두 보고된 macOS 버전 번호가 10으로 제한됩니다 (자세한 내용은 사용자 에이전트 문자열 축소 관련 업데이트 참고). Chrome에서 사용자 에이전트 문자열의 데이터를 어떻게 줄일 계획인지에 관한 정확한 세부정보는 사용자 에이전트 축소에서 확인할 수 있지만 간단히 말하자면 보고된 브라우저 버전 번호에는 메이저 버전만 포함될 수 있습니다. 따라서 브라우저의 버전이 123.10.45.108이더라도 버전 번호는 123.0.0.0과 같이 표시되며, OS 버전 번호의 경우 세세한 부분만 변경할 수 없습니다. 따라서 가상의 'Windows 20'에서 실행되는 가상의 Chrome 버전 123.45.67.89는 버전 번호를 다음과 같이 보고합니다.

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

필요한 핵심 정보 (브라우저 버전)는 여전히 사용 가능합니다. Windows용 Chrome 123입니다. 하지만 고정 후 자회사 정보 (칩 아키텍처, Windows 버전, 모방 중인 Safari 버전, 브라우저 부 버전)는 더 이상 사용할 수 없습니다.

이를 다른 플랫폼의 '최신' Chrome 사용자 에이전트와 비교해 보세요.

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,

Chrome 버전 번호 (104)와 플랫폼 식별자만 다름을 알 수 있습니다.

마찬가지로 Safari의 사용자 에이전트 문자열은 플랫폼 및 Safari 버전 번호를 표시하고 iOS의 OS 버전도 제공하지만 다른 모든 항목은 고정됩니다. 따라서 가상의 macOS 20에서 실행되는 가상의 Safari 버전 1234.5.67은 user-agent를 다음과 같이 제공할 수 있습니다.

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,

가상의 iOS 20에서는 다음과 같을 수 있습니다.

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**.

다시 말하지만 핵심 정보 (Safari, iOS 또는 macOS에 있음)를 사용할 수 있고 iOS Safari는 여전히 iOS 버전 번호를 제공합니다. 하지만 이전에 사용할 수 있었던 대부분의 보조 정보는 동결되었습니다. 중요한 것은 Safari 버전 번호(반드시 제공되지 않을 수도 있음)가 포함되어 있다는 것입니다.

보고된 사용자 에이전트의 변경사항에 대해 뜨거운 논쟁이 벌어졌습니다. https://github.com/WICG/ua-client-hints#use-cases 요약에는 몇 가지 인수와 변경 이유가 요약되어 있으며 Rowan Merewood는 UA 클라이언트 제안에 관해 자세히 설명한 맥락에서 차별화를 위해 사용자 에이전트를 사용하지 않기 위한 몇 가지 전략이 포함된 슬라이드 자료를 제공합니다.

퍼징

퍼징은 예기치 않은 값을 잘못 처리하고 보안 문제를 노출하기 위해 예기치 않은 값으로 API를 호출하는 보안 관행의 용어입니다. 웹 개발자는 교차 사이트 스크립팅 (XSS)에 대해 잘 알고 있어야 합니다. 이 방법은 페이지에 악성 스크립트를 추가하는 작업이 포함됩니다. 페이지가 삽입된 HTML을 올바르게 이스케이프 처리하지 않기 때문인 경우가 많기 때문입니다 (따라서 페이지에 <script>라는 텍스트가 포함된 검색어를 입력함). 백엔드 개발자는 SQL 삽입을 인지하게 될 것입니다. 사용자 입력의 유효성을 제대로 검사하지 않는 데이터베이스 쿼리가 보안 문제를 일으킵니다 (특히 Little Bobby Tables의 xkcd에서 설명). 퍼징 또는 퍼징 테스트는 여러 가지 무효하거나 예상치 못한 입력을 API에 제공하고 보안 유출, 비정상 종료 또는 기타 잘못된 처리 결과를 확인하려는 자동화된 시도에 더 적절하게 사용됩니다. 모두 의도적으로 부정확한 정보를 제공하는 예입니다. 하지만 여기서는 개발자가 해당 데이터에 의존하지 않도록 장려하기 위해 (사용자 에이전트를 의도적으로 잘못 만들어) 브라우저에서 사전에 수행됩니다.

의견을 제시하지

코드베이스에서 종속 항목을 포함하여 사용자 에이전트 문자열을 신뢰하고 있는지 확인합니다. navigator.userAgent를 검색하면 클라이언트 측 코드에서 대부분의 일치하는 항목을 찾을 수 있으며 백엔드 코드에서 User-Agent를 헤더로 찾을 가능성이 높습니다.
자체 코드에서 용도를 찾은 경우 코드가 무엇을 검사하는지 파악하고 차별화를 위한 다른 방법을 찾습니다. 또는 대체 종속 항목을 찾거나 문제를 제출하거나 종속 항목 업스트림에 업데이트를 확인하여 종속 항목 업스트림을 사용합니다. 버그를 해결하기 위해 브라우저 구분이 필요할 때도 있지만, 일단 사용자 에이전트가 정지되고 나면 이 방법을 사용할 수 없게 됩니다.
안전할 수도 있습니다. 브랜드, 메이저 버전, 플랫폼의 핵심 값만 사용하는 경우 거의 확실하게 사용할 수 있고 사용자 에이전트 문자열에서 정확합니다.
MDN은 사용자 에이전트 문자열('브라우저 스니핑')의 의존을 피하는 좋은 방법을 설명합니다. 그 중 주요한 방법은 기능 감지입니다.
여전히 유용한 몇 가지 핵심 값을 사용하더라도 어떤 식으로든 사용자 에이전트 문자열에 의존하고 있다면 새 브라우저 버전에 포함될 예정인 사용자 에이전트로 테스트하는 것이 좋습니다. 베타 또는 기술 미리보기 빌드를 통해 이러한 출시 예정 브라우저 버전으로 직접 테스트할 수 있지만 테스트용 맞춤 사용자 에이전트 문자열을 설정할 수도 있습니다. 로컬에서 개발할 때 Chrome, Edge, Firefox, Safari에서 사용자 에이전트 문자열을 재정의하여 사용자에게서 받을 수 있는 다양한 사용자 에이전트 값을 코드가 어떻게 처리하는지 확인할 수 있습니다.

클라이언트 힌트

이 정보를 제공하기 위한 주요 제안 중 하나는 User-Agent Client Hints입니다. 단, 모든 브라우저에서 지원되는 것은 아닙니다. 지원되는 브라우저는 브라우저 브랜드와 버전 번호를 제공하는 Sec-CH-UA 헤더, 요청이 휴대기기에서 시작되었는지를 나타내는 Sec-CH-UA-Mobile, 운영체제의 이름을 지정하는 Sec-CH-UA-Platform 등 세 개의 헤더를 전달합니다. (이 헤더는 단순한 문자열이 아니라 구조화된 헤더이기 때문에 파싱하기가 쉽지 않으며, 'tricky' 값을 전송하는 브라우저에 의해 시행되며, 올바르게 파싱되지 않으면 올바르게 처리됩니다. 이는 앞에서와 같이 브라우저에서 사전에 실행되는 '퍼징 테스트'의 예입니다. 이 데이터를 사용하는 개발자는 데이터를 적절하게 처리해야 합니다. 데이터가 부적절하거나 지연된 파싱으로 인해 존재하지 않는 브랜드나 제대로 닫히지 않는 문자열을 표시하는 등 부정적인 결과를 가져올 수 있기 때문입니다.) 다행히 이 데이터는 브라우저에서 JavaScript에 직접 navigator.userAgentData로도 제공되며, 지원되는 브라우저에서는 다음 객체와 유사할 수 있습니다.

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}