Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-04-22T12:49:06Zhttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/41start using plugins2023-04-22T12:49:06Zn0toosestart using pluginsWe want to avoid situations like: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot/-/blob/3edfb1c091c3b918629f0d06e767fc0137ddbf9e/OnionSproutsBot/bot.py#L372-L383
The patch was still merged, as it went k...We want to avoid situations like: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot/-/blob/3edfb1c091c3b918629f0d06e767fc0137ddbf9e/OnionSproutsBot/bot.py#L372-L383
The patch was still merged, as it went kind-of-out-of-scope and I wanted to provide translators with the few, slightly altered strings as soon as possible.
Pyrogram has a [built-in mechanism to specifically prevent this](https://docs.pyrogram.org/topics/smart-plugins), which I avoided using as I believed that "plugins", in this case, insinuated that they could be dynamically removed or added, which was very suboptimal, considering that the functions we wanted to "abstract" into separate files were linked to specific buttons under `bot.py` and we could not check whether a plugin was imported or not. Apparently, according to @StarByte, this doesn't matter as "plugins" can't be loaded or unloaded during runtime, and my confusion stemmed from my experience with other libraries that interface with instant messaging apps.
For this task to be complete, it'd be optimal to:
- separate some helper functions currently under `dialogue.py`
- shove all callback-needing functions in `dialogue.py` in a new file and remove the aforementioned "ugly hack" from bot.py
- move most of the functions in `bot.py` to a plugin file
~~(Note: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot/-/issues/42 has to be dealt with first)~~n0toosen0toosehttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/28Set daily max bucket distribution and adjust other settings for production2024-02-15T16:52:09ZonyinyangSet daily max bucket distribution and adjust other settings for productionWe likely need to decide on an upper bound of buckets that can be distributed each day so that we don't run out of open invitation buckets. We currently have buckets being distributed to k users before a new bucket is used but if buckets...We likely need to decide on an upper bound of buckets that can be distributed each day so that we don't run out of open invitation buckets. We currently have buckets being distributed to k users before a new bucket is used but if buckets are continuously requested, we will eventually run out of buckets each day. These variables should be part of a configuration file for Lox.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40284Publish container in our gitlab registry2023-10-01T15:24:43Zmicahmicah@torproject.orgPublish container in our gitlab registryNow that Tor [has enabled container registry support in Gitlab](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/89), it is possible to build and publish a container that is hosted in the container registry [here in the snowflake pr...Now that Tor [has enabled container registry support in Gitlab](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/89), it is possible to build and publish a container that is hosted in the container registry [here in the snowflake project](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/container_registry).
It would be ideal if we could host our own container, and point people to use that. We don't have to stop using the 3rd party registry.
This should be done automatically in the CI.https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/18Change lox-library functionality to replenish open-invitation bucket pool fro...2023-08-01T17:07:14ZonyinyangChange lox-library functionality to replenish open-invitation bucket pool from hot-spare poolHot spares could replenish open-invitation buckets but currently are only reallocated to be migrated to after a blocking event.
Perhaps the current functionality is the desired functionality, but if we're more likely to have open-invitat...Hot spares could replenish open-invitation buckets but currently are only reallocated to be migrated to after a blocking event.
Perhaps the current functionality is the desired functionality, but if we're more likely to have open-invitation bridges blocked than user migrate to trusted buckets when their bridges become blocked, this might be something to consider.
At the very least it could satisfy a condition in the case that there are no remaining open-invitation buckets. We should probably also flag that scenario so we can do something to get more bridges into the pool (hopefully).https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/20Figure out how to serve the encrypted bridge table to users2023-08-01T17:07:20ZCecylia BocovichFigure out how to serve the encrypted bridge table to usersLox credentials only contain an index into an encrypted table of bridge lines. Users must download the entire encrypted bridge table periodically in order to find and decrypt their bridges to preserve their anonymity and prevent the Lox ...Lox credentials only contain an index into an encrypted table of bridge lines. Users must download the entire encrypted bridge table periodically in order to find and decrypt their bridges to preserve their anonymity and prevent the Lox distributor from learning which users were assigned which bridges.
This can be a rather large download, and for obvious reasons must be done automatically and in a censorship-resistant way.https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/17author comments for translators2023-06-27T18:51:02Zn0tooseauthor comments for translatorsn0toosen0toosehttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/124Add a prometheus exporter to moat distributor2024-03-21T12:29:24Zmeskiomeskio@torproject.orgAdd a prometheus exporter to moat distributorLet's collect prometheus metrics on the Circumvention Settings [moat distributor](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md). We might want to collect metrics for:
* Requests to settings with country...Let's collect prometheus metrics on the Circumvention Settings [moat distributor](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md). We might want to collect metrics for:
* Requests to settings with country and *valid shim token* as labels
* Requests to other API endpoints with the endpoint as label (settings, defaults, map, builtin)
Some inspiration can be taken from how is the prometheus exporter in gettor: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/pkg/usecases/distributors/gettor/gettor.gomeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/185Distribute a single bridge in the QR code2024-03-04T15:30:36ZboyskaDistribute a single bridge in the QR codeThe current implementation of BridgeDB gives the user 3 bridges, and a QR code including them all.
It's a well-acknowledged fact that it's very difficult to scan this huge QR code from a smartphone.
It's almost impossible to scan it from...The current implementation of BridgeDB gives the user 3 bridges, and a QR code including them all.
It's a well-acknowledged fact that it's very difficult to scan this huge QR code from a smartphone.
It's almost impossible to scan it from a piece of paper.
It would therefore be great if the QR could include only a single bridge. While this would make the QR code slightly less useful, it would also make it much more _usable_.
I know that #40052+ is already tracking improvements for QR codes. However, they are mostly independent:
- To get one bridge per QR code, bridgedb#40052 is not needed
- Changing the format to a proper URI doesn't imply we will be switching to one-bridge-per-QR-code.
I can see two possible implementations:
1. Provide 3 bridges and 1 QR code. The QR code only includes data for one of the bridges.
2. Provide 3 bridges and 3 QR codes.
In Tails, we will be shipping QR code scanning [in 5.8](https://tails.boum.org/news/test_5.8-beta1/). This is expected to happen around December 20. It would be great if BridgeDB could distribute more usable QR codes by that time!shelikhooshelikhoo2024-03-29https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/182Implement a moat captcha API on top of circumvention settings2024-03-21T17:27:19Zmeskiomeskio@torproject.orgImplement a moat captcha API on top of circumvention settingsImplement the CAPTCHA API in rdsys with a static CAPTCHA. So we can turn off BridgeDB without the need to deprecate the API yet. It should have a single captcha that is always the same and easy to solve, but don't even check if the solut...Implement the CAPTCHA API in rdsys with a static CAPTCHA. So we can turn off BridgeDB without the need to deprecate the API yet. It should have a single captcha that is always the same and easy to solve, but don't even check if the solution is correct.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/197Add HTTPS distributor to the staging server2024-03-26T17:41:00Zmeskiomeskio@torproject.orgAdd HTTPS distributor to the staging servermeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40062Distribute a single bridge in the QR code2023-11-23T10:41:24ZboyskaDistribute a single bridge in the QR codeThe current implementation of BridgeDB gives the user 3 bridges, and a QR code including them all.
It's a well-acknowledged fact that it's very difficult to scan this huge QR code from a smartphone.
It's almost impossible to scan it from...The current implementation of BridgeDB gives the user 3 bridges, and a QR code including them all.
It's a well-acknowledged fact that it's very difficult to scan this huge QR code from a smartphone.
It's almost impossible to scan it from a piece of paper.
It would therefore be great if the QR could include only a single bridge. While this would make the QR code slightly less useful, it would also make it much more _usable_.
I know that #40052+ is already tracking improvements for QR codes. However, they are mostly independent:
- To get one bridge per QR code, #40052 is not needed
- Changing the format to a proper URI doesn't imply we will be switching to one-bridge-per-QR-code.
I can see two possible implementations:
1. Provide 3 bridges and 1 QR code. The QR code only includes data for one of the bridges.
2. Provide 3 bridges and 3 QR codes.
In Tails, we will be shipping QR code scanning [in 5.8](https://tails.boum.org/news/test_5.8-beta1/). This is expected to happen around December 20. It would be great if BridgeDB could distribute more usable QR codes by that time!shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/39abstract dialogue options2023-04-22T22:39:21Zn0tooseabstract dialogue optionsAs I was working on #15, I realized that I will most likely have to create two separate functions -- one for the desktop, and one for the Android versions of TBB. The functionality will be very similar (all database-related operations an...As I was working on #15, I realized that I will most likely have to create two separate functions -- one for the desktop, and one for the Android versions of TBB. The functionality will be very similar (all database-related operations and dialogue options), apart from details (such as the way the correct URL containing the correct file is determined).
As the same dialogue options may be used repeatedly across different functions, it may be a good idea to 'abstract' them (aka. put them in a different file) to make maintenance easier and improve readability.n0toosen0toosehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/36Dependency Dashboard2023-09-18T13:57:45ZRenovate BotDependency DashboardThis issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbo...This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
- [ ] <!-- rebase-branch=renovate/gitlab.torproject.org-tpo-anti-censorship-pluggable-transports-snowflake-v2-2.x -->[Update module gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2 to v2.6.1](!18)
- [ ] <!-- rebase-branch=renovate/github.com-refraction-networking-gotapdance-1.x -->[Update module github.com/refraction-networking/gotapdance to v1.7.2](!16)
## Ignored or Blocked
These are blocked by an existing closed MR and will not be recreated unless you click a checkbox below.
- [ ] <!-- recreate-branch=renovate/golang-1.x -->[Update golang Docker tag to v1.20](!11)
## Detected dependencies
<details><summary>gitlabci</summary>
<blockquote>
<details><summary>.gitlab-ci.yml</summary>
- `golang 1.18-buster`
- `golang 1.19-buster`
- `golang 1.20-buster`
</details>
</blockquote>
</details>
<details><summary>gomod</summary>
<blockquote>
<details><summary>go.mod</summary>
- `go 1.17`
- `git.torproject.org/pluggable-transports/snowflake.git/v2 v2.5.1`
- `github.com/pires/go-proxyproto v0.7.0`
- `github.com/refraction-networking/gotapdance v1.5.0`
- `gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib v1.5.0`
- `gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2 v2.6.0`
</details>
</blockquote>
</details>https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/30Dependency Dashboard2023-09-18T13:54:47ZRenovate BotDependency DashboardThis issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbo...This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
- [ ] <!-- rebase-branch=renovate/chrono-0.x -->[Update Rust crate chrono to 0.4.31](!54)
## Ignored or Blocked
These are blocked by an existing closed MR and will not be recreated unless you click a checkbox below.
- [ ] <!-- recreate-branch=renovate/aes-gcm-0.x -->[Update Rust crate aes-gcm to 0.10](!35)
- [ ] <!-- recreate-branch=renovate/rand-0.x -->[Update Rust crate rand to 0.8](!38)
- [ ] <!-- recreate-branch=renovate/sha2-0.x -->[Update Rust crate sha2 to 0.10](!40)
- [ ] <!-- recreate-branch=renovate/curve25519-dalek-4.x -->[Update Rust crate curve25519-dalek to v4](!45)
- [ ] <!-- recreate-branch=renovate/ed25519-dalek-2.x -->[Update Rust crate ed25519-dalek to v2](!46)
## Detected dependencies
<details><summary>cargo</summary>
<blockquote>
<details><summary>crates/lox-distributor/Cargo.toml</summary>
- `julianday 1.2.0`
- `base64 0.21.4`
- `hyper 0.14.27`
- `hex_fmt 0.3`
- `futures 0.3.28`
- `time 0.3.28`
- `tokio 1`
- `rand 0.8.5`
- `serde 1.0`
- `serde_with 3.3.0`
- `zkp 0.8.0`
- `clap 4.4.3`
- `serde_json 1.0.107`
- `sled 0.34.7`
- `chrono 0.4.30`
</details>
<details><summary>crates/lox-library/Cargo.toml</summary>
- `curve25519-dalek 3`
- `ed25519-dalek 1`
- `zkp 0.8`
- `bincode 1`
- `chrono 0.4`
- `rand 0.7`
- `serde 1.0.188`
- `serde_with 3.3.0`
- `sha2 0.9`
- `statistical 1.0.0`
- `lazy_static 1`
- `hex_fmt 0.3`
- `aes-gcm 0.8`
- `base64 0.21`
- `time 0.3.28`
- `subtle 2.5`
- `thiserror 1.0.48`
</details>
<details><summary>crates/lox-utils/Cargo.toml</summary>
- `serde 1`
- `serde_json 1.0.107`
- `serde_with 3.3.0`
</details>
<details><summary>crates/lox-wasm/Cargo.toml</summary>
- `julianday 1.2.0`
- `lazy_static 1.4.0`
- `wasm-bindgen 0.2`
- `time 0.3.28`
- `serde_json 1.0.107`
- `console_error_panic_hook 0.1.7`
- `js-sys 0.3.64`
- `rand 0.7`
- `zkp 0.8.0`
- `chrono 0.4.30`
</details>
<details><summary>crates/rdsys-backend-api/Cargo.toml</summary>
- `serde_json 1`
- `futures-util 0.3`
- `serde 1`
- `bytes 1`
- `hex 0.4.3`
- `crc64 2.0.0`
- `sha1 0.10.5`
- `tokio 1`
- `reqwest 0.11`
- `tokio-stream 0.1.14`
- `futures 0.3.28`
- `tokio-util 0.7.8`
- `chrono 0.4.30`
</details>
</blockquote>
</details>
<details><summary>gitlabci</summary>
<blockquote>
<details><summary>.gitlab-ci.yml</summary>
</details>
</blockquote>
</details>https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/79meta: fill the "donate" link on addons.mozilla.org2023-08-01T18:44:42ZWofWcawofwca@protonmail.commeta: fill the "donate" link on addons.mozilla.org![image](/uploads/1f3d212fb7ff1f3a2389c92ad083720e/image.png)
This will add the buttons on the extensions list and on the store page:
<details><summary>Like this</summary>
![image](/uploads/e4727d45059eb5d3b3ce8adb5ed2ff02/image.png)
...![image](/uploads/1f3d212fb7ff1f3a2389c92ad083720e/image.png)
This will add the buttons on the extensions list and on the store page:
<details><summary>Like this</summary>
![image](/uploads/e4727d45059eb5d3b3ce8adb5ed2ff02/image.png)
![image](/uploads/9f7bf215b4235e0871f29d235f7f8e4a/image.png)
</details>
Related: #77https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40217Upgrade utls dependency to v1.1.3 or later2023-10-11T05:28:38ZDavid Fifielddcf@torproject.orgUpgrade utls dependency to v1.1.3 or laterOur [current version](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/v2.3.1/go.mod#L15) is [v1.0.0](https://github.com/refraction-networking/utls/releases/tag/v1.0.0) from 2021-11-02. Newer releas...Our [current version](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/v2.3.1/go.mod#L15) is [v1.0.0](https://github.com/refraction-networking/utls/releases/tag/v1.0.0) from 2021-11-02. Newer releases have important enhancements, notably new and corrected fingerprints:
* [Implement certificate compression #95](https://github.com/refraction-networking/utls/pull/95)
* [new ClientHellos and Extensions #116](https://github.com/refraction-networking/utls/pull/116)
* Chrome_87
* Chrome_96
* Chrome_100
* Chrome_102
* Firefox_99
* Firefox_102
* iOS_13
* iOS_14
* Android_11
* ApplicationSettingsExtension
* SignatureAlgorithmsCertExtension
* DelegatedCredentialsExtension
* StatusRequestExtension
* [Add new ClientHellos #122](https://github.com/refraction-networking/utls/pull/122)
* Firefox 105
* Chrome 106
* Edge 106
* Safari 16.0
* 360 Secure Browser 11.0
* QQ Browser 11.1
* [Fix Google Parrots #125](https://github.com/refraction-networking/utls/pull/125)
You may not want to automatically include every possible new supported fingerprint. For example, see [this caveat](https://github.com/refraction-networking/utls/pull/122#issue-1401840671):
> Unfortunately, the specs based on Edge 106 and 360 11.0 seem to incompatible with this library.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/117Make bridge lines address into 'human-memorable' address or easier for users ...2023-05-18T11:18:05ZGusMake bridge lines address into 'human-memorable' address or easier for users to copy/shareA frequent problem in our user support channels is users failing to add a new bridge due to various reasons:
- Sometimes they just copy a piece of it (IP:Port) (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552)
...A frequent problem in our user support channels is users failing to add a new bridge due to various reasons:
- Sometimes they just copy a piece of it (IP:Port) (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552)
- In other cases they were adding more than one bridge without the right space/delimiter and then Tor fails to parse it right.
There are other instances where these poorly formatted addresses result in the user being unable to connect to Tor and lead them to report that the bridge is blocked in their country. (cc: @nina @championquizzer)
This is affecting users especially from high censored regions because we're sharing private bridges with them as other pluggable transports didn't work for them.
Maybe qr-codes could be used with bridgemojis?
Maybe bridges with human-memorables address would make this easier?meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/10Populate wiki with documentation2023-10-03T18:38:55ZCecylia BocovichPopulate wiki with documentationLet's use this overview project as a way to aggregate issues and documentation since Lox is made of many different pieces. A good start would be:
- There's some high level docs written up at https://gitlab.torproject.org/cohosh/lox/-/wi...Let's use this overview project as a way to aggregate issues and documentation since Lox is made of many different pieces. A good start would be:
- There's some high level docs written up at https://gitlab.torproject.org/cohosh/lox/-/wikis/Lox-Overview that should be moved here and also checked to see if they are accurate
- @onyinyang made some cool graphics at https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/116#note_2884107Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/12Add Early Data support to WebTunnel2024-02-27T19:06:29ZshelikhooAdd Early Data support to WebTunnelCurrently, the early data support(send first chunk of client data together with HTTP GET Request) is not implemented in WebTunnel.
This can slightly increase performance at the cost of increased code complexity.Currently, the early data support(send first chunk of client data together with HTTP GET Request) is not implemented in WebTunnel.
This can slightly increase performance at the cost of increased code complexity.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/104extend PT args size limit2023-08-11T10:49:53Zmeskiomeskio@torproject.orgextend PT args size limitCurrently the maximum length of arguments on a bridge line is 510bytes, as those are passed in the username and password fields of the SOCKS5 connection. We have already hit this limit with snowflake (https://gitlab.torproject.org/tpo/ap...Currently the maximum length of arguments on a bridge line is 510bytes, as those are passed in the username and password fields of the SOCKS5 connection. We have already hit this limit with snowflake (https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40665).
One proposal would to define a SOCKS5 METHOD (section 3 of [RFC1928](https://www.rfc-editor.org/rfc/rfc1928) different that 'username/password' (0x02) for it. Some years ago this was discussed and proposed to use 0x80 (*RESERVED FOR PRIVATE METHODS*): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10671#note_2604090
There is a PT spec around that proposes using 0x9 (undefined in the SOCKS5 RFC): https://github.com/Pluggable-Transports/Pluggable-Transports-spec/blob/main/releases/PTSpecV3.0/Pluggable%20Transport%20Specification%20v3.0%20-%20Dispatcher%20IPC%20Interface%20v3.0.md#14-pluggable-pt-client-per-connection-arguments
But AFAIK there is no implementation of any of those, so I guess we are free to define what we find more useful here. Any better proposals?