[tbb-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Feb 22 06:02:29 UTC 2016

#18361: Issues with corporate censorship and mass surveillance
     Reporter:  ioerror      |      Owner:  tbb-team
         Type:  enhancement  |     Status:  new
     Priority:  High         |  Milestone:
    Component:  Tor Browser  |    Version:
     Severity:  Critical     |   Keywords:  security, privacy, anonymity
Actual Points:               |  Parent ID:
       Points:               |    Sponsor:
 There are companies - such as CloudFlare - which are effectively now
 Global Active Adversaries. Using CF as an example - they do not appear
 open to working together in open dialog, they actively make it nearly
 impossible to browse to certain websites, they collude with larger
 surveillance companies (like Google), their CAPTCHAs are awful, they block
 members of our community on social media rather than engaging with them
 and frankly, they run untrusted code in millions of browsers on the web
 for questionable security gains.

 It would be great if they allowed GET requests - for example - such
 requests should not and generally do not modify server side content. They
 do not do this - this breaks the web in so many ways, it is incredible.
 Using wget with Tor on a website hosted by CF is... a disaster. Using Tor
 Browser with it - much the same. These requests should be idempotent
 according to spec, I believe.

 I would like to find a solution with Cloudflare - but I'm unclear that the
 correct answer is to create a single cookie that is shared across all
 sessions - this effectively links all browsing for the web. When tied with
 Google, it seems like a basic analytics problem to enumerate users and
 most sites visited in a given session.

 One way - I think - would be to create a warning page upon detection of a
 CF edge or captcha challenge. This could be similar to an SSL/TLS warning
 dialog - with an option for users to bypass, engage with their systems or
 an option to *contact them* or the *site's owners* or to hit a cached
 version, read only version of the website that is on archive.org,
 archive.is or other caching systems. That would ensure that *millions* of
 users would be able to engage with informed consent before they're tagged,
 tracked and potentially deanonymized. TBB can protect against some of this
 - of course - but when all your edge nodes are run by one organization
 that can see plaintext, ip addresses, identifiers and so on - the
 protection is reduced. It is an open research question how badly it is
 reduced but intuitively, I think there is a reduction in anonymity.

 It would be great to find a solution that allows TBB users to use the web
 without changes on our end - where they can solve one captcha, if required
 - perhaps not even prompting for GET requests, for example. Though in any
 case - I think we have to consider that there is a giant amount of data at
 CF - and we should ensure that it does not harm end users. I believe CF
 would share this goal if we explain that we're all interested in
 protecting users - both those hosting and those using the websites.

 Some open questions:
 * What kind of per browser session tracking is actually happening?
 * What other options do we have on the TBB side?
 * What would a reasonable solution look like for a company like
 * What is reasonable for a user to do? (~17 CAPTCHAs for one site == not
 * Would "Warning this site is under surveillance by Cloudflare" be a
 reasonable warning or should we make it more general?

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18361>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the tbb-bugs mailing list