[tbb-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Feb 22 22:23:00 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 lhi):
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.
??? where did ioerror insult you? I looked hard and the only thing I could
find is discussions about "human bits" and spurious distinctions between
tech and politics, which might be construed as insulting our intelligence.
technology is politics and politics is technology in times of mass
surveillance and big data, and so is corporate policy that discourages
anonymity and defines legitimate behavior. no one brought politics into
this except that it was there from the beginning. sorry for being rude. I
am angry about all the CAPTCHAs I have seen.
I also think this discussion is being derailed.
you claim to put it back on track by proposing some expensive idea on TBB
side, which is overkill and would cause a shitload of new artificial
problems while we already have real ones. I contend that responsibility
for the debacle lies squarely with your company, not with Tor. to some
extent, granted, abusive bots and the general makeup of the web are also
to blame, but you mishandled it by serving impossible puzzles and causing
lots of collateral blocking.
> (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.
you're the MITM, you can see whether there is already an auth token of
some kind right? disallow POST otherwise. think of something. you're the
ones breaking things for people right now.
> (blocking regions) Second, during an "attack" (call it ddos or
something) the website owners often decide to block traffic from ceirtain
regions. Many bus.nesses 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.
how often does that happen? most of the time for a given site there's no
> (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.
what about slowing down recurrent requests? it's really not something that
can be solved on the Tor side.
> 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
in other words, you're happy to overblock Tor because IP blocks are just
so convenient? probably also because as far as cloudflare is concerned, we
just don't matter. I don't understand why you (or jgrahamc) bother with
this discussion anyway. what's in it for you?
I have already aired a comment about the "human bit", which I think is an
appalling idea in this context.
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18361#comment:71>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs