Google I/O를 시청해 주셔서 감사합니다. 주문형 콘텐츠를 확인하세요.

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

디지털 지문 수집

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

더 공식적인 정의는 다음과 같습니다. 지문 식별은 사용자 설정의 명시적 및 비명시적 장기 특성을 사용하여 최대한 많은 다른 사용자와 구별하려는 작업입니다.

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

사용자의 지문 식별이 중요한 특이 사례도 있습니다(예: 사기 감지). 하지만 지문 인식은 사이트 전반에서 사용자를 추적하는 데도 사용될 수 있으며, 이러한 추적은 사용자가 동의하지 않은 상태에서 이루어지거나 경우에 따라 사용자에게 충분히 알리지 않은 잘못된 동의를 근거로 이루어지는 경우가 많습니다. 이 작업이 완료되고 나면 사용자는 종종 다소 배신당했다고 느끼는 것이죠.

디지털 지문 수집은 특정 사용자를 다른 사용자와 은밀하게 구분하는 방법을 찾는 것을 의미합니다. 지문 식별은 동일한 웹사이트에서 여전히 동일한 사용자임을 인식하거나 두 개의 서로 다른 브라우저 프로필에서 동일한 사용자를 동시에 인식하는 데 사용할 수 있습니다. 즉, 사이트 전반에서 사용자를 추적하는 데 지문 식별을 사용할 수 있습니다. 고유한 사용자별 ID가 포함된 쿠키를 저장하는 것과 같은 결정론적이며 명시적인 추적 방법은 사용자에 의해 어느 정도 관찰되고 제어될 수 있습니다(이전 모듈에서 이러한 접근 방식 중 일부를 설명함). 하지만 디지털 지문 수집은 비밀이기 때문이죠. 변하지 않는 특성에 의존하며, 눈에 띄지 않게 일어날 가능성이 큽니다. 이를 '디지털 지문'이라고 합니다. 디지털 지문이나 손가락 끝의 지문을 변경하는 것은 쉽지 않습니다.

브라우저 공급업체는 사용자가 추적을 원하지 않는다는 사실을 알고 있으며 디지털 지문 수집을 제한하는 기능을 지속적으로 구현하고 있습니다. (이 중 일부는 이전 모듈에서 살펴봤습니다). 이번 시간에는 이러한 기능이 비즈니스에 어떤 영향을 미칠 수 있는지 개인 정보를 보호하는 방식으로 계속해서 원하는 작업을 하는 방법을 알아봅니다. 브라우저에서 지문 식별 방지 기능을 사용하면 지문 식별을 실행하는 것이 어떻게 차단되는지보다는 브라우저에서 지문 식별 방지 기능을 사용하면 어떤 작업을 어떻게 할 수 있는지에 관한 내용입니다.

실제로 대부분의 개발자와 비즈니스는 사용자의 지문을 생성할 필요가 없습니다. 앱에서 사용자가 로그인해야 하는 경우 사용자는 동의를 통해 언제든지 일방적으로 선택 해제할 수 있는 방식으로 개발자에게 본인 식별 정보를 제공합니다. 이는 로그인한 사용자를 파악하기 위한 개인 정보 보호 방법입니다. 앱에서 사용자에게 로그인을 요구하지 않을 수도 있습니다. 이렇게 하면 사용자의 개인 정보 보호가 더욱 강화되고 필요한 데이터만 수집할 수 있습니다.

권장사항

서드 파티의 지문 식별을 평가합니다. 서드 파티 모듈을 통해 포함된 서드 파티 서비스와 해당 서비스의 웹 요청 목록이 이미 있을 수 있습니다. 2단계 인증으로 해당 요청을 검사하여 작성자(있는 경우)에게 다시 전달되는 데이터를 확인합니다. 하지만 이는 종종 어렵습니다. 디지털 지문 수집은 본질적으로 사용자 승인 대상이 아닌 데이터를 요청하는 은밀한 프로세스입니다.

또한 서드 파티 서비스 및 종속 항목의 개인정보처리방침을 읽고 디지털 지문 수집의 징후를 찾는 것이 좋습니다. 있습니다. '확률적 일치'라고도 하며 '확정적 일치'와 달리 확률적 일치 기법 모음의 일부로 간주됩니다.

디지털 지문 수집의 작동 방식

이러한 모든 속성의 개인적인 조합은 각자의 고유한 특성이거나 적어도 비슷한 집단의 사람들에게 은밀하게 추적하는 데 사용될 수 있습니다.

참고: 패시브 및 능동적 디지털 지문 수집

여기에서 패시브와 액티브 핑거프린팅 기법을 구분하는 것이 유용합니다. 패시브 핑거프린팅 기법은 웹사이트에 기본적으로 제공되는 정보를 사용하는 기법입니다. 액티브 핑거프린팅 기법은 브라우저에 추가 정보를 명시적으로 쿼리하는 기법입니다. 이러한 구분이 중요한 이유는 브라우저가 활성 기술을 감지 및 가로채거나 완화하려고 시도할 수 있습니다. API는 제한되거나 사용자의 권한을 요청하는 대화상자 뒤에 게이트웨이로 설정될 수 있습니다. 따라서 사용자에게 API가 사용되고 있음을 알리거나 사용자가 기본적으로 API를 거부하도록 허용할 수 있습니다. 수동적 기법은 이미 웹사이트에 제공된 데이터를 사용하는 기법입니다. 왜냐하면 역사적으로 정보 초고속도로 초창기에는 이 정보가 모든 사이트에 제공되었습니다. user-agent 문자열은 이 예시에 대해 더 자세히 살펴보겠습니다. 웹사이트에서 이를 기반으로 다양한 항목을 표시할 수 있도록 사용자의 브라우저, 버전, 운영체제에 관한 상당한 양의 정보를 제공하는 데 유용하다고 여겨졌습니다. 그러나 이렇게 하면 사용자를 구분하는 데 도움이 되는 정보의 양도 늘어납니다. 따라서 이러한 정보는 점점 더 사용 불가하게 되거나 최소한 더 이상 구분할 수 없도록 동결됩니다. 이 정보를 기반으로 하는 업무가 있다면, 예를 들어 코드가 분기될 때마다 브라우저가 점점 더 많은 정보를 동결하거나 중지함에 따라 이 코드는 손상될 수 있습니다. 테스트가 최선의 방어책입니다(나중에 참고).

참고: 지문 식별 가능성 측정

이러한 각 데이터 포인트에서 제공하는 정보의 양을 기술적으로 측정한 값을 엔트로피라고 하며 비트 단위로 측정됩니다. 가능한 값이 여러 개인 기능(예: 설치된 글꼴 목록)은 총계에 많은 비트를 제공할 수 있으며, 구별력이 없는 항목(예: 사용 중인 운영체제)은 몇 개만 추가할 수 있습니다. HTTP Almanac에서는 기존 디지털 지문 수집이 라이브러리는 다양한 API의 응답을 '해시'로 결합하는 과정을 자동화합니다. 단 한 명일 수도 있는 작은 사용자 그룹입니다. 모드 날파스는 이 부분에 대해 이 YouTube 동영상에서 하는 일이지만 간략히 말하면, 좋아하는 음악, 좋아하는 음식, 사용하는 언어가 포함된 친구 목록 삭제되었습니다. 한 사람의 목록이 친구 중에서 고유하게 식별할 수도 있고 범위도 좁을 가능성이 높습니다. 소수의 사람들만 볼 수 있도록 했습니다. 이것이 지문 생성의 작동 방식입니다. 좋아하는 항목 목록이 '해시'가 됩니다. 이 해시를 사용하면 연결되지 않은 두 사이트에서 사용자를 동일한 사람으로 식별하는 것이 더 쉬워집니다. 이는 사용자의 개인 정보 보호 욕구를 회피하기 위한 추적의 목표입니다.

브라우저에서 디지털 지문 수집에 대해 어떤 작업을 수행하나요?

