Opened 12 months ago

Closed 12 months ago

Last modified 11 months ago

#27495 closed defect (duplicate)

Tor Browser 8.0 wrong user-agent

Reported by: temp123 Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor Browser 8.0 does not set user agent properly.

general.useragent.override = Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0

User agent shown using https://httpbin/user-agent = Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Expected behavior:
User agent should match the general.useragent.override string and should not reveal OS details

Additional details:
OS is Arch Linux. Installed via AUR package tor-browser-en. New install. No settings changed.

Child Tickets

Change History (7)

comment:1 Changed 12 months ago by arma

Component: - Select a componentApplications/Tor Browser
Owner: set to tbb-team
Version: Tor: unspecified

comment:2 Changed 12 months ago by arma

This ticket makes a good point that the useragent is actually set to Windows in my about:config, so it sure looks like it's *trying* to set the useragent, it's just not actually setting it correctly (or using it).

(I hear from the tor browser devs that they are no longer trying to lie about user agent, (a) because you can't actually convincing lie, because there are so many other components that would have to change too, and (b) because when Android enters the scene, they won't want to get served the non-mobile version of pages. But I think there are still some arguments in favor of setting the useragent to Windows for the desktop version: passive website logs only look at user-agent for one, and when the openbsd people get their Tor Browser going they'll sure stand out. Oh and a third reason is the flood of people who keep thinking there's a bug to report. :)

comment:3 Changed 12 months ago by sysrqb

Resolution: duplicate
Status: newclosed

There are some argument on #26146 about this. I'll close this as a dup, but please re-open if this is actually different.

comment:4 in reply to:  2 Changed 12 months ago by gk

Replying to arma:

This ticket makes a good point that the useragent is actually set to Windows in my about:config, so it sure looks like it's *trying* to set the useragent, it's just not actually setting it correctly (or using it).

That's #26146.

(I hear from the tor browser devs that they are no longer trying to lie about user agent, (a) because you can't actually convincing lie, because there are so many other components that would have to change too, and (b) because when Android enters the scene, they won't want to get served the non-mobile version of pages. But I think there are still some arguments in favor of setting the useragent to Windows for the desktop version: passive website logs only look at user-agent for one, and when the openbsd people get their Tor Browser going they'll sure stand out. Oh and a third reason is the flood of people who keep thinking there's a bug to report. :)

I don't think the third argument is a valid one. Just because an amount of (5?, 10?, 1.000?) X people think Y is a bug Y is a bug. The second one is neither valid: openbsd and other non macOS *NIXes get a Linux UA. There are only fixed UAs for Windows, macOS, Linux, and Android. So, this leaves the first one. Sure, there is a trade-off to be made here. While upstreaming (and before) we and Mozilla had reports that this UA spoofing actually breaks Tor Browser. Not only is it more than confusing to get always a random .exe file offered for download even though you are not on Windows but things like Google apps were actually broken for macOS users (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1405810)
We had https://lists.torproject.org/pipermail/tbb-dev/2017-October/000642.html ff. for the discussion.
So, I think at least for macOS the breakage is not worth the Windows UA.

Last edited 11 months ago by gk (previous) (diff)

comment:5 in reply to:  2 Changed 12 months ago by cypherpunks3

We use Tor.

Last edited 12 months ago by cypherpunks3 (previous) (diff)

comment:6 in reply to:  2 Changed 12 months ago by cypherpunks3

Replying to arma:

This ticket makes a good point that the useragent is actually set to Windows in my about:config, so it sure looks like it's *trying* to set the useragent, it's just not actually setting it correctly (or using it).

(I hear from the tor browser devs that they are no longer trying to lie about user agent, (a) because you can't actually convincing lie, because there are so many other components that would have to change too, and (b) because when Android enters the scene, they won't want to get served the non-mobile version of pages. But I think there are still some arguments in favor of setting the useragent to Windows for the desktop version: passive website logs only look at user-agent for one, and when the openbsd people get their Tor Browser going they'll sure stand out. Oh and a third reason is the flood of people who keep thinking there's a bug to report. :)

The first issue is the most severe. I do not want to be the only person in the website logs who is shown as using Linux. The fix is so easy. Is there any way we can correct this? Should I be installing a browser extension to force the user agent? (not the same cypherpunks3 as above)

Last edited 12 months ago by cypherpunks3 (previous) (diff)

comment:7 Changed 12 months ago by H7gQsKnpvf3nB7NWYtdhtDyECtySfgyx

A troll vandalized my comment with "We use Tor." so I'm going to replicate my earlier comment with a different account:

Replying to arma:

(I hear from the tor browser devs that they are no longer trying to lie about user agent, (a) because you can't actually convincing lie,

1) Not everyone does OS detection with JS, so the trackers who use the UA only (i.e. without JS detection) are duped, 2) with JS disabled there's no reliable way to tell exactly the OS (except some CSS bugs from now and then),

because there are so many other components that would have to change too,

3) these elements can be changed too in the long term (search for a keyword that sounds like tbb-fingerprinting-os or something). We can have fantastic dreams, right?

and (b) because when Android enters the scene, they won't want to get served the non-mobile version of pages.

Mobile vs desktop distinction is justifiable, and it entails nothing for the case we're dealing with here.

Replying to gk:

Not only is it more than confusing to get always a random .exe file offered for download even though you are not on Windows but things like Google apps were actually broken for macOS users (see: ​https://bugzilla.mozilla.org/show_bug.cgi?id=1405810)

This is kinda ironic considering that logging into your Google account to use Google Docs with Tor is straight-up *impossible* unless one does the SMS verification - or partial de-anonymization to put it in another fashion (except for the folks who buy SMS boxes with Bitcoin). So we're doing trading-off a situation that only a very limited number of Mac OS (marketshare is low) *and* Tor users encounter for the global Tor populace (the reports come from a standard Firefox for a reason)? This is even more ironic considering the amount of voluntary breakage that Google makes on its websites and services for the standard Firefox and Firefox Mobile, let alone the Tor Browser (recent examples in mind: YouTube uses an old standard not implemented in Firefox which leads to 5-10sec of delay on Firefox vs Chrome, the Google search looked different for Firefox Mobile vs Chrome Mobile and would change with a simple UA change to Chrome Mobile's UA). In other words trading privacy for hostile Google's usability shouldn't be even on our imagination.

(Another comment:) By the way this is a bad precedent from the great folks over there at Mozilla, first party isolation breaks a lot of websites - should we then whitelist it for those? Why should we treat first party isolation and fingerprinting resistance differently?

Note: See TracTickets for help on using tickets.