HTTP 클라이언트 힌트

이 문서에서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 모두 대문자로 표시될 때에만 BCP 14의 설명대로 해석되어야 합니다. 자세한 내용은 [RFC2119] 및 [RFC8174]를 참조하십시오.

이 문서는 Augmented Backus-Naur Form(ABNF) 표기법을 사용합니다(참조: [RFC5234]).

사용자 에이전트는 기본 설정, 사용자 구성 및 서버가 Accept-CH에 표현한 선호에 근거하여 요청에서 어떤 Client Hints를 보낼지 선택합니다. 사용자 에이전트와 서버는 아래에 설명된 옵트인 메커니즘을 사용하여 효율적인 콘텐츠 적응을 위해 어떤 헤더 필드를 전송해야 하는지를 협상할 수 있으며, 선택적으로 추가 메커니즘(예: [CLIENT-HINTS-INFRASTRUCTURE]에 설명된 것)을 사용하여 제3자가 동일한 헤더 필드에 접근하는 권한을 제어하는 위임 정책을 협상할 수 있습니다. 사용자 에이전트는 낮은 엔트로피로 간주되지 않는 힌트를 전송하기 위해 옵트인을 요구해야 합니다(EMPHASIS: SHOULD). 낮은 엔트로피 힌트의 예는 [CLIENT-HINTS-INFRASTRUCTURE]의 표를 참조하십시오.

구현자는 Client Hints 지원을 구현할 때 지문 수집(fingerprinting) 영향에 대해 인지하고 이 문서의 보안 고려사항 섹션(섹션 4)을 준수해야 합니다.

하나 이상의 Client Hints 헤더 필드를 포함하는 요청이 제시되면, 서버는 그 안의 정보를 기반으로 응답을 최적화할 수 있습니다. 그렇게 할 때, 그리고 리소스가 캐시 가능하다면, 서버는 어떤 힌트가 선택된 응답에 영향을 줄 수 있고 선택된 응답이 이후 요청에 적합한지 여부를 나타내기 위해 Vary 응답 헤더 필드(RFC7231 섹션 7.1.4)를 생성해야 합니다(EMPHASIS: MUST).

서버는 자신이 이해하거나 지원하지 않는 힌트를 무시해야 합니다(EMPHASIS: MUST). 무시된 힌트를 사용자 에이전트에 알리는 메커니즘은 없습니다.

또한 서버는 클라이언트 처리를 돕기 위해(해당 힌트에 의해 지정된 대로) 관련 값을 전달하는 추가 응답 헤더 필드를 생성할 수 있습니다.

Accept-CH 응답 헤더 필드는 그 값에 표시된 힌트들에 대한 서버의 지원을 나타냅니다. 사용자 에이전트 정보를 Client Hints를 통해 수신하기를 원하는 서버는 가능한 한 빨리 응답에 Accept-CH 응답 헤더를 추가해야 합니다(EMPHASIS: SHOULD).

  Accept-CH = sf-list

Accept-CH: Sec-CH-Example, Sec-CH-Example-2

사용자 에이전트가 Accept-CH를 포함한 HTTP 응답을 수신하면, 이는 해당 원본(origin)이 이후 동일 출처(same-origin) 요청들에 대해 표시된 요청 헤더 필드들을 수신하도록 옵트인했음을 나타냅니다. 옵트인은 비보안 전송(HTTPS가 아닌 스킴을 사용하는 경우)으로 전달된 경우 무시되어야 합니다(EMPHASIS: MUST). 옵트인은 지속되어야 하며 사용자 에이전트가 정의하는 세션 기간 동안 원본에 바인딩되어 이후 요청에서 Client Hints를 전달할 수 있어야 합니다(EMPHASIS: SHOULD). 새로운 옵트인은 이전에 지속된 옵트인 값을 덮어쓰며 대신 지속되어야 합니다(EMPHASIS: SHOULD).

위의 Accept-CH 예는 사용자 에이전트가 "https://site.example"로 네비게이션한 응답으로 수신되었고 안전한 전송으로 전달되었다고 가정하면, 지속된 Accept-CH 선호는 "https://site.example"에 바인딩됩니다. 이후 예를 들어 "https://site.example/foobar.html"로의 네비게이션에 대해서는 사용되지만, 예를 들어 "https://foobar.site.example/"에는 사용되지 않습니다. 또한 네비게이션 응답으로 구성된 페이지에서 시작된 동일 출처 리소스 요청(예: "https://site.example/image.jpg")에는 이 선호를 사용하지만, 교차 출처 리소스 요청(예: "https://thirdparty.example/resource.js")에는 사용하지 않습니다. 이 선호는 다른 출처에서 "https://site.example"로 시작된 리소스 요청(예: "https://other.example/"로의 네비게이션에서 시작된 요청)으로 확장되지 않습니다.

