Team issueshttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues2023-09-11T14:42:44Zhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/131Moat distributor is sharing offline bridges2023-09-11T14:42:44ZGusMoat distributor is sharing offline bridgesMoat is distributing obfs4 bridges that are currently offline. By checking their fingerprint on Metrics, it appears that these bridges no longer exist.
Reported via Tor forum: https://forum.torproject.org/t/bridges-requested-in-tb-do-...Moat is distributing obfs4 bridges that are currently offline. By checking their fingerprint on Metrics, it appears that these bridges no longer exist.
Reported via Tor forum: https://forum.torproject.org/t/bridges-requested-in-tb-do-not-work-only-the-ones-built-in/9172/2meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/127Some links in the wiki go to .onion when being on .org2023-06-28T09:53:32Zcomputer_freakSome links in the wiki go to .onion when being on .orgBeing on https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home#projects-that-the-team-maintains but all links except the last one try to send me to the `.onion` version.Being on https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home#projects-that-the-team-maintains but all links except the last one try to send me to the `.onion` version.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/126Research about designing an armored bridge line sharing URL format2024-03-04T15:32:16ZshelikhooResearch about designing an armored bridge line sharing URL formatTor's bridge line format is well suited for professional developers and power users on desktop environments. However, for other users the current bridge line does not work so well because:
1. The bridge line contains white space and oth...Tor's bridge line format is well suited for professional developers and power users on desktop environments. However, for other users the current bridge line does not work so well because:
1. The bridge line contains white space and other special characters that could make it hard to copy and paste correctly.
2. When the bridge line was corrupted, the client software can neither detect it, nor correct it. This results in user confusion as the corrupted bridge line results in silent error.
3. User tries to edit the bridge line without understanding how it works internally. This results in inconsistency between how the user expects a bridge line to work and how it actually works.
This ticket tracks the research and discussion about creating a new bridge line format specialized in sharing to address the issues mentioned.
Let's make some initial discussion before I write the full spec and write a reference implementation.
## Goals and non-goals
This armored bridge line format will try to:
1. auto detect/auto correct error occurred during transmission. Give the user explicit feedback when the bridge line is corrupted and avoid silent errors.
2. improve its operating system integration, allowing the user to click on the armored bridge line and be redirected to a bridge line recipient application.
3. avoid any characters or design that could make it harder to transmit the bridge line correctly.
4. signal user not to modify the shared bridge line by intuitively
It won't:
1. try to replace the current bridge line format. It is used to share bridge lines, and original bridge line format will still be accepted by all Tor applications and shown to users by default. The current bridge line format will still be the way bridge configurations are represented.
2. prevent users from editing bridge lines. Users still will be able to edit the bridge line once it is decoded from armored format.
3. prevent the bridge line from being censored or detected by authority.
## Expected Usage Context
This armored bridge line design will be used exclusively for sharing.
Specifically:
1. On Tor Browser, there will be a share bridge line button, when clicked, an armored bridge line will be converted from an ordinary bridge line, and shown to the user as plain text and QR code.
2. The user support team will share an armored bridge line generated from Tor Browser or command line tool to users requesting a bridge when appropriate.
3. Users can share armored bridge lines with each other.
4. Tor client implementations MAY support armored bridge line input. It is optional since this design is targeted toward ordinary users, and Tor Browser already supports converting bridge lines between different forms with command line tools. Advanced users can just use command line tools to convert bridge lines between its different formats.
## Internal design (for discussion)
The 2 way convention between armored bridge line and ordinary bridge line is through a sequence of reversible transform steps. Some of them are optional(under discussion), and may or may not be included in the final design. There are no dynamic or skipable step in the final version of the design.
### Compression (optional)
A compression like 7 bit UTF8 can be used to reduce the length of the final url string.
It will however make conversion more complex to implement.
### All or none transform (optional)
A all or none transform(AONT) like [SAEP+](http://crypto.stanford.edu/~dabo/abstracts/saep.html) can make sure the final output is completely random looking, polymorphic without any resemblance of underlying data.
This ensures:
1. Data are covered by checksum(see SAEP+ design), so any corruption will be detected.
2. Because data are encoded differently each time, if the final output contains a censored keyword, the user can just try again.
3. there will be less observable patterns in the final URL, preventing users from attempting to modify or interpreting it. The users will need to use a supported application to process the armored bridge line.
4. (less of a concern for Tor ecosystem) prevent client implementation from ignoring the checksum and process anyway.
This is a complex transform step.
### Checksum (if All or none transform step is not used) (optional)
Use a CRC64 or SHA-3 to generate a checksum to detect corruption.
This step should be skipped if AONT step was used.
### Forward error correction (optional)
Split the data into chunks and use Reed Solomon coding to encode the data and generate recovery shreds.
When the bridge line is corrupted, forward error correction attempts to repair content directly, without asking the user to try again. This non-interactive repair makes it easier for the user to get the bridge line working, without asking and waiting for assistance. Some environments like bad email clients/line breakers corrupt the content each time it processes it, retry itself won't work and frustrate users.
This is a complex transform step.
### URLSafe base64 encoding without padding + concreted
URL safe base64 encoding without padding will convert the binary result of previous steps into a URL safe string. If there is more than one shard of contents, they will be concreted with ~ symbol, which is URL safe and not used by URL safe base64.
### URL Prefix
The final string will be prefixed with either `bridgeprefix:?` or `https://bridgeprefix/#` to allow it to be clicked and be redirected to Tor client application by operating system.shelikhooshelikhoo2024-03-08https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/125tpo/anti-censorship/lox/lox-overview#72023-04-18T16:30:56Zonyinyangtpo/anti-censorship/lox/lox-overview#7https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/116Lox integration2024-02-14T16:57:40ZCecylia BocovichLox integrationLox is reputation-based bridge distribution system based on Salmon, that uses anonymous credentials and stores all of the state on the client side. We're working on a trial integration as part of #105 that will eventually (hopefully) bec...Lox is reputation-based bridge distribution system based on Salmon, that uses anonymous credentials and stores all of the state on the client side. We're working on a trial integration as part of #105 that will eventually (hopefully) become a full integration if it works.
This issue is to track progress on this integration.
## Integration Pieces
The Lox client library is written in Rust, so if we want to call it from the same part of Tor Browser that makes other Moat connections it has to be callable from a Javascript module in the browser. The first step for that is to write wasm bindings for the Lox library functions we need the client to call.
- [x] wasm bindings for the client-side lox library (https://gitlab.torproject.org/cohosh/lox-wasm)
Next is the actual Tor Browser code. We need a way to call the compiled wasm bindings and a new Javascript module for Lox that re-uses the same Moat connection logic that other calls to BridgeDB use.
- [x] javascript module for Tor Browser that uses the lox wasm bindings (https://gitlab.torproject.org/cohosh/tor-browser/-/merge_requests/1/diffs)
Finally, we need to integrate the server side with rdsys by writing a distributor for Lox that will receive bridge resources from the rdsys backend to eventually distribute via its reputation-based bridge distribution logic to users.
- [ ] Make an rdsys distributor for the server-side bits of Lox
- [x] document rdsys backend API (https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/backend-api.md)
- [x] implement backend api library in rust (https://gitlab.torproject.org/cohosh/rdsys-backend-api)
- [x] write distributor backend
- [ ] write distributor frontend
The goal is to get a minimally working example done first so that other teams can have a look at the changes required, suggest changes, and make a final decision on how we want to move forward.
## Trying out the integration candidate
**Note: This is very minimal at the moment. All it does is request an open invite from the lox distributor**
A work in progress Lox integration is available to try out. To test it, you will need two things:
- A Tor Browser Build that implements Lox
- A local test environment to emulate the server side of Lox
1. Building or downloading the latest Lox-capable Tor Browser
You can either download one of our Tor Browser builds (Linux only for now) at https://people.torproject.org/~cohosh/lox/
or you can build it yourself by checking out the latest lox integration branch: https://gitlab.torproject.org/cohosh/tor-browser-build/-/tree/lox
2. Run the local test environment
This can be done either with a premade Docker container or manually.
To run the premade Docker container, simply run:
```
docker run -p 2000:2000 -it cecylia/lox-test-env
```
To run the lox-server and the meek-server manually:
1. Build and run [lox-server](https://gitlab.torproject.org/cohosh/lox-server)
2. Set environment variables for the meek server:
```
export TOR_PT_MANAGED_TRANSPORT_VER=1
export TOR_PT_SERVER_BINDADDR=meek-0.0.0.0:2000
export TOR_PT_SERVER_TRANSPORTS=meek
export TOR_PT_ORPORT=127.0.0.1:8001
```
3. Build and run [meek-server](https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-server) with the `--disable-tls` argument.
3. Start Tor Browser and navigate to the Connection Settings. Select the "Request a Lox Invitation from torproject.org" button.
![Screenshot_from_2023-03-01_20-16-44](/uploads/5cd4aecebb8106ad9544cf96afb117c8/Screenshot_from_2023-03-01_20-16-44.png)
4. If it is successful, you should see a message saying the invitation was received and an array of bytes will be displayed. Optionally, see the console messages by opening the browser console (ctrl+shift+J).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/97Setup Webtunnel at njalla VPS2023-01-08T22:57:25ZshelikhooSetup Webtunnel at njalla VPSWe are considering to try out WebTunnel pluggable transport by setting it up at njalla VPS.
This issue will be used to track this effort.
## Steps to setup the bridge
- [x] Setup ACME for obtaining certificate
- [x] Setup nginx for TL...We are considering to try out WebTunnel pluggable transport by setting it up at njalla VPS.
This issue will be used to track this effort.
## Steps to setup the bridge
- [x] Setup ACME for obtaining certificate
- [x] Setup nginx for TLS termination and forwarding traffic to webtunnel
- [x] Setup tor and webtunnel
- [x] Test the setup
IRC log(Some content are removed as it come from internal channel):
```
[12:42:42 pm] <+meskio> shelikhoo: how do you feel about this? setting up a webtunnel bridge in our iran VPS and build a TB with webtunnel support
[12:43:02 pm] <+meskio> I worry it might be too much work, but might be handy to advance webtunnel and test it in the real world
[12:44:22 pm] <+meskio> I wonder if is not that simple, as we might actually need to modify the code of TB to understand what to do with webtunnel bridge urls
[1:32:10 pm] <+shelikhoo> meskio: we could try whether it will work first?
[1:32:51 pm] <+shelikhoo> I think it is a huge effort to get tor browser support a new transport NOW I think
[1:33:01 pm] <+shelikhoo> so we better test it?
[1:33:07 pm] <+shelikhoo> first
[1:36:06 pm] <+shelikhoo> Let's say we setup that bridge and write a instruction about testing it
[1:36:17 pm] <+shelikhoo> and see what is the response
[1:36:26 pm] <+shelikhoo> while we are getting TB to support it
[1:47:05 pm] <+meskio> shelikhoo: that sounds like a good idea
[1:48:14 pm] <+shelikhoo> we can setup one and test it first
[2:47:45 pm] <+shelikhoo> meskio: webtunnel need a domain with dns point to it. so do we wants to setup it Iran and forward the tor traffic with a tunnel, or setup it in outside and forward the web traffic?
[2:52:23 pm] <+meskio> true, might be easier the second option?
[3:49:38 pm] <+shelikhoo> meskio: I will try to setup it now
[3:56:22 pm] <+meskio> great, good luck
[3:56:23 pm] <+shelikhoo> meskio: can I copy and paste our conversation here about setting up this webtunnel bridge at a public ticket?
[3:57:13 pm] <+meskio> sure
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/95Investigate Distributed Snowflake Rollout Issue on proxy2023-10-25T15:24:07ZshelikhooInvestigate Distributed Snowflake Rollout Issue on proxyCurrently, we are encountering a slow rollout in distributed snowflake. We should investigate why.Currently, we are encountering a slow rollout in distributed snowflake. We should investigate why.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/81Snowflake stops working after large size tests2022-07-21T01:06:13ZitchyonionSnowflake stops working after large size tests
Snowflake, after some of the large message size tests, snowflake suddenly stopped being able to send/receive. The race app was still running, but starting/stopping the deployment seemed to fix the issue
Snowflake, after some of the large message size tests, snowflake suddenly stopped being able to send/receive. The race app was still running, but starting/stopping the deployment seemed to fix the issueSponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/78deploy onionsproutsbot2022-06-10T12:40:05Zmeskiomeskio@torproject.orgdeploy onionsproutsbotSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/77select bridges for probetest2022-03-31T13:38:45Zmeskiomeskio@torproject.orgselect bridges for probetestAfter deploying rdsys bridges has being shifted between distributors. Let's provide new bridges to probetest from each of the distributors.
I think the bridges should be newer than the deployment of rdsys (Feb 28), so they were not bloc...After deploying rdsys bridges has being shifted between distributors. Let's provide new bridges to probetest from each of the distributors.
I think the bridges should be newer than the deployment of rdsys (Feb 28), so they were not blocked from before, but as old and stable as possible, so hopefully they will not disappear in few weeks.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/72Moat process unexpected quit issue2022-09-23T20:04:10ZshelikhooMoat process unexpected quit issueLast Saturday(March 5, 2022) there is a failure observed at the moat service. The root cause of service failure is due to the unexpected quit of the moat process. @arma restored the service by restarting the moat process. However, the ro...Last Saturday(March 5, 2022) there is a failure observed at the moat service. The root cause of service failure is due to the unexpected quit of the moat process. @arma restored the service by restarting the moat process. However, the root cause of the issue is still present.
To solve this issue we have created the following roadmap:
1. Setup an automatic restart procedure like systemd to restart moat automatically when it fails
2. Setup a log collection system to capture the diagnostic output
3. redact the log file to hide the user IP address
4. Try to fix the root cause of service crashing by analyzing the diagnostic output
The relevant IRC log is as follows:
```
<n8fr8[m]> not sure where the right channel to report this, but the moat service endpoint seems to be down. can't request a bridge in TB, Orbot, OnionBrowser, etc.
<lavamind> n8fr8[m]: thanks for the heads up, usually a good place to start is #tor of forum.torproject.net
<lavamind> or*
<n8fr8[m]> well... a key part of our anti-censorship services for users in places like Russia where tor is blocked is down, and you want me to post it to the general tor forum on a message board? I suppose I will send an email to the right people instead
<lavamind> well I know there was an upgrade to bridgedb done this week, so I've poked a member of the anticensorship team responsible for it
<lavamind> I've looked at the system and couldn't find anything obviously wrong
<n8fr8[m]> thanks for checking!
<n8fr8[m]> could be something with fastly front domain, hopefully temporary
<n8fr8[m]> I am getting a TLS cert error on https://moat.torproject.org.global.prod.fastly.net/
<lavamind> oh nice catch
<lavamind> well we definitely dont generate those certificates :p
<lavamind> so yeah, maybe an issue on Fastly's end
<+armadev> n8fr8[m]: i think i might have fixed moat
<+armadev> if somebody wants to verify, please do :)
<shelikhoo> I think moat is recovered.... how did armadev fix it?
<+armadev> shelikhoo: the moat fix was 'sudo -u moat /srv/bridges.torproject.org/bin/run-moat-shim'
<+armadev> as specified in https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Moat-Survival-Guide
<+armadev> (and i had said this in #tpo-admin but i guess not in more detail here too)
<+armadev> shelikhoo: the bigger issue though is: that moat-shim thing has died at least twice now, mysteriously, for no reason
<+armadev> so somebody should debug it, set up monitoring for when it disappears, etc
<shelikhoow> Yes, so I think a systemd based solution that restart it automatically will work....
<+armadev> can you open a ticket somewhere?
<shelikhoow> Yes, consider it done.
<+armadev> i agree that using systemd to auto restart it is a good first step
<+armadev> there is definitely also a part of me that wants to know why it exits though :)
<+armadev> thanks!
<shelikhoo> That means we need to investigate the log....
<+armadev> yep. the log is full of tls complaints and ip addresses,
<+armadev> but i think the log only goes to stdout
<+armadev> i.e. when you log out from running run-moat-shim, the log now goes nowhere
<shelikhoo> Yes... If we setup a systemd based deployment, we can configure it to store the log from stdout,err
<+armadev> great. so, step one, switch to systemd and start logging stuff somewhere,
<shelikhoo> Systemd have its issues, but it is quite convenient
<shelikhoo> Yes.
<+armadev> then step two, when it dies, see if it said anything useful
<shelikhoo> The effort to do so will be tracked in the issue.
<shelikhoo> Yes
<+armadev> step one-point-five, notice that the log has a bunch of ip addresses in it and wonder if that is urgent enough to fix
<shelikhoo> Yes. I don't think it is urgent but we should fix it....
<+armadev> great
```meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/71moat over meek is not responding2022-09-23T20:04:10Zmeskiomeskio@torproject.orgmoat over meek is not respondingI'm unable to connect to moat using meek as transport. meek-client doesn't display any errors, but curl just fails to connect over it.I'm unable to connect to moat using meek as transport. meek-client doesn't display any errors, but curl just fails to connect over it.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/69Prepare for s28 site visit: March 25 20222022-03-29T01:45:45ZRoger DingledinePrepare for s28 site visit: March 25 2022Very similar to https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62: "We've got to make slides, wrap up any ongoing work that we want to report, and coordinate with the rest of our group about what our story/goals are."
I...Very similar to https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62: "We've got to make slides, wrap up any ongoing work that we want to report, and coordinate with the rest of our group about what our story/goals are."
In particular, the set of topics I want to learn about ("what did we make progress on") is the same set as listed in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62#note_2775653
Since the actual presentation is on March 25, it would be good to have things gathered some days earlier, e.g. by March 20 latest.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Roger DingledineRoger Dingledine2022-03-21https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/67Contact default bridge operators and ask them to upgrade obfsproxy package2022-05-30T09:26:43ZGusContact default bridge operators and ask them to upgrade obfsproxy packageFrom ACT meeting logs:
16:06:42 dcf1: How about starting with the Tor Browser default bridges?\
16:06:50 meskio: +1\
16:22:34 meskio: ggus: do you want to contact the default bridges about the obfs4 upgrade? or should I do it? (I guess ...From ACT meeting logs:
16:06:42 dcf1: How about starting with the Tor Browser default bridges?\
16:06:50 meskio: +1\
16:22:34 meskio: ggus: do you want to contact the default bridges about the obfs4 upgrade? or should I do it? (I guess I can find their contact somewhere in the wiki)\
[logs](http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-02-24-15.59.log.html)
Default bridges contact info: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Default-BridgesGusGushttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/66Self-service dashboard for dynamic bridges2022-04-26T23:25:35ZirlSelf-service dashboard for dynamic bridges![Image_18-02-2022_at_14.21](/uploads/c8337088a4d84514273626f6204e7872/Image_18-02-2022_at_14.21.png)
We need a self-service dashboard for rotating blocked bridges so that I am not a bottleneck. Access will be provided to the community ...![Image_18-02-2022_at_14.21](/uploads/c8337088a4d84514273626f6204e7872/Image_18-02-2022_at_14.21.png)
We need a self-service dashboard for rotating blocked bridges so that I am not a bottleneck. Access will be provided to the community team who will be able to mark bridges as blocked based on user reports, manual testing or metrics clues. Blocked bridges will then be destroyed and replacement bridges deployed.Sponsor 125: Rapid Response Fund for Russia censorship circumventionirlirl2022-04-08https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/63Prepare and respond to scrimmage/integration events2023-03-09T17:08:09ZCecylia BocovichPrepare and respond to scrimmage/integration eventsFrom Eliana:
> These dates are accurate, though the further off dates might shift a tad
> Re getting prepared for these, the only thing that needs to be done is having the code ready for the code freeze, and being available for debuggin...From Eliana:
> These dates are accurate, though the further off dates might shift a tad
> Re getting prepared for these, the only thing that needs to be done is having the code ready for the code freeze, and being available for debugging/support as requested (via RACE slack) during these events if an issue arises with the frozen code
> there's nothing required besides having the plugin pushed and working, and being available via slack if there are issues
The next step is for snowflake to pass the stress test. We won't be runing these tests ourselves -- TA1 team will take care of them. If any problem comes up I will need to fix it.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/58Update s28 plugin for v2.3.02022-11-03T17:22:27ZCecylia BocovichUpdate s28 plugin for v2.3.0Changes: https://wiki.race.twosixlabs.com/display/RACE2/TA2+Minimum+Changes+for+v.2.3.0
Branch: https://github.com/RACECAR-GU/plugin/tree/snowflake-rc-2.3.1
Still need to fix the same issue as in https://gitlab.torproject.org/tpo/anti-...Changes: https://wiki.race.twosixlabs.com/display/RACE2/TA2+Minimum+Changes+for+v.2.3.0
Branch: https://github.com/RACECAR-GU/plugin/tree/snowflake-rc-2.3.1
Still need to fix the same issue as in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/57Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/57Update s28 plugin for v2.2.02022-11-03T17:22:17ZCecylia BocovichUpdate s28 plugin for v2.2.0https://wiki.race.twosixlabs.com/display/RACE2/TA2+Minimum+Changes+for+v2.2.0https://wiki.race.twosixlabs.com/display/RACE2/TA2+Minimum+Changes+for+v2.2.0Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/56Update s28 plugins for v2.1.02022-05-06T18:08:45ZCecylia BocovichUpdate s28 plugins for v2.1.0More info coming soon. Due date is tentative.More info coming soon. Due date is tentative.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)itchyonionitchyonion2022-03-12https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/55Update s28 plugins for v2.0.02022-02-10T00:42:44ZCecylia BocovichUpdate s28 plugins for v2.0.0We'll have to update our plugins from v1.6.0 to v2.0.0. The new version will be released on January 27th. It shouldn't be too difficult to do this update from v1.6.0 but we should make sure we read the [release notes](https://wiki.race.t...We'll have to update our plugins from v1.6.0 to v2.0.0. The new version will be released on January 27th. It shouldn't be too difficult to do this update from v1.6.0 but we should make sure we read the [release notes](https://wiki.race.twosixlabs.com/display/RACE2/v2.0.0+Changes+Walkthrough).Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovich2022-02-05