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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:
  Sponsor:                                |
------------------------------------------+--------------------------

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,
 etc.

 >
 > (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
 default.

 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
 activity.

 Do you have any open data on this?

 > @willscott:
 >
 > > 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
 <XX> minutes.
 >

 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
 TBB side?

 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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs