User-Agent in torcheck

added component::applications/tor check priority::medium reporter::sanren resolution::fixed status::closed type::enhancement labels

Replying to sanren:

It would be nice, if there was user-agent shown on main torcheck page. For example: https://torcheck.xenobite.eu/ It would be quite useful, I think.

Curious, why would you find this useful?

I assume it's so torcheck can help you with your application-level privacy decisions too.

I think our best bet here, if we want to do it, is to identify our favorite such page and include a link. But I'm not sure that's needed.

More generally, if we were to do anything about application-level privacy on check, I'd want to do a Torbutton detector, so it can yell at you if you show up using Iceweasel or IE or the like. I think such a detector is designed to be hard to make you 100% accurate, but we could still get pretty good by just comparing user-agent with the user-agents in currently-recommended TBBs.

Trac:
Cc: N/A to mikeperry, erinn

Yes, it would be better, if torcheck shows alert message if useragent contains uncommon information such as nightly build, or non-standard user-agent. I created this proposal after I'd used orweb from my smartphone. This browser has issue with user-agent by default, using default's browser user-agent string. This string contains sensitive information, such as os information, nightly build information and so on. I understand, that it is bug in orweb, but we can warn tor users if they meet this problem. Also, you can look at http://panopticlick.eff.org.

Trac:
Username: sanren

Replying to sanren:

Yes, it would be better, if torcheck shows alert message if useragent contains uncommon information such as nightly build, or non-standard user-agent. I created this proposal after I'd used orweb from my smartphone. This browser has issue with user-agent by default, using default's browser user-agent string. This string contains sensitive information, such as os information, nightly build information and so on. I understand, that it is bug in orweb, but we can warn tor users if they meet this problem.

I don't think there's a good reason why Tor should branch out into maintaining one of these pages. Perhaps we should find our favorite page that somebody else maintains, and point to that?

Replying to arma:

More generally, if we were to do anything about application-level privacy on check, I'd want to do a Torbutton detector, so it can yell at you if you show up using Iceweasel or IE or the like. I think such a detector is designed to be hard to make you 100% accurate, but we could still get pretty good by just comparing user-agent with the user-agents in currently-recommended TBBs.

In #1940 (moved) you seemed to be saying wontfix. We can do something very coarse grained like,

 if (!(/Firefox/gi).test(window.navigator.userAgent)) yell!

to catch the obvious cases.

Users are configuring their Safari/IE browser to proxy through Tor, then visit check.tpo and see a happy message that they are using Tor successfully. Even if a user agent check wouldn't detect everyone who did this, getting a warning message to some people would help deter this behavior.

I don't think there is a good way of noticing the difference between someone using their browser's proxy settings and some using a Tor router. I'm not sure if we care about this difference or not.

Took the approach of warning if the user agent doesn't match the set of known TBBs.

Closed with https://gitweb.torproject.org/check.git/commit/9162164ad821bcebd4cf79d25bae6965128643d4

Trac:
Resolution: N/A to fixed
Status: new to closed

This approach means we're going to have false positives when TBB moves to the next Firefox ESR, and eventually somebody will open a ticket, and eventually we'll update it, and then we do the cycle again on the next ESR?

Maybe a regexp to handle the upcoming expected ESRs will avoid this cycle?

Replying to arma:

This approach means we're going to have false positives when TBB moves to the next Firefox ESR, and eventually somebody will open a ticket, and eventually we'll update it, and then we do the cycle again on the next ESR?

Maybe a regexp to handle the upcoming expected ESRs will avoid this cycle?

Fixed in https://gitweb.torproject.org/check.git/commit/cdd86d2119ed4548c5785134c6c461d0eca94e79

Oddly, I had done this for flashproxy but dcf asked me not to ... https://trac.torproject.org/projects/tor/ticket/11290#comment:1

Replying to arlolra:

Oddly, I had done this for flashproxy but dcf asked me not to ... https://trac.torproject.org/projects/tor/ticket/11290#comment:1

I think in the flashproxy case a wrong classification is ok, since it just causes you to try to be a flashproxy even though it won't work very well. But in this case thinking you're not Tor when you are will result in a misleading warning to the user. So I think they are different situations. Do you buy it?

Replying to arma:

Do you buy it?

Sold.

closed

mentioned in issue #11666 (moved)

User-Agent in torcheck

Child items ...

Activity