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

Re: [perpass] HTTP user-agent fingerprinting

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Fri, 13 Sep 2013 14:22:22 -0700
Message-ID: <CAA4WUYi=NqJjNFm1v=Qqa2bNSVcxz46=EpAHiTjiHB94fNXaNg@mail.gmail.com>
To: Patrick Pelletier <code@funwithsoftware.org>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, HTTP Working Group <ietf-http-wg@w3.org>, perpass@ietf.org
Speaking as a browser vendor, we do try to limit the info we send in the UA
string. It's sadly difficult. Please refer to
http://webaim.org/blog/user-agent-string-history/. Changing the UA string
breaks web compat, and when the end user's favorite site foo.com fails to
render in browser X, the end user switches to browser Y.

For a fairly recent discussion of this on the Chromium developer's mailing
list, feel free to refer to

On Fri, Sep 13, 2013 at 12:18 PM, Patrick Pelletier <
code@funwithsoftware.org> wrote:

> Forwarding this idea along to httpbis as you (Stephen) suggested.
>  Although this could be retrofitted onto existing HTTP, not just httpbis,
> since it's merely recommending practices which are already legal in HTTP.
> On Sep 13, 2013, at 5:17 AM, Stephen Farrell wrote:
>  On 09/13/2013 04:12 AM, Patrick Pelletier wrote:
>>> On 9/12/13 1:18 PM, Dave Crocker wrote:
>>>     "privacy properties of IETF protocols and concrete ways in which
>>>>     those could be improved."
>>> One obvious thing is the amount of (usually unnecessary) information
>>> leaked by the User-Agent field in HTTP.
>>> Should we downgrade the User-Agent field (section 14.43 of RFC 2616)
>>> from a SHOULD to a MAY?
>> I think everyone finds those values problematic, and not only for
>> privacy reasons. But yes, if you believe [1] then its probably the
>> biggest contributor to browser fingerprinting that's in an IETF
>> spec. (No idea if that site's evaluation is sound myself though.)
>>   [1] https://panopticlick.eff.org/
>>  Or, if that's too radical, should we standardize a small number of fixed
>>> strings to use in the User-Agent field?  (For example, "Desktop/1.0" for
>>> desktop browsers, "Mobile/1.0" for mobile browsers, "Text/1.0" for text
>>> browsers like Lynx, "Batch/1.0" for non-interactive clients like curl
>>> which are performing a task more specific than crawling the web, and
>>> "Robot/1.0" for clients which are crawling the web?)
>> Interesting. An IANA registry of those kinds of value might just end
>> up like the UA string though, which also started out nice and simple.
> I agree that things always start out simple and get messy.  However, I
> think there are some differences:
> * The original User-Agent field was not designed with privacy in mind.  In
> fact, it was designed specifically to identify the product and version the
> user is using.  So, with a different goal (privacy first), we will
> hopefully get different results.
> * By specifying only a single product token, omitting comments, and fixing
> the version number at 1.0, we've already eliminated a fair amount of
> information.  And then we further limit the information by making the
> product name not the actual name of the software, but merely a generic
> indication of the type of User-Agent; whatever is the minimal amount of
> information necessary for any legitimate browser sniffing that needs to
> occur.  (Such as differentiating desktop and mobile clients.)
> And, of course, using the simplified User-Agent strings was just one of my
> two proposals.  My other proposal, which was even simpler, though perhaps
> more radical, was to downgrade the requirement on User-Agent from SHOULD to
> MAY, and encourage browsers not to send User-Agent at all.  (We could even
> change it to a SHOULD NOT if we feel really heavy-handed.)  One could argue
> that by using other techniques such as responsive layout, no browser
> sniffing should be necessary at all.
>  Maybe ask this on httpbis if you don't get more feedback here? That's
>> where you'd find folks who know if it could be done and who could do
>> it.
> --Patrick
Received on Friday, 13 September 2013 21:22:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC