Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Reading HTTP Client Hints

Reading HTTP Client Hints

This slide introduced RFC8942 HTTP Client Hints. This slide is based on my understanding for the RFC.

Tomoyuki KOYAMA

June 10, 2024
Tweet

More Decks by Tomoyuki KOYAMA

Other Decks in Technology

Transcript

  1. Introduction What is “User Agent” • HTTP servers select the

    appropriate response for a given request based on user agent’s characteristics. • User Agent is the HTTP request header. RFC 8942 HTTP Client Hints https://datatracker.ietf.org/doc/html/rfc8942 Smartphone PC HTTP 
 Servers 1. Request 2. Response 1. Request 2. Response $ curl -s -v https://www.mercari.com -o /dev/null > GET / HTTP/2 > Host: www.mercari.com > User-Agent: curl/8.4.0 > Accept: */* > Headers 2
  2. Introduction Variety of User Agents Hardware / OS User Agent

    iPhone + Safari Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X) AppleWebKit/ 605.1.15 (KHTML, like Gecko) Version/17.4.1 Mobile/15E148 Safari/604. Windows + Chrome Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 macOS + Chrome Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 Ref. https://www.useragents.me/ 2024-05-23 accessed 3
  3. Introduction Use-case: User Agent • Changing HTTP responses based on

    user agent allows for more appropriate content delivery. Smartphone PC HTTP 
 Servers 1. Request 2. Response 1. Request 2. Response PC websites Mobile websites User Agent: xxx User Agent: yyy HTTP 
 Servers 4
  4. Introduction Issue: User Agent • User Agent has following issues:

    • Performance: Increase the length of HTTP response headers
 
 • Privacy: Identify users by User Agent (especially minor hardware/OS) Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X) AppleWebKit/ 605.1.15 (KHTML, like Gecko) Version/17.4.1 Mobile/15E148 Safari/604. 138 bytes Ref. https://www.w3counter.com/globalstats.php 2024-05-23 accessed 5
  5. Client Hints Solution for performance and privacy (Sec.1) • Advertise

    server’s use of request headers for proactive content negotiation • Bene fi ts: • Mitigate performance concerns by limiting HTTP request headers sent • Mitigate privacy concerns for tracking 
 by requiring explicit opt-in and disclosure of required headers. • New HTTP response header “Accept-CH” • Currently in experimental status and NOT standards 6
  6. Client Hints Processing fl ow with Client Hints (Sec.2) •

    (Step1) User agents choose Client Hints based on “Default settings of Client Hints,” “User Con fi guration,” and “Server Preferences” • Opt-in mechanisms for negotiation (which header fi elds need to be sent) is described in Client Hints Infrastructure* Use Agent HTTP 
 Server Default settings of Client Hints User Con fi guration Server Preferences 1. Request 2. Response Accept-CH headers * Client Hints Infrastructure https://wicg.github.io/client-hints-infrastructure/ First time Client Hints 7
  7. Client Hints Processing fl ow with Client Hints (Sec.2) •

    (Step 2) When HTTP request (Request) includes Client Hints headers, HTTP server optimize HTTP response. • If the HTTP response is cacheable, HTTP server MUST includes a “Vary” header. • To indicate which Client Hints can a ff ect the selected HTTP response • To indicate ether the selected HTTP response is appropriate for a later request Use Agent HTTP 
 Server Client Hints 1. Request 2. Response Second time or later 8
  8. Note “Vary” header • HTTP response header “Vary” is de

    fi ned in RFC 7231* • Represents the information to decide HTTP response contents by HTTP request headers excluding HTTP Method, Host header, request target. • (Example)
 
 →Additional information to decide HTTP response contents: 
 accept-encoding, accept-language *RFC 7231 https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.4 Vary: accept-encoding, accept-language 9
  9. Client Hints Advertising Server use of request headers (Sec.3) •

    Accept-CH headers format in ABNF: • This header has a “Structured Header” which is de fi ned in RFC 8941*. • Example: • When a user agent receives an HTTP response containing Accept-CH, 
 the user agent is able to send an request which contains corresponding headers. • Whether a header is included in an HTTP request or not is persistent on the same origin. Accept-CH = sf-list Accept-CH: Sec-CH-Example, Sec-CH-Example-2 *RFC 8941 https://datatracker.ietf.org/doc/html/rfc8941#name-structured-data-types Use Agent HTTP Server Client Hints 1. Request 2. Response Vary: Sec-CH-Example, Sec-CH-Example-2 10
  10. Client Hints Security Considerations (Sec.4) • 4.1. Information Exposure •

    4.2. Deployment and Security Risks • 4.3. Abuse Detection 11
  11. Security Considerations 4.1. Information Exposure • Client Hints • Enable

    “privacy-preserving proactive content negotiation” (Vary header) • Avoid exposing information about passive fi ngerprinting vectors • Uncontrolled and unmonitored “privacy-preserving proactive content negotiation” has information exposure risks due to features abuse in Client Hints. • To prevent this abuse, user agents has to apply further policies to prevent abuse 12
  12. Security Considerations 4.1. Information Exposure • Implementers ought to consider

    following points to avoid information exposure. 13 “The underlying assumption is that exposing information about the user as a request header is equivalent (from a security perspective) to exposing this information by other means. (For example, if the request's origin can access that information using JavaScript APIs and transmit it to its servers.)” Use Agent
 (request’s origin) Servers Send information
 (display size, OS) 13 Get information (display size, OS) Assume user agents by received information
  13. Security Considerations 4.1. Information Exposure • Client Hints MUST NOT

    provide new information that is otherwise not made available to the application by the user agent, such as existing request headers, HTML, CSS, or JavaScript. • Client Hints enable “privacy-preserving proactive content negotiation” • Scripts such as Save-Data Client Hints* causes information exposure without increasing the passive fi ngerprinting surface. 14 * https://wicg.github.io/savedata/#save-data-request-header- fi eld Use Agent Servers User-Agent: chrome …
  14. Security Considerations 4.1. Information Exposure Consider following information: 1. Entropy


    “Exposing highly granular data can be used to help identify users across multiple requests to di ff erent origins.” 2. Sensitivity
 “information available to the application, but gated behind speci fi c user actions (e.g., a permission prompt or user activation), SHOULD NOT be exposed as a Client Hint.” 3. Change over time
 “The feature SHOULD NOT expose user information that changes over time, unless the state change itself is also exposed (e.g., through JavaScript callbacks).” 15
  15. Security Considerations 4.1. Information Exposure Implementers ought to consider: •

    “Implementers SHOULD restrict delivery of some or all Client Hints header fi elds to the opt-in origin only, unless the opt-in origin has explicitly delegated permission to another origin to request Client Hints header fi elds.” • “User agents MUST clear persisted opt-in preferences when any one of site data, browsing cache, cookies, or similar are cleared.” 16 Use Agent Server1 Request Client Hints Server2 Request Client Hints
  16. Client Hints Security Considerations (Sec.4) • 4.1. Information Exposure •

    4.2. Deployment and Security Risks • 4.3. Abuse Detection 17
  17. Security Considerations 4.2. Deployment and Security Risks Consideration for deployment

    of new request headers • Field name con fl icts between existing headers and Client Hints headers • User Agent behavior based on header fi eld name • User Agent prevents access to Sec- pre fi x on header fi eld name 
 from scripts or other app contents • Request header fi eld name for Client Hints ought to contain CH- pre fi x 18
  18. Client Hints Security Considerations (Sec.4) • 4.1. Information Exposure •

    4.2. Deployment and Security Risks • 4.3. Abuse Detection 19
  19. Security Considerations 4.3. Abuse Detection • “A user agent that

    tracks access to active fi ngerprinting information SHOULD consider emission of Client Hints headers similar to the way it would consider access to the equivalent API.” • In research, Compare HTTP response including Client Hints with other HTTP responses 20
  20. Security Considerations Cost of Sending Hints (Sec. 5) • Client

    Hints causes HTTP request byte increases • HTTP header compression mitigates HTTP request byte increases • “Servers SHOULD take that into account when opting in to receive Client Hints and SHOULD NOT opt-in to receive hints unless they are to be used for content adaptation purposes.” 21
  21. Reference • Improving user privacy and developer experience with User-Agent

    Client Hints | Privacy & Security | Chrome for Developers https:// developer.chrome.com/docs/privacy-security/user-agent-client-hints • RFC 8942 - HTTP Client Hints https://datatracker.ietf.org/doc/html/ rfc8942#name-cost-of-sending-hints • User-Agent Client-Hints https://www.chromium.org/updates/ua-ch/ 22