브라우저 공급업체는 웹사이트 (또는 웹사이트에 포함된 서드 파티)를 위한 다양한 방법을 잘 알고 있습니다. 사용자의 고유한 디지털 지문을 계산하거나 고유성에 기여하기 위해 서로 다른 정보 비트를 계산 인식했습니다. 이러한 방법 중 일부는 명시적이고 의도적인 것입니다. 예를 들어 브라우저의 user-agent 문자열(예: 사용 중인 브라우저, 운영 체제 및 버전을 식별하며, 다른 브라우저를 사용하고 있음). 일부 방법은 의도적으로 만들어 낸 것이 아니라 브라우저에서 사용할 수 있는 동영상 및 오디오 장치 목록처럼 말이죠 브라우저는 이러한 기기를 사용할 필요가 없으며 이름으로 기기 목록을 가져오기만 하면 됩니다. 캔버스 요소의 글꼴 안티앨리어싱의 정확한 픽셀 렌더링과 같이 출시 후 지문 생성에 기여하는 것으로 확인된 경우도 있습니다. 그 외에도 많은 요소가 있습니다. 내 브라우저와 다른 브라우저의 각 요소는 엔트로피를 추가하므로 나와 다른 사람을 구분하고 웹사이트에서 개인을 최대한 고유하게 식별하는 데 도움이 될 수 있습니다. https://amiunique.org에는 잠재적인 지문 생성에 기여하는 기능의 긴 목록이 있지만(전체 목록은 아님) 이 목록은 계속 늘어납니다. 사용자가 원하지 않거나 예상하지 못하는 경우에도 사용자의 지문을 생성할 수 있는 기능에 대한 금전적 관심이 크기 때문입니다.

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

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

사용자 권한 게이트웨이

브라우저 공급업체에서 취하는 두 번째 접근 방식은 일종의 명시적인 사용자 권한 없이 API 또는 데이터 액세스를 방지하는 것입니다. 이 접근 방식은 보안상의 이유로도 종종 사용됩니다. 웹사이트에서 사용자의 허락 없이 웹캠으로 사진을 찍을 수 없어야 합니다. 하지만 여기서는 개인 정보 보호와 보안이 비슷한 관심을 가질 수 있습니다. 다른 사람의 위치를 식별하는 것은 물론 그 자체로 개인 정보를 침해할 수 있지만 지문의 고유성을 높이는 요인이기도 합니다. 권한 필요 특정 위치가 해당 지문의 고유성에 추가하는 추가 엔트로피를 감소시키지는 않지만, 기본적으로 디지털 지문 수집에 위치정보를 사용하는 기능이 더 이상 보이지 않으므로 사용하지 않습니다. 지문 식별의 주된 목적은 사용자를 서로 은밀하게 구별하는 것입니다. 사용자가 본인 식별을 시도하고 있다는 사실을 알 수 있도록 준비가 되었다면 지문 식별 기법이 필요하지 않습니다. 사용자에게 계정을 만들고 해당 계정으로 로그인하라고 안내합니다.

예측 불가능성 추가

경우에 따라 취해지는 세 번째 접근 방식은 브라우저 공급업체가 API의 응답을 '퍼징'하여 세부적인 수준을 낮추고 식별 가능성을 낮추는 것입니다. 이는 데이터 모듈의 무작위 응답 메커니즘의 일부로 다음과 같이 설명되어 있습니다. 해야 합니다. 브라우저 공급업체는 웹 앱 및 서드 파티에 제공되는 API 데이터에도 이 접근 방식을 사용할 수 있습니다. 이와 관련된 예로 페이지 성능을 측정하는 데 사용되는 매우 정확한 타이밍 API window.performance.now()부터 브라우저는 이러한 값을 마이크로초 단위의 정확도로 알고 있지만 반환된 값은 지문 식별에 사용되지 않도록(그리고 타이밍 공격을 방지하기 위한 보안상의 이유로) 가장 가까운 20마이크로초 경계로 반올림하여 의도적으로 정밀도가 낮아집니다. 여기서 목표는 는 API의 유용성을 유지할 수 있지만 응답의 식별이 덜하기 위한 것입니다. 본질적으로는 "무리 면역"을 제공하기 위함입니다. 이를 통해 내 기기가 나만 고유하지 않고 다른 사람의 기기처럼 보이게 합니다. Safari는 시스템 구성의 단순화된 버전을 제공합니다 바로 이것입니다.

개인 정보 보호 예산 시행

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

