I don't think you can reliably tell without information from the network; indeed, to the extent that you can tell *at all* without information from the network, I would expect that to be considered a bug. The tactic that occurs to me is, have the investigative media website's server stick a marker of some sort into its webpages whenever it is being accessed from a Tor exit. That would avoid needing to load an additional network resource. However, I don't think I understand your threat model. Who observes the whistleblower, from where, and why wouldn't they just red-flag *all* use of Tor? On Sat, Feb 7, 2015 at 7:59 AM, Fabio Pietrosanti (naif) - lists <lists@infosecurity.ch> wrote:

Hi all,

we're introducing client-side checking if a user it's on Tor or not on the GlobaLeaks Javascript client.

As far as i understood since some time ago, the right way to do it was to detect a TBB user with some fingerprinting technique, however those are going to disappear/being avoided/fixed right?

So, the TorButton approach is to load https://check.torproject.org/?TorButton=true .

However we're looking for a way that enable to check if we are on Tor without having to load a network resource.

That's very important because there are use-case of GlobaLeaks where the application is being "integrated" into investigative media website (that are under HTTPS) and the Whistleblower is given "some plausible deniability" regarding the fact he's leaking something or visiting a news.

For that reason, we cannot check if a user it's on Tor by loading an external network resource such as https://check.torproject.org/?TorButton=true because it would destroy the plausible deniability things.

There's a right way to detect if a user it's on Tor, from a Browser, without loading an external network resource?

-- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi

_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

On Sat, Feb 07, 2015 at 01:59:05PM +0100, Fabio Pietrosanti (naif) - lists wrote:

we're introducing client-side checking if a user it's on Tor or not on the GlobaLeaks Javascript client.

So, the TorButton approach is to load https://check.torproject.org/?TorButton=true .

Note that the TorButton=true is just a parameter you can hand to check, to ask it to give you different strings on the results page (so it's easier to scrape the answer).

However we're looking for a way that enable to check if we are on Tor without having to load a network resource.

Good idea. The answer from check.tp.o is not 100% accurate anyway, for various reasons: http://tor.stackexchange.com/questions/190/why-does-check-torproject-org-som... So relying on it will result in a thin but steady stream of confused and worried users.

That's very important because there are use-case of GlobaLeaks where the application is being "integrated" into investigative media website (that are under HTTPS) and the Whistleblower is given "some plausible deniability" regarding the fact he's leaking something or visiting a news.

For that reason, we cannot check if a user it's on Tor by loading an external network resource such as https://check.torproject.org/?TorButton=true because it would destroy the plausible deniability things.

Ok.

There's a right way to detect if a user it's on Tor, from a Browser, without loading an external network resource?

Can you describe the scenario more? You have a browser that you don't control, and you hope the user configured it to point into Tor, and you want to automatically check if this is true? What software do you control? In the distant past, we had a ".noconnect" special extension in Tor: https://gitweb.torproject.org/torspec.git/tree/address-spec.txt#n58 and the idea was that you would connect to Tor's control port, induce a request for foo.noconnect, and see if you saw stream events for it. If you did, things were configured correctly. But we disabled .noconnect because we worried it could be used to notice Tor users in some way. And it sounds like that solution wouldn't work for you anyway, because if things *aren't* configured correctly, then your browser would generate a funny-looking request that everybody knows is a Globaleaks Tor check? --Roger