하나 이상의 Client Hints에 따라 응답을 선택할 때, 그리고 리소스가 캐시 가능하다면 서버는 어떤 힌트가 선택된 응답에 영향을 줄 수 있고 선택된 응답이 이후 요청에 적합한지 여부를 나타내기 위해 Vary 응답 헤더 필드([RFC7234])를 생성해야 합니다.

Vary: Sec-CH-Example

위 예시는 캐시 키에 Sec-CH-Example 헤더 필드를 포함해야 함을 나타냅니다.

Vary: Sec-CH-Example, Sec-CH-Example-2

위 예시는 캐시 키에 Sec-CH-Example 및 Sec-CH-Example-2 헤더 필드를 포함해야 함을 나타냅니다.

이 문서에 의존하는 기능에서 사용되는 요청 헤더 필드는 개인정보를 보호하는 선제적 콘텐츠 협상을 가능하게 하고 수동적 지문 수집 벡터를 노출하지 않기 위해 사용자의 환경에 대한 정보를 노출합니다. 그러나 구현자는 최악의 경우 통제되지 않고 모니터링되지 않은 능동적 지문 수집이 수동적 지문 수집보다 나을 수 없다는 점을 염두에 두어야 합니다. 사용자에게 개인정보 이점을 제공하려면 사용자 에이전트는 Client Hints를 사용하는 기능이 노출하는 정보를 남용하지 못하도록 추가 정책을 적용해야 합니다.

기능이 노출하는 정보는 사용자에 대해 새로운 정보를 드러낼 수 있으므로 구현자는 다음의 고려사항, 권장 사항 및 모범 사례를 고려해야 합니다.

기본 가정은 요청 헤더로 사용자의 정보를 노출하는 것이 보안 관점에서 애플리케이션이 다른 수단으로 해당 정보를 얻는 것(예: JavaScript API를 통해 접근하여 서버로 전송하는 경우)과 동등하다는 것입니다.