광범위한 테스트 환경 사용

이 모든 것은 앱과 서비스를 빌드하는 방식에 영향을 미칩니다. 특히 대응 방식과 접근 방식이 매우 다양합니다. 이 지역의 브라우저와 플랫폼에서 확인할 수 있습니다 즉, 작업을 여러 환경에서 테스트하는 것이 중요합니다. 이는 물론 항상 중요합니다. 하지만 엔진이 어떤 브라우저나 플랫폼에 있든지 관계없이 주어진 렌더링 엔진에 대해 HTML 렌더링 또는 CSS가 일정하다고 가정하는 것이 합리적일 수 있습니다. 따라서 예를 들어 Blink 기반 브라우저 하나만 테스트하고 싶을 수 있습니다. 이는 명백하게 API를 사용하는 경우에는 그렇지 않습니다. 정확히 렌더링 엔진은 디지털 지문 수집에 대비하여 API 표면을 강화하는 방법에 따라 크게 다를 수 있습니다.

권장사항

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

교차 브라우저 테스트 도구

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

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

대략적인 정보인 경우 사용자 에이전트 문자열만 사용합니다.

또 다른 예로, 브라우저는 웹이 시작된 이래로 HTTP 사용자-에이전트 헤더. 거의 같은 기간 동안 사람들은 웹 개발자에게 user-agent 헤더의 콘텐츠를 사용하여 브라우저마다 다른 콘텐츠를 제공하지 말라고 권고해 왔으며, 그동안 웹 개발자들은 어쨌든 그렇게 해 왔습니다. 일부 경우에만 어느 정도 정당화할 수 있었습니다. 브라우저는 웹사이트에서 차선의 경험을 얻는 것을 원하지 않기 때문에 이렇게 하면 모든 브라우저가 다른 모든 브라우저인 것처럼 가장하고 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이라고 주장합니다. 물론 user-agent 문자열은 지문 식별을 위한 풍부한 엔트로피 소스이며, 이러한 지문 식별 가능성을 완화하기 위해 브라우저 제조업체는 이미 user-agent 헤더를 동결했거나 동결하기 위해 노력하고 있습니다. 이는 API를 완전히 삭제하지 않고도 API가 제공하는 데이터를 변경하는 또 다른 예입니다. 빈 사용자 에이전트 헤더를 전송하면 이 헤더가 있다고 가정하는 수많은 웹사이트가 중단됩니다. 일반적으로 브라우저는 세부사항의 일부를 삭제한 다음 이후로는 거의 변경하지 않고 그대로 유지하는 것입니다. Safari, Chrome, Firefox에서 이러한 현상을 확인할 수 있습니다. 세부적인 디지털 지문 식별에 대한 이러한 보호는 기본적으로 더 이상 user-agent 헤더가 정확하다고 신뢰할 수 없다는 것을 의미하며, 그렇다면 대체 데이터 소스를 찾아야 합니다.

명확히 하자면 사용자 에이전트의 데이터가 완전히 사라지는 것은 아니지만, 더 낮은 세부사항으로 사용할 수 있거나, 변경되지 않은 이전 숫자가 보고될 수 있으므로 부정확할 수 있습니다. 예를 들어 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은 다음과 같은 사용자 에이전트를 제공할 수 있습니다.

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 summarises 요약 로완 메어우드가 제시하는 슬라이드 자료 에서 UA 클라이언트 힌트 제안의 맥락에서 차별화를 위해 user-agent를 사용하는 것에서 벗어날 수 있는 몇 가지 전략을 소개합니다.

퍼징

