사용자 에이전트 축소란 무엇인가요?

사용자 에이전트 (UA) 축소는 수동 디지털 지문 수집에 사용될 수 있는 사용자 에이전트 문자열에서 공유되는 식별 정보를 최소화합니다. 이제 이러한 변경사항이 일반 안정화 버전으로 출시되었으므로 모든 리소스 요청의 User-Agent 헤더가 줄어듭니다. 따라서 navigator.userAgent, navigator.appVersion, navigator.platform를 포함한 특정 Navigator 인터페이스의 반환 값이 줄어듭니다.

웹 개발자는 사이트 코드에서 사용자 에이전트 문자열 사용을 검토해야 합니다. 사이트에서 사용자 에이전트 문자열을 파싱하여 기기 모델, 플랫폼 버전 또는 전체 브라우저 버전을 읽는 경우 User-Agent Client Hints API를 구현해야 합니다.

사용자 에이전트 클라이언트 힌트 (UA-CH)

사용자 에이전트 클라이언트 힌트를 사용하면 사용자 에이전트 데이터의 전체 집합에 액세스할 수 있지만 서버에서 특정 데이터 조각에 대한 명시적인 필요를 적극적으로 선언하는 경우에만 허용됩니다.

Google에서는 수동적으로 노출된 사용자 데이터를 삭제함으로써 요청 헤더, JavaScript API, 기타 메커니즘에서 의도적으로 노출되는 정보의 양을 더 효과적으로 측정하고 줄입니다.

UA 및 UA-CH를 줄여야 하는 이유는 무엇인가요?

지금까지 사용자 에이전트 문자열은 모든 HTTP 요청을 통해 사용자의 브라우저, 운영체제, 버전에 관한 대량의 데이터 문자열을 브로드캐스트했습니다. 이것이 문제가 되는 두 가지 이유는 다음과 같습니다.

  • 세밀하고 풍부한 세부정보를 통해 사용자를 식별할 수 있습니다.
  • 이 정보를 기본적으로 확인할 수 있기 때문에 은밀한 추적이 발생할 수 있습니다.

UA 및 UA-CH 축소는 기본적으로 기본 정보만 공유하여 사용자 개인 정보 보호를 개선합니다.

축소된 사용자 에이전트에는 브라우저의 브랜드와 요청이 발생한 주요 버전 (데스크톱 또는 모바일), 플랫폼이 포함됩니다. 더 많은 데이터에 액세스하기 위해 사용자 에이전트 클라이언트 힌트를 통해 사용자의 기기 또는 조건에 관한 구체적인 정보를 요청할 수 있습니다.

또한 시간이 지남에 따라 User-Agent 문자열이 더 길고 복잡해져서 오류가 발생하기 쉬운 문자열 파싱이 발생했습니다. UA-CH는 해석하기 쉬운 정형화되고 신뢰할 수 있는 데이터를 제공합니다. UA 문자열을 파싱하는 기존 코드는 손상되지 않아야 하며 (반환되는 데이터가 더 적음) 사이트에 특정 클라이언트 정보가 필요한 경우 UA-CH로 이전해야 합니다.

축소된 UA 및 UA-CH는 어떻게 작동하나요?

다음은 축소된 사용자 에이전트 문자열과 UA-CH가 작동하는 방식의 간단한 예입니다. 더 자세한 예는 사용자 에이전트 클라이언트 힌트를 통한 사용자 개인 정보 보호 및 개발자 환경 개선을 참고하세요.

사용자가 브라우저를 열고 주소 표시줄에 example.com를 입력합니다.

  1. 브라우저가 웹페이지를 로드하기 위한 요청을 보냅니다.

    1. 브라우저에는 축소된 사용자 에이전트 문자열이 있는 User-Agent 헤더가 포함됩니다. 예를 들면 다음과 같습니다. User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.0.0 Mobile Safari/537.36

    2. 브라우저의 기본 사용자 에이전트 클라이언트 힌트 헤더에 동일한 정보가 포함됩니다. 예를 들면 다음과 같습니다.

      Sec-CH-UA: "Chrome"; v="98"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"

  2. 서버는 Accept-CH 응답 헤더와 함께 기기 모델과 같은 추가 클라이언트 힌트를 전송하도록 브라우저에 요청할 수 있습니다. 예를 들면 다음과 같습니다. Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model

  3. 브라우저는 정책과 사용자 구성을 적용하여 후속 요청 헤더에서 서버로 반환할 수 있는 데이터를 결정합니다. 예를 들면 다음과 같습니다.

    Sec-CH-UA: "Chrome"; v="93"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Model: "Pixel 2"

중요한 클라이언트 힌트

초기 요청에 특정 클라이언트 힌트 세트가 필요한 경우 Critical-CH 응답 헤더를 사용할 수 있습니다. Critical-CH 값은 Accept-CH에서 요청한 값의 하위 집합이어야 합니다.

예를 들어 초기 요청에는 Device-Memory 및 Viewport-Width에 대한 요청이 포함될 수 있으며, 여기서 Device-Memory는 중요한 것으로 간주됩니다.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory, Viewport-Width
Vary: Device-Memory, Viewport-Width
Critical-CH: Device-Memory

브라우저에서 웹페이지를 제대로 렌더링하기 위해 중요한 힌트 (Critical-CH)를 요구하는 경우 서버는 Accept-CH 헤더를 사용하여 이 추가 정보를 요청할 수 있습니다. 그러면 브라우저가 중요한 힌트를 포함하여 페이지에 관한 새 요청을 보낼 수 있습니다.

요약하면 Accept-CH는 페이지에 원하는 모든 값을 요청하고 Critical-CH는 페이지를 올바르게 로드하기 위해 로드 시 필요한 값의 하위 집합만 요청합니다. 자세한 내용은 클라이언트 힌트 안정성 사양을 참고하세요.

UA-CH API로 태블릿 기기 감지

모바일, 태블릿, 데스크톱 기기 간의 경계가 점점 덜 뚜렷하고 동적 폼 팩터가 더 보편화되고 (접기 화면, 노트북과 태블릿 모드 간 전환) 반응형 디자인과 기능 감지를 사용하여 적절한 사용자 인터페이스를 제공하는 것이 좋습니다.

그러나 사용자-에이전트 문자열과 사용자-에이전트 클라이언트 힌트에 대해 브라우저에서 제공하는 정보는 동일한 소스에서 가져오므로 동일한 형태의 로직이 작동해야 합니다.

예를 들어 UA 문자열에서 이 패턴을 확인하는 경우 다음과 같습니다.

  • 전화 패턴: 'Android' + 'Chrome/[.0-9]* Mobile'
  • 태블릿 패턴: 'Android' + 'Chrome/[.0-9]* (?!Mobile)'

일치하는 기본 UA-CH 헤더 인터페이스를 확인할 수 있습니다.

  • 전화 패턴: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?1
  • 태블릿 패턴: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?0

또는 동등한 JavaScript 인터페이스:

  • 전화 패턴: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === true
  • 태블릿 패턴: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === false

하드웨어 관련 사용 사례의 경우 기기 모델 이름은 하이 엔트로피 Sec-CH-UA-Model 힌트를 통해 요청할 수 있습니다.

축소된 UA를 사용하고 테스트하려면 어떻게 해야 하나요?

시작하려면 사이트 코드를 검토하여 사용자 에이전트 문자열의 인스턴스 및 용도를 확인하세요. 사이트에서 사용자 에이전트 문자열을 파싱하여 기기 모델, 플랫폼 버전 또는 전체 브라우저 버전을 읽는 경우 UA-CH API를 구현해야 합니다.

UA-CH API로 업데이트한 후에는 User-Agent에서 원하는 데이터를 얻었는지 테스트해야 합니다. 테스트하는 방법에는 세 가지가 있으며 각각 복잡성이 증가합니다.

사용자 에이전트 축소를 위한 확장된 가용성은 모든 Chrome 기기에 제공되는 완전히 축소된 UA 문자열을 의미합니다. 성능 축소는 2022년 2분기 Chrome 부 버전으로 시작되었습니다

로컬에서 맞춤 문자열 테스트

맞춤 사용자 에이전트 문자열로 사이트를 테스트하여 다양한 기기를 시뮬레이션하려면 --user-agent="Custom string here" 명령줄 플래그를 사용하여 Chrome을 실행하세요. 여기에서 명령줄 플래그에 대해 자세히 알아보세요.

또는 Chrome DevTools에서 기기 에뮬레이터를 사용합니다.

사이트 코드의 문자열 변환

클라이언트 측 또는 서버 측 코드에서 기존 Chrome user-agent 문자열을 처리하는 경우 이 문자열을 새 형식으로 변환하여 호환성을 테스트할 수 있습니다. 문자열을 재정의 및 교체하거나 새 버전과 테스트를 나란히 생성하여 테스트할 수 있습니다.

클라이언트 힌트 및 중요 힌트 지원

브라우저 이름, 메이저 버전, 브라우저가 휴대기기에 있는지 나타내는 불리언, 운영체제 이름 등 3개의 기본 클라이언트 힌트가 서버에 반환됩니다. 전송 계층 보안 프로토콜 (TLS) 핸드셰이크 후에 전송됩니다. 이는 브라우저에서 이미 사용 가능하며 지원됩니다.

그러나 사이트를 렌더링하기 위해 중요한 정보를 가져와야 하는 경우가 있을 수 있습니다.

중요한 힌트 최적화

TLS 핸드셰이크는 브라우저와 웹 서버 간의 보안 연결을 만드는 첫 번째 단계입니다. 중요-CH 응답 헤더는 개입 없이 첫 번째 요청이 중요한 힌트 없이 전송된 경우 요청을 즉시 재시도하도록 브라우저에 지시하도록 설계되었습니다.

중요한 힌트가 포함된 클라이언트 힌트의 시퀀스 다이어그램
서버에서 중요한 힌트를 요청하면 클라이언트는 중요한 힌트가 있는 웹페이지에 대한 첫 번째 요청을 다시 보내 봅니다. 이 예에서 Sec-CH-UA-Model 힌트는 두 번 요청됩니다. 한 번은 Accept-CH가 있는 클라이언트 힌트로, 한 번은 Critical-CH가 있는 중요한 힌트로 요청됩니다.

중요한 힌트 (Critical-CH 헤더)를 최적화하려면 이 핸드셰이크를 가로채 클라이언트 힌트용 모델을 제공해야 합니다. 이러한 단계는 복잡할 수 있으며 고급 지식이 필요합니다.

ACCEPT_CH HTTP/2 및 HTTP/3 프레임은 TLS ALPS 확장 프로그램과 함께 첫 번째 HTTP 요청에 시간에 맞춰 서버의 클라이언트 힌트 환경설정을 제공하기 위한 연결 수준 최적화입니다. 이를 위해서는 복잡한 구성이 필요하며, 정말 중요한 정보에만 사용하는 것이 좋습니다.

BoringSSL (OpenSSL의 포크)을 사용하면 Chromium에서 Google의 실험적 기능을 사용할 수 있습니다. 현재 ALPS는 BoringSSL로만 구현됩니다.

중요한 힌트를 사용해야 하는 경우 중요한 힌트 안정성 및 최적화에 관한 가이드를 참고하세요.

FAQ

Accept-CH 헤더를 통해 지정된 힌트는 얼마 동안 전송되나요?

Accept-CH 헤더를 통해 지정된 힌트는 브라우저 세션 동안 또는 다른 힌트 세트가 지정될 때까지 전송됩니다.

UA-CH는 HTTP/2 및 HTTP/3에서 작동하나요?

UA-CH는 HTTP/2 및 HTTP/3 연결 모두에서 작동합니다.

하이 엔트로피 UA-CH에 액세스하려면 하위 도메인 (및 CNAME)에 최상위 페이지 Permissions-Policy가 필요한가요?

요청 헤더의 높은 엔트로피 UA-CH는 출처가 DNS 측에서 정의된 방식에 관계없이 교차 출처 요청에서 제한됩니다. 위임은 교차 출처 하위 리소스의 경우 Permissions-Policy를 통해 처리하거나 교차 출처 컨텍스트에서 실행되는 자바스크립트를 통해 가져와야 합니다.

사용자 에이전트 축소가 봇 감지에 어떤 영향을 미치나요?

Chrome의 사용자 에이전트 문자열 변경사항은 봇이 전송하는 사용자 에이전트 문자열에 직접적인 영향을 미치지 않습니다.

봇은 Chrome에서 전송하는 정보 중 축소된 정보를 반영하도록 자체 문자열을 업데이트할 수 있지만, 이는 전적으로 봇의 구현 선택입니다. Chrome은 여전히 동일한 사용자-에이전트 형식을 전송하고 있으며 Chrome 사용자-에이전트 문자열 끝에 자체 식별자를 추가하는 봇은 계속 전송할 수 있습니다.

특정 봇과 관련된 우려사항의 경우 소유자에게 직접 문의하여 사용자 에이전트 문자열을 변경할 계획이 있는지 문의하는 것이 좋습니다.

참여 및 의견 공유

자세히 알아보기