W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

[#232] User-Agent Guidelines (proposal)

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 20 Sep 2010 19:14:48 +1000
Message-Id: <1958A21D-F2B6-4AFF-8057-E83FDF160F22@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/232>

UA strings have become quite long, which makes requests bigger than necessary, can reveal too much information about the user (including allowing them to be "fingerprinted"), and potentially can encourage inappropriate sniffing.

Guidance should be provided regarding what's appropriate / inappropriate in a UA string, and the privacy aspect should be added to Security Considerations.

See also:

 https://bugzilla.mozilla.org/show_bug.cgi?id=572650 
 http://blogs.msdn.com/b/ie/archive/2010/03/23/introducing-ie9-s-user-agent-string.aspx 
 https://panopticlick.eff.org/

Current text <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-11#section-9.9>:

---8<---

The "User-Agent" request-header field contains information about the user agent originating the request.  This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations.

User agents SHOULD include this field with requests.  The field can contain multiple product tokens (Section 6.3 of [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent and any subproducts which form a significant part of the user agent.  By convention, the product tokens are listed in order of their significance for identifying the application.

--->8---

Proposal:

---8<---

The "User-Agent" request-header field contains information about the user agent originating the request.  User agents SHOULD include this field with requests.  

Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular user agent limitations.

The field can contain multiple product tokens (Section 6.3 of [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent and its significant subproducts.  By convention, the product tokens are listed in order of their significance for identifying the application.

Because this field is usually sent on every request a user-agent makes, implementations are encouraged not to include needlessly fine-grained detail, and to limit (or even prohibit) the addition of subproducts by third parties. Overly long and detailed User-Agent field values make requests larger and can also be used to identify ("fingerprint") the user against their wishes.

Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility with them, as this circumvents the purpose of the field. Finally, they are encouraged not to use comments to identify products; doing so makes the field value more difficult to parse.

--->8---

Current text <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-11#section-11.1>:
  
---8<---

The User-Agent (Section 9.9) or Server (Section 9.8) header fields can sometimes be used to determine that a specific client or server have a particular security hole which might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has no better mechanism.

--->8---

Proposal: 

---8<---

The User-Agent (Section 9.9) or Server (Section 9.8) header fields can sometimes be used to determine that a specific client or server have a particular security hole which might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has no better mechanism.

Furthermore, the User-Agent (Section 9.9) header field may contain enough entropy to be used, possibly in conjunction with other material, to uniquely identify the user.

--->8---



--
Mark Nottingham     http://www.mnot.net/
Received on Monday, 20 September 2010 09:15:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:25 GMT