Anti-censorship team report: September 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

Anonymous

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

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

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?

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

Join the discussion...

We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the post moderator. Please do not comment as a way to receive support or report bugs on a post unrelated to a release. If you are looking for support, please see our support portal or ways to get in touch with us.

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

2 + 0 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.