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

User-Agent 클라이언트 힌트로 이전

사용자 에이전트 문자열을 사용하는 사이트를 새 User-Agent 클라이언트 힌트로 이전하는 전략

Rowan Merewood

사용자 에이전트 문자열은 브라우저에서 중요한 패시브 디지털 지문 수집 노출 영역이며 처리하기 어렵습니다. 하지만 사용자 에이전트 데이터를 수집하고 처리하는 데는 다양한 타당한 이유가 있으므로 더 나은 솔루션으로 가는 길이 필요합니다. User-Agent 클라이언트 힌트는 사용자 에이전트 데이터의 필요성을 선언하는 명시적인 방법과 사용하기 쉬운 형식으로 데이터를 반환하는 메서드를 모두 제공합니다.

이 도움말에서는 사용자 에이전트 데이터에 대한 액세스 권한을 감사하고 사용자 에이전트 문자열 사용을 사용자 에이전트 클라이언트 힌트로 이전하는 방법을 설명합니다.

사용자 에이전트 데이터 수집 및 사용 감사

다른 모든 형태의 데이터 수집과 마찬가지로 데이터를 수집하는 이유를 항상 이해해야 합니다. 조치를 취할지 여부와 관계없이 첫 번째 단계는 사용자-에이전트 데이터를 사용하는 위치와 이유를 파악하는 것입니다.

사용자 에이전트 데이터가 사용되는지 또는 사용되는 위치를 모르는 경우 프런트엔드 코드에서 navigator.userAgent 사용을 검색하고 백엔드 코드에서 User-Agent HTTP 헤더 사용을 검색해 보세요. 또한 프런트엔드 코드에서 navigator.platform 및 navigator.appVersion와 같이 지원 중단된 기능이 사용되지 않는지 확인해야 합니다.

기능적 관점에서 코드에서 녹화하거나 처리하는 모든 위치를 생각해 보세요.

브라우저 이름 또는 버전
운영체제 이름 또는 버전
기기 제조업체 또는 모델
CPU 유형, 아키텍처 또는 비트 수 (예: 64비트)

서드 파티 라이브러리 또는 서비스를 사용하여 사용자 에이전트를 처리하고 있을 수도 있습니다. 이 경우 User-Agent 클라이언트 힌트를 지원하도록 업데이트 중인지 확인합니다.

기본 사용자 에이전트 데이터만 사용하고 있나요?

기본 사용자 에이전트 클라이언트 힌트 세트에는 다음이 포함됩니다.

Sec-CH-UA: 브라우저 이름 및 주요/중요한 버전
Sec-CH-UA-Mobile: 휴대기기를 나타내는 불리언 값
Sec-CH-UA-Platform: 운영체제 이름
- 이러한 변경사항은 사양에서 업데이트되었으며 곧 Chrome 및 기타 Chromium 기반 브라우저에 반영될 예정입니다.

제안된 축소된 버전의 사용자 에이전트 문자열도 이전 버전과 호환되는 방식으로 이 기본 정보를 유지합니다. 예를 들어 문자열에 Chrome/90.0.4430.85 대신 Chrome/90.0.0.0이 포함됩니다.

브라우저 이름, 메이저 버전 또는 운영 체제의 사용자 에이전트 문자열만 확인하는 경우 지원 중단 경고가 표시될 수 있지만 코드는 계속 작동합니다.

User-Agent 클라이언트 힌트로 이전할 수 있고 이전해야 하지만 이를 방해하는 기존 코드나 리소스 제약조건이 있을 수 있습니다. 이러한 하위 호환 방식으로 사용자 에이전트 문자열의 정보를 줄이는 것은 기존 코드가 더 적은 양의 세부정보를 수신하더라도 기본 기능을 유지할 수 있도록 하기 위한 것입니다.

전략: 주문형 클라이언트 측 JavaScript API

현재 navigator.userAgent를 사용 중인 경우 user-agent 문자열 파싱으로 대체하기 전에 navigator.userAgentData를 선호하도록 전환해야 합니다.

if (navigator.userAgentData) {
  // use new hints
} else {
  // fall back to user-agent string parsing
}

모바일 또는 데스크톱을 확인하는 경우 불리언 mobile 값을 사용하세요.

const isMobile = navigator.userAgentData.mobile;

userAgentData.brands는 brand 및 version 속성이 있는 객체 배열로, 브라우저가 이러한 브랜드와의 호환성을 나열할 수 있습니다. 배열로 직접 액세스하거나 some() 호출을 사용하여 특정 항목이 있는지 확인할 수 있습니다.

function isCompatible(item) {
  // In real life you most likely have more complex rules here
  return ['Chromium', 'Google Chrome', 'NewBrowser'].includes(item.brand);
}
if (navigator.userAgentData.brands.some(isCompatible)) {
  // browser reports as compatible
}

