Anti-censorship team report: September 2020

by phw | October 12, 2020

Tor's anti-censorship team writes monthly reports to keep the world updated on its progress. This blog post summarizes the anti-censorship work we got done in September 2020. Let us know if you have any questions or feedback!

Snowflake

  • Merged a contribution from Peter Gerber to consider more IP address ranges local, for the purpose of stripping from SDP offers sent to the broker.

Rdsys

  • Built an HTTP streaming API between rdsys's backend and its distributors that allows distributors to receive resource updates (e.g. a bridge changing its IP address) in real-time.

  • Implemented a registration API that allows standalone-proxies (i.e. without a corresponding Tor bridge) to register themselves:
    https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/4

  • Added lots of unit tests. Rdsys's domain logic is 72.1% tested.

  • Experimented with reCAPTCHA support in rdsys. We could port BridgeDB's HTTPS distributor to rdsys and replace our Gimp-generated CAPTCHAs with Google's reCAPTCHA. To prevent exposing our users to Google, we would have to set up a reverse proxy, so Google only gets to see our machine's IP address. This is possible but messy to build.

  • Started brainstorming Salmon's user interface; in particular how we can best integrate it in Tor Browser:
    https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/7

  • Started writing up rdsys's design and architecture. The goal is to eventually publish a technical blog post that discusses how we built rdsys.

Bridgestrap

Miscellaneous

Outreach

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

October 14, 2020

Permalink

Recorded a brief video that summarises Tor's anti-censorship work for a class at the University of Michigan.

Is the video going to be released publicly or no?

Anonymous (not verified) said:

October 14, 2020

Permalink

Snowflake became extremely slow for me these last months, I don't know if it's because more and more people are using it. I get 60kb/s from most snowflakes, only with a luck I can get on a snowflake with 400kb/s (these figures are what i get from opening Nyx and seeing the download bandwidth)

I think it's because of latency, some snowflakes might just be far from you *AND* from the snowflake bridge (in netherlands IIRC, no longer following dev after they switched to gitlab), it would be better if they had different snowflake bridges that connect to the snowflakes based on information from the broker about geoip (geoip is not perfect but better than the status quo)

but at least we might see the double channels soon which might help

Anonymous (not verified) said:

October 14, 2020

Permalink

The post is too technical for me to grasp even the gist, but this caught my eye:

> replace our Gimp-generated CAPTCHAs with Google's reCAPTCHA

My instinctive reaction is:

noooooo!

Is this perhaps another example of Google's money pushing Tor devs to consider something which potentially endangers Tor users but which has some obscure benefit to Google?

As I mentioned before, we're not married to the idea of using reCAPTCHA. We would only use reCAPTCHA if it's possible to embed it in a privacy-preserving way. That may very well be impossible, in which case we wouldn't deploy it.

@ Phillip Winter:

My experience with Google CAPTCHAS is very discouraging. Sites which use them seem to always just demand capture after capture after capture, but apparently Google never has any intention of passing a Tor user, they just make us suffer needlessly and keep the door slammed in our face. This is very bad because we are not doing anything wrong.

One could reason that more refreshes and longer delays produce more permutations of one user's circuits for them to fingerprint and geolocate the user.

anon (not verified) said:

October 28, 2020

Permalink

I can't believe trying to implementing google's recaptcha is even being floated as a possibility it is more than feasible to create a captcha that isn't easily beaten by automation

But maybe i overestimated the Tor team since the "captcha" on this blog is 1+0=

Human (not verified) said:

November 05, 2020

Permalink

Please dont use Google's captcha, its terrible for privacy.
Why not use something like the math question captcha, or hcaptcha? There are several alternatives to Google's captchas out there