Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-05-16T18:24:05Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/84Snowflake web badge need 3rd-party cookies to run, which is unskilled in toda...2023-05-16T18:24:05ZsolidsSnowflake web badge need 3rd-party cookies to run, which is unskilled in today's most browsersToday most browser set the default config to disable 3rd-party cookie, in Safari it's called "Prevent corss-site tracking", in Chromium-based browser it's called "Block third-party cookies". For example, the badge in website [relay.love]...Today most browser set the default config to disable 3rd-party cookie, in Safari it's called "Prevent corss-site tracking", in Chromium-based browser it's called "Block third-party cookies". For example, the badge in website [relay.love](https://relay.love) will show "Cookies are not enabled." in my browser and it's not possible to run without re-enabling 3rd-party cookies, which will allow tracking websites sneak in my privacy.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/77Add "Donate" link to the popup2023-04-25T10:44:36ZWofWcawofwca@protonmail.comAdd "Donate" link to the popupLike this maybe
![image](/uploads/7928d63db7365ba0fb2e4abe09456ae6/image.png)Like this maybe
![image](/uploads/7928d63db7365ba0fb2e4abe09456ae6/image.png)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/81Snowflake is Off / WebRTC feature is not detected.2023-04-23T10:27:21ZcypherpunksSnowflake is Off / WebRTC feature is not detected.I've just installed Snowflake via Chrome and it's not working. Can you confirm the process has been followed correctly? What have I done wrong - or not done at all? Thanks.I've just installed Snowflake via Chrome and it's not working. Can you confirm the process has been followed correctly? What have I done wrong - or not done at all? Thanks.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb-admin/-/issues/2keep from-serge tar file history for some time2023-04-20T16:46:50Zmeskiomeskio@torproject.orgkeep from-serge tar file history for some timeSerge sends regularly to polyanthum a tar file with the latest descriptors. In polyanthum we [process](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb-admin/-/blob/main/bin/store-bridge-tarball-from-serge) the tar and [send it...Serge sends regularly to polyanthum a tar file with the latest descriptors. In polyanthum we [process](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb-admin/-/blob/main/bin/store-bridge-tarball-from-serge) the tar and [send it](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb-admin/-/blob/main/bin/sync-to-colchicifolium) with a timestamp to collector. There might be issues with the sending, will be nice to keep a copy of each uploaded tar to collector for some time so we can restore if needed.
Related to: https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/40026https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/155Document in a bit more detail how rdsys is using onbasca2023-04-13T15:58:10ZjugaDocument in a bit more detail how rdsys is using onbascajugajugahttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/83Host the privacy policy on snowflake.torproject.org2023-04-11T18:38:11Zmeskiomeskio@torproject.orgHost the privacy policy on snowflake.torproject.orgLet's host the privacy policy (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/34) on the website:
https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/privacy/Let's host the privacy policy (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/34) on the website:
https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/privacy/https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/8Create and document our commit workflow2023-04-11T18:29:51ZCecylia BocovichCreate and document our commit workflowAt the moment, each project has been maintained slightly differently, but with the branch changes we're taking the opportunity to document and consolidate our workflows on each of these projects. They don't all need to be handled the sam...At the moment, each project has been maintained slightly differently, but with the branch changes we're taking the opportunity to document and consolidate our workflows on each of these projects. They don't all need to be handled the same, but we should definitely document the different workflows and point out projects that have exceptions. This workflow should include the following:
- which repositories to push to and where our mirrors are pointing
- do we introduce merge commits or do we rebase branches before merging?
- do we use the gitlab interface or merge things locally?
- how many reviews do we need and who maintains/has access to which repository?
- we had some discussion over on #7 about signing commits
- which projects have releases and what is the release workflow?
This is generally a good idea, and something we should work into our workflow. Let's use this ticket to document a proposal for different workflows. Again, some repositories for our team are maintained by people outside TPI so the focus should be on documentation and best practices, not necessarily in making everything the same.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/5Write documentation on how it is working2023-04-11T18:29:41ZGabagaba@torproject.orgWrite documentation on how it is workingAdd documentation on how it is working, the design, architecture and anything we need for it to be running (including survival guide).
- [ ] bridge survival guide
- [ ] point of contact for conjure station
- [ ] brief summary of archite...Add documentation on how it is working, the design, architecture and anything we need for it to be running (including survival guide).
- [ ] bridge survival guide
- [ ] point of contact for conjure station
- [ ] brief summary of architectureCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40147Move snowflake-broker to a systemd based setup2023-04-10T19:39:01ZshelikhooMove snowflake-broker to a systemd based setupCurrently snowflake-broker is using a [runit](http://manpages.ubuntu.com/manpages/trusty/man8/sv.8.html) based setup. It is simple and working but has some limitations.
We could consider moving to systemd to enable [auto](https://www.fr...Currently snowflake-broker is using a [runit](http://manpages.ubuntu.com/manpages/trusty/man8/sv.8.html) based setup. It is simple and working but has some limitations.
We could consider moving to systemd to enable [auto](https://www.freedesktop.org/software/systemd/man/systemd.service.html#RuntimeMaxSec=) restart.
Edit: remove incorrect info. Thanks @dcf .https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/7Save phantom registrations for later use2023-04-04T14:15:20ZCecylia BocovichSave phantom registrations for later useExisting phantom registrations can be used in future conjure sessions. This is where the Conjure registration process differs from a Snowflake rendezvous: phantoms are always online and the obfs4, min transport methods use static ports f...Existing phantom registrations can be used in future conjure sessions. This is where the Conjure registration process differs from a Snowflake rendezvous: phantoms are always online and the obfs4, min transport methods use static ports for the connection. Right now the client gets a new phantom IP for every connection. We should look into making these registrations persist to cut down on networking costs.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/13Allow connections to IPv6 phantoms2023-04-04T14:14:53ZCecylia BocovichAllow connections to IPv6 phantomsIPv6 address space gives a lot more phantom addresses to connect through and has the potential to be more censorship resistant.IPv6 address space gives a lot more phantom addresses to connect through and has the potential to be more censorship resistant.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/10Use the obfs4 transport2023-04-04T14:14:51ZCecylia BocovichUse the obfs4 transportRight now conjure is working with the min transport. This issue is to add an option to use obfs4.Right now conjure is working with the min transport. This issue is to add an option to use obfs4.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/23Use timeouts to detect stale connections and retry2023-04-04T14:14:06ZCecylia BocovichUse timeouts to detect stale connections and retryAs described in #22, there are some cases where a successful connection to the phantom proxy is established, but the TLS handshake with the phantom proxy doesn't complete.
We could add a staleness timeout similar to snowflake to close t...As described in #22, there are some cases where a successful connection to the phantom proxy is established, but the TLS handshake with the phantom proxy doesn't complete.
We could add a staleness timeout similar to snowflake to close the connection and retry registration again.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40126Visualize the Snowflake Network2023-03-31T19:00:35ZsereneVisualize the Snowflake NetworkTo further upgrade the main page, we could include a live visualization showing the strength of the Snowflake Network. (in a way which is scrubbed / anonymized of course, which the underlying metrics I believe always are.)
- It can show...To further upgrade the main page, we could include a live visualization showing the strength of the Snowflake Network. (in a way which is scrubbed / anonymized of course, which the underlying metrics I believe always are.)
- It can show how many people are currently helping, how many people are being helped.
- It would further assist in immediately making clear to new visitors what exactly Snowflake is/does, and how they can immediately be involved... whether as a volunteer proxy, as a user, as a dev, as a funder...
- It would cool.
I've not implemented this yet, but it's on my list. It would be an excellent addition to the landing page. See: #40125
I will update this ticket with a screenshot or demo soon.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/46Review UX and suggest improvements for telegram bridge bot2023-03-31T18:51:53ZdonutsReview UX and suggest improvements for telegram bridge botWe have a telegram bridge bot, and it's awesome! However at some point (i.e. when we revisit the bot and potentially integrate it with rdsys in future) UX should review and input into the following:
- The General UX/Design of the bot
- ...We have a telegram bridge bot, and it's awesome! However at some point (i.e. when we revisit the bot and potentially integrate it with rdsys in future) UX should review and input into the following:
- The General UX/Design of the bot
- How to collect user feedback about its use
- How to include (or link to) basic instructions on how to add bridges
- Improving user communication when (re)distributing cached bridges
- Integrating basic help functions/links to support articles
- If we want to localize it, and how this will work from a UI point of viewhttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40020probetest: automate graphing the results2023-03-31T17:42:15ZRoger Dingledineprobetest: automate graphing the resultsCohosh made some manual graphs showing some of the data points coming out of the bridgetest docker image. That's great but I bet it will be no fun to do new manual graphs every time.
One of Shadow's huge features is that part of running...Cohosh made some manual graphs showing some of the data points coming out of the bridgetest docker image. That's great but I bet it will be no fun to do new manual graphs every time.
One of Shadow's huge features is that part of running a Shadow experiment is that it writes out a many-page pdf with automatic snazzy graphs of cdfs of bandwidth, latency, all the rest. So, check out how Shadow does its thing.
Especially if we end up wanting to do more involved logic, like the "don't show any results for bridges that Canada couldn't reach" idea from #40019, we're going to want this "output analysis" step to be automated and repeatable.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40006Task 2.1: Publish ongoing scan results as a public (privacy-preserving as nee...2023-03-31T17:40:33ZGabagaba@torproject.orgTask 2.1: Publish ongoing scan results as a public (privacy-preserving as needed) dataset, and have a web page that highlights recent data and steers researchers toward trends/questions raised by the data.Much of this data is already in the [metrics portal](https://metrics.torproject.org) (passive bridge measurements for example) but much will be new.
- [ ] Publish ongoing scan results as a public (privacy-preserving as needed) dataset.
...Much of this data is already in the [metrics portal](https://metrics.torproject.org) (passive bridge measurements for example) but much will be new.
- [ ] Publish ongoing scan results as a public (privacy-preserving as needed) dataset.
- [ ] Have a web page that highlights recent data and steers researchers toward trends/questions raised by the data.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40008Task 2.2 Understand the OONI data format and constraints on OONI tests.2023-03-31T17:39:47ZGabagaba@torproject.orgTask 2.2 Understand the OONI data format and constraints on OONI tests.Understand the OONI data format, and the constraints on OONI tests, to build a plan for either converting our data into the OONI data format, or adding some of our tests to the ooniprobe app, or some other smart way to integrate.Understand the OONI data format, and the constraints on OONI tests, to build a plan for either converting our data into the OONI data format, or adding some of our tests to the ooniprobe app, or some other smart way to integrate.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/30716Improve the obfs4 obfuscation protocol2023-03-31T17:37:37ZPhilipp Winterphw@torproject.orgImprove the obfs4 obfuscation protocolAs part of our work for Sponsor 28, we will evaluate and improve the obfs4 obfuscation protocol, which may result in obfs5.
Roger started the discussion [on our anti-censorship-team mailing list](https://lists.torproject.org/pipermail/a...As part of our work for Sponsor 28, we will evaluate and improve the obfs4 obfuscation protocol, which may result in obfs5.
Roger started the discussion [on our anti-censorship-team mailing list](https://lists.torproject.org/pipermail/anti-censorship-team/2019-May/000015.html). Relevant reading is the CCS'15 paper [Seeing through Network-Protocol Obfuscation](https://censorbib.nymity.ch/#Wang2015a) and the S&P'16 paper [SoK: Towards Grounding CensorshipCircumvention in Empiricism](https://censorbib.nymity.ch/#Tschantz2016a).
Let's use this ticket to keep track of this effort. Below is a list of ideas that we may or may not want to incorporate in obfs5.
== Randomisation
Obfs4 already implements randomisation for packet lengths and inter-arrival times but there are other protocol aspects that we can randomise. Note that the adoption of these strategies may complicate censorship analysis: if obfs5 instance X looks very different from obfs5 instance Y, then X may end up getting blocked while Y still works. Instead of saying "obfs5 is blocked," one may then have to be more specific and say "the obfs5 instances that rely on UDP are blocked."
* **Payload**: All bytes that obfs4 writes to the wire are randomly distributed. These high-entropy packets may or may not be common on the Internet. We could evade a "high-entropy filter" by having obfs4 servers derive a formal language from the shared secret. This language could, say, use dummy clear-text headers. The [LibFTE](http://libfte.org/) library may be helpful here.
* **Cover traffic**: [dcf](https://lists.torproject.org/pipermail/tor-dev/2017-June/012310.html) explains that obfs4 only sends data when it's given data to send. To improve on this, as dcf suggests, we could make obfs5 send data even when the application has nothing to send.
* **Packet directions**: An obfs4 flow begins with the client sending data to the server. We could randomise packet directions and have, say, the server talk first with a server-specific probability.
* **Transport protocol**: An obfs4 server could talk either TCP or UDP or SCTP. This may very well not be worth the effort.
== Lessons learned from [CCS'15 paper](https://censorbib.nymity.ch/#Wang2015a)
* DPI boxes tend to classify flows by only inspecting the first N packets of a flow. Keeping state is expensive, after all. We could exploit this by relaxing our obfuscation techniques after N packets to increase throughput.
* The paper's data set may not be representative of what countries or ISPs would see:
* It's "only" a university uplink. Universities typically have policies that prohibit file sharing such as BitTorrent. BitTorrent's "message stream encryption" may look similar to obfs3 and obfs4.
* The data sets are from 2014, 2012, and 2010, respectively. That's a long time in Internet years.
* The detectors' false positive rates are non-trivial and, as the authors point out themselves, would be problematic for a censor given that non-obfuscated traffic significantly outweighs obfuscated traffic.
* Does the data set only contain one obfs4 server instance? This may have affected their results.
== Miscellaneous
* [yawning writes](https://trac.torproject.org/projects/tor/ticket/30716#comment:1) that obfs4 doesn't easily support backward incompatible protocol alterations.
* [yawning writes](https://trac.torproject.org/projects/tor/ticket/30716#comment:3) that the framing could use better cryptography.
* Crazy idea: Use a modified TCP stack that ignores RST and FIN segments, so the GFW's on-path devices cannot tear down the connection. Instead, the obfs5 protocol could signal the end of the connection in an authenticated control frame. We could ignore RST and FIN segments by using firewall rules, or to get more crazy, by shipping a user space TCP stack (this may be easy to fingerprint, though).https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40005Task 1.4: Identify set of wishlist/missing features for Tor client and plugga...2023-03-31T17:37:15ZGabagaba@torproject.orgTask 1.4: Identify set of wishlist/missing features for Tor client and pluggable transports to better assess Tor blockingUse this ongoing library of events to identify a set of wish list features for the Tor client and the various transports for how they could make scans more accurate and/or more productive.Use this ongoing library of events to identify a set of wish list features for the Tor client and the various transports for how they could make scans more accurate and/or more productive.