[tbb-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Feb 22 07:46:42 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 | Resolution:
Keywords: security, privacy, anonymity | Actual Points:
Parent ID: | Points:
Comment (by ioerror):
Replying to [comment:10 marek]:
> @ioerror: you are doing this again. You are mixing your opinions with
technical reality. Please stop insulting me. Please focus on what can we
can technically do to fix the problem.
I'm unclear on what I've said or done that is insulting you? Could you
clarify? It certainly isn't my attempt or intent to insult you.
What is my opinion and what is technical reality? Could you enumerate that
a bit? I've asked many questions and it is important that we discuss the
wide range of topics here.
> > Here is a non-cryptographic, non-cookie based solution: Never prompt
for a CAPTCHA on GET requests.
> There are a number of problems with this model.
There are a number of problems with the current model - to be clear - and
so while there are downsides to the read-only GET suggestion, I think it
would reduce nearly all complaints by end users.
> (POST is hard) First, what actually the proxy should *do* on the POST?
Abort your POST, serve captcha, and ask you to fill the POST again? Or
accept your 10meg upload, serve captcha and ask you to upload it again?
Now think about proxy behaviour during an attack. Doing captcha validation
on POST is not a trivial thing.
Off the top of my head - to ensure I reply to everything you've written:
It seems reasonable in many cases to redirect them on pages where this is
a relevant concern? POST fails, failure page asks for a captcha solution,
> (blocking regions) Second, during an "attack" (call it ddos or
something) the website owners often decide to block traffic from ceirtain
regions. Many businesses care only about visitors from some geographical
region, and in case of a DDoS are happy to just DROP traffic from other
regions. This is not something to like or dislike. This is a reality for
many website owners. Serving captcha is strictly better than disallowing
the traffic unconditionally.
Actually, a censorship page with specific information ala HTTP 451 would
be a nearly in spec answer to this problem. Why not use that? You're
performing geographic discrimination on behalf of your users - this
censorship should be transparent. It should be clear that the site owner
has decided to do this - and there is less of a need to solve a captcha by
Though in the case of Tor - you can't do this properly - which is a reason
to specifically treat Tor users as special. Visitors may be in the region
and Tor is properly hiding them. That is a point in the direction of
having an interstitial page that allows a user to solve a captcha.
> (Not only spam, load as well) Third, there regularly are bot "attacks"
that just spam website with continous flood of GET requests, for example
to check if the offered product is released, the promotion started or
price updated. This is a problem for some website owners and they wish to
allow only traffic from vetted sessions.
Why not just serve them an older cached copy?
> The underlying problem, is that for any ddos / spam protection system
the source IP address is a very strong signal. Unfortunately many Tor exit
IP's have bad IP reputation, because they _ARE_ often used for unwanted
Do you have any open data on this?
> > What sort of data would qualify as an 'i'm a human' bit?
> Let's start with something not-worse than now: a captcha solved in last
This feels circular - one of the big problems is that users are unable to
solve them after a dozen tries. We would not have as many complaining
users if we could get this far, I think.
> > This sounds very much like something that could be provided through
the use of zero-knowledge proofs
> Yup. What do we do to implement one both on ddos protection side and on
My first order proposition would be to solve a cached copy of the site in
"read only" mode with no changes on the TBB side. We can get this from
other third parties if CF doesn't want to serve it directly - that was
part of my initial suggestion. Why not just serve that data directly?
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18361#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs