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

[Tor Bug Tracker & Wiki]

#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 mmarco):

 Hello everybody.

 DISCLAIMER: I am by no means an expert in networks, computer science or
 any other technical aspect that might have to do with the subject here, so
 it is likely that what I am going to propose makes no sense at all (uf
 that is the case, just ignore it). I am just a Tor user that is
 particularly annoyed by CF capthas, since I do a big part of my browsing
 through orfox, and captchas are broken there. The only reason I have
 decided to share my thoughts here is because ioerror publicly uncouraged
 us to do so in Twitter.

 My (probably naive) proposal is the following:

 from my perspective, the problem here is that Tor, by dessign, makes it
 hard to distinguish bewteen the legitimate user from the abusive one (be
 it human or robot). CF's work is preciselly to distinguish between those
 two users, so we have a inconpatibility problem here. More preciselly, the
 problem is the lack of granularity: CF just sees one IP (the exit node)
 used by many users, both legitimate and abusive.

 So my propsal goes in the direction of adding more granularity, that is,
 distinguish between those different users. It would be something like
 this:

 - When the website receives a request from a Tor exit node, it creates an
 ephemeral .onion service (or gets one from a pool of pre-created ones),
 and answers with a 301 message that redirects to the .onion service (maybe
 with a delay to give time for the corresponmding circuits to be
 stablished).

 - Those ephemeral .onion services are killed when there is no session
 running on them anymore. Or when abusive behaviour is detected through
 them.

 - The connections through those .onion services now can be treated
 separatedly, thus allowing to treat separatedly the legitimate users from
 the abusive ones.


 I don't know if this solution is viable (maybe the overhead of creating
 the ephemeral .onion services is too much), but if it is, I think it would
 give an improvement over the current situation.

 From the user viewpoint, there is a delay when accessing for the first
 time to the website, but that sounds better than the captcha hell. After
 that, there is a slower browsing experience, but that is the usuall price
 you have to pay for using Tor .onion services.

 From the website viewpoint, you have an initial timeout for each
 connection, which might already discourage abusers. If some abuser wants
 to reuse the same .onion connection, you have a direct handle over it (you
 can then push the captha hell, or even directly kill the connection).

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