userAgentData.brands에는 다양한 순서로 다양한 값이 포함되므로 특정 색인에 표시되는 항목에 의존하지 마세요.

더 자세하고 엔트로피가 높은 사용자 에이전트 값 중 하나가 필요한 경우 이를 지정하고 반환된 Promise에서 결과를 확인해야 합니다.

navigator.userAgentData.getHighEntropyValues(['model'])
  .then(ua => {
    // requested hints available as attributes
    const model = ua.model
  });

서버 측 처리에서 클라이언트 측 처리로 전환하려는 경우에도 이 전략을 사용할 수 있습니다. JavaScript API는 HTTP 요청 헤더에 액세스할 필요가 없으므로 언제든지 사용자 에이전트 값을 요청할 수 있습니다.

전략: 정적 서버 측 헤더

서버에서 User-Agent 요청 헤더를 사용하고 해당 데이터에 대한 요구사항이 전체 사이트에서 비교적 일관된 경우 응답에서 원하는 클라이언트 힌트를 정적 세트로 지정할 수 있습니다. 일반적으로 한 위치에서만 구성하면 되므로 비교적 간단한 접근 방식입니다. 예를 들어 웹 서버 구성에 이미 헤더를 추가한 경우, 호스팅 구성 또는 사이트에 사용하는 프레임워크 또는 플랫폼의 최상위 구성에 있을 수 있습니다.

사용자-에이전트 데이터를 기반으로 제공되는 응답을 변환하거나 맞춤설정하는 경우 이 전략을 고려해 보세요.

브라우저나 다른 클라이언트에서 다른 기본 힌트를 제공할 수 있으므로 일반적으로 기본적으로 제공되는 경우에도 필요한 모든 항목을 지정하는 것이 좋습니다.

예를 들어 Chrome의 현재 기본값은 다음과 같이 표시됩니다.

⬇️ 응답 헤더

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA

응답에서 기기 모델도 수신하려면 다음을 전송합니다.

⬇️ 응답 헤더

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform, Sec-CH-UA

서버 측에서 이를 처리할 때는 먼저 원하는 Sec-CH-UA 헤더가 전송되었는지 확인한 다음 사용할 수 없는 경우 User-Agent 헤더 파싱으로 대체해야 합니다.

전략: 교차 출처 요청에 힌트 위임

요청 시 User-Agent 클라이언트 힌트를 전송해야 하는 교차 출처 또는 교차 사이트 하위 리소스를 요청하는 경우 권한 정책을 사용하여 원하는 힌트를 명시적으로 지정해야 합니다.

예를 들어 https://blog.site가 특정 기기에 최적화된 리소스를 반환할 수 있는 https://cdn.site에 리소스를 호스팅한다고 가정해 보겠습니다. https://blog.site는 Sec-CH-UA-Model 힌트를 요청할 수 있지만 Permissions-Policy 헤더를 사용하여 https://cdn.site에 명시적으로 위임해야 합니다. 정책 제어 힌트 목록은 클라이언트 힌트 인프라 초안에서 확인할 수 있습니다.

⬇️ 힌트를 위임하는 blog.site의 응답

Accept-CH: Sec-CH-UA-Model
Permissions-Policy: ch-ua-model=(self "https://cdn.site")

⬆️ cdn.site의 하위 리소스에 대한 요청에 위임된 힌트 포함

Sec-CH-UA-Model: "Pixel 5"

ch-ua 범위뿐만 아니라 여러 출처에 여러 개의 힌트를 지정할 수 있습니다.

⬇️ 여러 출처에 여러 힌트를 위임하는 blog.site의 응답

Accept-CH: Sec-CH-UA-Model, DPR
Permissions-Policy: ch-ua-model=(self "https://cdn.site"),
                    ch-dpr=(self "https://cdn.site" "https://img.site")

각 위임된 힌트를 Accept-CH에 포함할 필요는 없지만, 최상위 수준에서 직접 사용하지 않더라도 각 힌트에 self를 포함해야 합니다.

전략: iframe에 힌트 위임

교차 출처 iframe은 교차 출처 리소스와 비슷한 방식으로 작동하지만 위임할 힌트는 allow 속성에서 지정합니다.

⬇️ blog.site의 응답

Accept-CH: Sec-CH-UA-Model

↪️ blog.site용 HTML

<iframe src="https://widget.site" allow="ch-ua-model"></iframe>

⬆️ widget.site에 요청

Sec-CH-UA-Model: "Pixel 5"

iframe의 allow 속성은 widget.site가 자체적으로 전송할 수 있는 모든 Accept-CH 헤더를 재정의하므로 iframe 사이트에 필요한 모든 항목을 지정했는지 확인하세요.

전략: 동적 서버 측 힌트

사용자 여정의 특정 부분에서 나머지 사이트보다 더 많은 힌트 선택이 필요한 경우 전체 사이트에서 정적으로 힌트를 요청하는 대신 필요에 따라 요청할 수 있습니다. 관리하기는 더 복잡하지만 이미 경로별로 다른 헤더를 설정한 경우에는 가능할 수 있습니다.

여기서 중요한 점은 Accept-CH 헤더의 각 인스턴스가 기존 세트를 효과적으로 덮어쓴다는 것입니다. 따라서 헤더를 동적으로 설정하는 경우 각 페이지에서 필요한 전체 힌트 집합을 요청해야 합니다.

예를 들어 사이트에 사용자의 운영체제와 일치하는 아이콘과 컨트롤을 제공하려는 섹션이 하나 있을 수 있습니다. 이를 위해 Sec-CH-UA-Platform-Version를 추가로 가져와 적절한 하위 리소스를 제공하는 것이 좋습니다.

⬇️ /blog의 응답 헤더

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA

⬇️ /app의 응답 헤더

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version, Sec-CH-UA

전략: 첫 번째 요청 시 서버 측 힌트 필요

첫 번째 요청에서 기본 힌트 세트보다 많은 힌트가 필요한 경우가 있을 수 있지만, 이는 드물기 때문에 근거를 검토해야 합니다.

첫 번째 요청은 실제로 해당 브라우징 세션에서 전송된 해당 출처의 첫 번째 최상위 요청을 의미합니다. 기본 힌트 세트에는 기본 버전이 포함된 브라우저 이름, 플랫폼, 모바일 표시기가 포함됩니다. 여기서 질문할 수 있는 것은 초기 페이지 로드 시 확장 데이터가 필요한지 여부입니다.

첫 번째 요청에 대한 추가 힌트는 두 가지 옵션이 있습니다. 먼저 Critical-CH 헤더를 사용할 수 있습니다. 이 힌트는 Accept-CH와 동일한 형식을 사용하지만 첫 번째 힌트가 중요한 힌트 없이 전송된 경우 브라우저에 요청을 즉시 다시 시도해야 한다고 알려줍니다.

⬆️ 초기 요청

[With default headers]

⬇️ 응답 헤더

Accept-CH: Sec-CH-UA-Model
Critical-CH: Sec-CH-UA-Model

🔃 브라우저가 추가 헤더를 사용하여 초기 요청을 다시 시도합니다.

[With default headers + …]
Sec-CH-UA-Model: Pixel 5

이렇게 하면 첫 번째 요청에서 재시도 오버헤드가 발생하지만 구현 비용은 비교적 낮습니다. 추가 헤더를 전송하면 브라우저가 나머지를 처리합니다.

모든 Critical-CH 값은 Accept-CH의 값의 하위 집합이어야 합니다. Accept-CH는 페이지에 필요한 모든 값이고 Critical-CH는 이러한 값 중 있어야 페이지를 제대로 로드할 수 있는 하위 집합입니다.

첫 페이지 로드 시 추가 힌트가 정말로 필요한 경우 클라이언트 힌트 안정성 제안서에서는 연결 수준 설정에서 힌트를 지정하는 경로를 제시합니다. TLS 1.3의 애플리케이션 계층 프로토콜 설정(ALPS) 확장 프로그램을 사용하여 HTTP/2 및 HTTP/3 연결에 대한 힌트를 조기에 전달할 수 있습니다. 아직 초기 단계이지만 자체 TLS 및 연결 설정을 적극적으로 관리하는 경우 참여하기에 좋은 시기입니다.

전략: 레거시 지원

사이트에 navigator.userAgent에 종속된 기존 코드 또는 서드 파티 코드가 있을 수 있으며, 여기에는 축소될 사용자 에이전트 문자열의 일부가 포함됩니다. 장기적으로는 이에 상응하는 navigator.userAgentData 호출로 전환할 계획을 세워야 하지만 임시 솔루션이 있습니다.

UA-CH 레트로필은 요청된 navigator.userAgentData 값으로 빌드된 새 문자열로 navigator.userAgent을 덮어쓸 수 있는 작은 라이브러리입니다.

예를 들어 이 코드는 '모델' 힌트를 추가로 포함하는 사용자 에이전트 문자열을 생성합니다.

import { overrideUserAgentUsingClientHints } from './uach-retrofill.js';
overrideUserAgentUsingClientHints(['model'])
  .then(() => { console.log(navigator.userAgent); });

결과 문자열에는 Pixel 5 모델이 표시되지만 uaFullVersion 힌트가 요청되지 않았으므로 여전히 축소된 92.0.0.0가 표시됩니다.

Mozilla/5.0 (Linux; Android 10.0; Pixel 5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.0.0 Mobile Safari/537.36

추가 지원

이러한 전략이 사용 사례에 적용되지 않는 경우 privacy-sandbox-dev-support 저장소에서 토론을 시작하면 문제를 함께 살펴볼 수 있습니다.

사진: 리카르도 로차(Unsplash 제공)