Client Hints는 명시적 옵트인 메커니즘이므로, 사용자 환경에 대한 정보에 접근하기를 원하는 서버는 이를 적극적으로 요청해야 하며, 이는 클라이언트와 개인정보 연구원들이 어떤 원본이 해당 데이터를 수집하는지 추적하고 잠재적으로 대응할 수 있게 합니다. 헤더 기반 옵트인은 수동적 지문 수집 벡터의 제거를 가능하게 합니다. 예를 들어, 사용자 에이전트는 User-Agent 문자열로 노출되는 정보를 줄이는 대신 User-Agent Client Hints를 통해 해당 정보에 대한 능동적 접근을 가능하게 할 수 있습니다. 또는 사용자는 이미 스크립트를 통해 사용할 수 있는 정보를(예: Save-Data Client Hints <https://wicg.github.io/savedata/#save-data-request-header-field>) 헤더로 노출하되 수동적 지문 표면을 증가시키지 않을 수 있습니다. Client Hints 기능을 지원하는 사용자 에이전트는 특정 정보가 옵트인한 서버로 전송될 때 동등한 정보를 수동적으로 전송하지 않도록 해야 합니다(EMPHASIS: SHOULD).

따라서 이 문서에 의존하여 Client Hint 헤더를 정의하는 기능은 애플리케이션에 사용자 에이전트를 통해 이미 제공되지 않는 새로운 정보를 제공해서는 안 됩니다(예: 기존 요청 헤더, HTML, CSS 또는 JavaScript에서 제공되는 정보). 이는 금지되어야 합니다(EMPHASIS: MUST NOT).

엔트로피:

매우 세분화된 데이터를 노출하면 서로 다른 원본에 대한 여러 요청에서 사용자를 식별하는 데 사용될 수 있습니다. 표현될 수 있는 헤더 필드 값의 집합을 줄이거나, 광고된 값이 현재 값을 정확히 나타내지 않고 근사치가 되도록 열거형 범위로 제한하면 프라이버시를 개선하고 링크 가능성(linkability) 위험을 줄일 수 있습니다.

민감도:

기능은 사용자 민감 정보를 노출해서는 안 됩니다(EMPHASIS: SHOULD NOT). 예를 들어 특정 사용자 행위(권한 프롬프트나 사용자 활성화 등)에 의해 제공되는 정보는 Client Hint로 노출되어서는 안 됩니다(EMPHASIS: SHOULD NOT).

시간에 따른 변경:

기능은 시간이 지남에 따라 변경되는 사용자 정보를 노출해서는 안 됩니다(EMPHASIS: SHOULD NOT), 단 상태 변경 자체가 또한 노출되는 경우(예: JavaScript 콜백을 통해)에는 예외일 수 있습니다.

다양한 기능은 낮은 엔트로피·비민감·정적 정보(예: 사용자 에이전트 정보)와 높은 엔트로피·민감·동적 정보(예: 지리 위치) 사이의 스펙트럼에서 서로 다른 위치에 놓일 것입니다. 사용자 에이전트는 특정 기능이 제공하는 가치와 이러한 고려사항을 비교하여 기능별 또는 다른 세분화된 기준에 따라 서로 다른 정책을 가질 수 있습니다.

• 구현자는 일부 또는 모든 Client Hints 헤더 필드의 제공을 옵트인된(origin) 원본에만 제한해야 합니다(EMPHASIS: SHOULD), 단 옵트인 원본이 명시적으로 다른 원본에 Client Hints 헤더 필드를 요청할 권한을 위임한 경우는 예외입니다.
• 개인정보와 대역폭 제한을 균형있게 고려할 수 있도록 사용자 선택 메커니즘을 제공하는 구현자는 수동적 지문 수집의 위험과 같은 개인정보 영향에 대해 사용자가 이해하도록 설명하는 것이 어렵거나 실용적이지 않을 수 있음을 고려해야 합니다.
• 특정 사용 사례나 위협 모델에 특화된 구현은 일부 또는 모든 Client Hints 헤더 필드의 전송을 피할 수 있습니다(MAY). 예를 들어 링크 가능성(linkability) 위험이 더 높은 헤더 필드의 전송을 회피할 수 있습니다.

사용자 에이전트는 사이트 데이터, 브라우징 캐시, 쿠키 또는 유사 항목이 지워질 때 지속된 옵트인 선호를 반드시 지워야 합니다(EMPHASIS: MUST).

• 헤더 필드 이름의 기존 사용과 인한 잠재적 충돌
• 헤더 필드 값으로 전달되는 데이터의 속성

새로운 Client Hints의 작성자는 클라이언트 측 콘텐츠(예: 스크립트)에 의해 추가될 필요가 있는지, 아니면 Client Hints가 사용자 에이전트에 의해 독점적으로 설정되어야 하는지를 신중히 고려해야 합니다. 후자의 경우 헤더 필드 이름에 Sec- 접두사를 사용하면 스크립트 및 다른 애플리케이션 콘텐츠가 사용자 에이전트에서 이를 설정하는 것을 방지하는 효과가 있습니다. "Sec-" 접두사를 사용하면 헤더 값이 사용자 에이전트에 의해 생성되었음을 서버에 신호로 보냅니다. 자세한 내용은 [FETCH]를 참조하십시오.

관례상 Client Hints인 요청 헤더는 이 프레임워크를 사용함을 더 쉽게 식별하기 위해 CH- 접두사를 사용하도록 권장됩니다. 예: CH-Foo 또는 "Sec-" 접두사를 포함한 Sec-CH-Foo. 이렇게 하면 프로그래밍 방식으로 식별하기 쉬워져(예: 프라이버시 필터가 인식되지 않은 힌트를 요청에서 제거하는 경우) 유용합니다.

Accept-CH 옵트인 메커니즘으로 협상된 Client Hints 요청 헤더는 필드 이름이 sf-token과 일치해야 합니다(EMPHASIS: MUST).

능동적 지문 수집 정보에 대한 접근을 추적하는 사용자 에이전트는 Client Hints 헤더의 발신을 동등한 API 접근으로 간주하는 것을 고려해야 합니다(EMPHASIS: SHOULD).

Client Hints의 남용 연구는 Client Hints를 포함한 요청에 대한 HTTP 응답이 다른 값 또는 값이 없는 경우의 응답과 어떻게 다른지를 조사할 수 있습니다. 이는 어떤 Client Hints가 사용되는지를 밝히는 데 사용되어 연구자들이 추가 분석을 수행할 수 있게 합니다.

헤더 필드 이름:

Accept-CH

적용 프로토콜:

HTTP

상태:

experimental

작성자/변경 컨트롤러:

IETF

명세 문서:

이 RFC의 섹션 3.1

관련 정보:

Client Hints 관련