퍼징은 보안 관행에서 사용되는 용어로, API가 예기치 않은 값을 사용하여 이러한 값을 처리할 수 있기를 기대하며 잘못되어 보안 문제를 야기할 수 있습니다. 웹 개발자는 교차 사이트 스크립팅 (XSS), 이 경우 페이지에 삽입된 HTML을 올바르게 이스케이프하지 않기 때문에 페이지에 악성 스크립트를 추가해야 합니다. 따라서 그 안에 <script> 텍스트가 들어 있는 경우). 백엔드 개발자는 SQL 삽입, 여기서 사용자 입력을 올바르게 검증하지 않는 데이터베이스 쿼리는 보안 문제를 노출시킵니다 (주로 Little Bobby Tables). 퍼징, 즉 퍼징 테스트가 더 적합합니다. API에 다양한 유효하지 않거나 예상치 못한 입력을 제공하고 보안 유출 결과를 확인하려는 자동화된 시도에 사용됩니다. 비정상 종료 또는 기타 잘못된 처리가 발생할 수 있습니다 모두 고의로 부정확한 정보를 제공하는 예입니다. 하지만 여기에서는 (user-agent를 의도적으로 잘못 만들어) 브라우저에서 사전에 데이터 의존하지 않도록 독려합니다.

권장사항

코드베이스에서 사용자 에이전트 문자열에 대한 의존성이 있는지 확인합니다. navigator.userAgent를 검색하면 가장 많이 일치하는 항목을 찾을 수 있습니다. 를 사용하고, 백엔드 코드는 다음을 포함하여 User-Agent 헤더로 찾을 가능성이 높습니다. 종속 항목이 포함됩니다
자체 코드에서 사용을 발견한 경우 코드에서 무엇을 확인하는지 파악하고 구분하는 다른 방법을 찾습니다(또는 대체 종속 항목을 찾거나 문제를 제출하거나 업데이트를 확인하여 종속 항목 업스트림을 사용합니다). 가끔 버그를 해결하기 위해서는 브라우저 차별화가 필요하지만, 고정 후에는 user-agent가 점점 더 이를 수행할 방법이 될 것입니다.
무사할지도 몰라. 브랜드, 주요 버전, 플랫폼의 핵심 값만 사용하는 경우 이러한 값은 거의 확실히 계속 사용할 수 있으며 사용자 에이전트 문자열에서 올바르게 표시됩니다.
MDN에서는 사용자 에이전트 문자열 ('브라우저 스니핑')에 의존하지 않는 좋은 방법을 설명합니다. 그중 주요 방법은 기능 감지입니다.
어떤 식으로든 user-agent 문자열에 의존하는 경우 (유용한 소수의 핵심 값을 사용하는 경우에도) 좋습니다. 새로운 브라우저 릴리스에 포함될 예정된 user-agent로 테스트하는 아이디어를 얻었습니다. 베타 또는 기술 미리보기 빌드를 통해 이러한 향후 브라우저 버전 자체로 테스트할 수 있지만 테스트를 위해 맞춤 사용자-에이전트 문자열을 설정할 수도 있습니다. 로컬 개발 시 Chrome, Edge, Firefox, Safari에서 사용자 에이전트 문자열을 재정의하여 코드가 사용자로부터 수신할 수 있는 다양한 사용자 에이전트 값을 처리하는 방식을 확인할 수 있습니다.

클라이언트 힌트

이 정보를 제공하기 위한 주요 제안사항 중 하나는 User-Agent Client Hints이지만 모든 브라우저에서 지원되는 것은 아닙니다. 지원되는 브라우저는 브라우저 브랜드 및 버전 번호를 제공하는 Sec-CH-UA, 요청이 휴대기기에서 발생했는지 나타내는 Sec-CH-UA-Mobile, 운영체제의 이름을 지정하는 Sec-CH-UA-Platform라는 세 가지 헤더를 전달합니다. 이러한 헤더는 단순한 문자열이 아닌 구조화된 헤더이므로 파싱하기가 생각보다 쉽지 않습니다. 이는 브라우저가 '까다로운' 값을 전송하여 적용되며, 제대로 파싱되지 않으면 잘못 처리됩니다. 이것은 다음과 같습니다. 브라우저가 사전에 수행하는 '퍼징 테스트'의 예입니다. 이 데이터를 사용하는 개발자는 데이터를 부적절하게 또는 지연 파싱하면 좋지 않은 결과를 제공할 수 있기 때문입니다. 있는 경우 또는 제대로 닫히지 않는 문자열). 다행히 이 데이터는 브라우저에서 JavaScript에 navigator.userAgentData로 직접 제공되므로 지원되는 브라우저에서는 다음과 같은 객체로 표시될 수 있습니다.

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