Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-12-04T17:19:49Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40208"./proxy -h" does not show default value of a -capacity parameter2022-12-04T17:19:49Zslrslr"./proxy -h" does not show default value of a -capacity parameterHello at
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tree/main/proxy
"proxy -h"
Regarding “-capacity” parameter it would be handy to know what value is used when i do not use the -capacity switch.Hello at
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tree/main/proxy
"proxy -h"
Regarding “-capacity” parameter it would be handy to know what value is used when i do not use the -capacity switch.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/18".tx" translation option at snowflake.torproject.org2021-01-15T20:31:48ZDavid Fifielddcf@torproject.org".tx" translation option at snowflake.torproject.orgAt the top of the list of translations at https://snowflake.torproject.org/ there is a ".tx" option. The cause seems to be a new .tx directory in the translation submodule, specifically [this commit](https://gitweb.torproject.org/transla...At the top of the list of translations at https://snowflake.torproject.org/ there is a ".tx" option. The cause seems to be a new .tx directory in the translation submodule, specifically [this commit](https://gitweb.torproject.org/translation.git/commit/?h=snowflakeaddon-messages.json_completed&id=a30c07f5fc719b2c24619c3dd231b61314340d80), "Add tx config", from 2020-05-26.
<img src="/uploads/969118842e2a7fa422143fd292933af1/tx.png" height=320>https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/6149"Censorship-timeline" for Tor2020-06-27T13:43:43ZPhilipp Winterphw@torproject.org"Censorship-timeline" for TorIt was shortly discussed on #tor-dev that some sort of "censorship-timeline" for Tor would be helpful. In particular, this should provide:
* Detailed technical analyses of the censorship mechanisms in place (DPI fingerprints and manufa...It was shortly discussed on #tor-dev that some sort of "censorship-timeline" for Tor would be helpful. In particular, this should provide:
* Detailed technical analyses of the censorship mechanisms in place (DPI fingerprints and manufacturers, traceroutes, ...)
* Code and data to reproduce all experiments
* Tor patches and standalone tools to evade the censorship devices
After all, this timeline should serve as a comprehensive archive for all people interested in how Tor is getting blocked. It should make it easy to answer questions such as _"What happened to Tor in country X back in Y?"_.
There are also some open questions:
* How should the data be structured? In form of a timeline? Or country based? Something else?
* What data should be published and when? Full disclosure too early in the process helps the censors.
* How should it be presented? In a wiki page or a standalone web site?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12774"Firefox is already running" when you select meek after bootstrapping2021-11-08T19:49:21ZDavid Fifielddcf@torproject.org"Firefox is already running" when you select meek after bootstrapping1.Let Tor Browser bootstrap without any pluggable transports.
2. Open Network Settings and choose meek.
An alert appears:
Firefox is already running, but is not responding. To open a new window, you must first close the existing Fire...1.Let Tor Browser bootstrap without any pluggable transports.
2. Open Network Settings and choose meek.
An alert appears:
Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.
After that you can't browse. But closing the browser and allowing it to bootstrap from scratch again (with meek) works.
Tested on 3.6.3-meek-1 and on a build of the 4.0-alpha-1 branch.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40057"How to" page is missing styling2022-09-08T15:28:19Zdonuts"How to" page is missing stylingI'm not sure if this is a temporary issue or not, but I'm not seeing any styling on the howto page at all: https://bridges.torproject.org/howto/
![bridges-howto-unstyled](/uploads/6fa807f8ce9a584b92c82f023091c5f5/bridges-howto-unstyled....I'm not sure if this is a temporary issue or not, but I'm not seeing any styling on the howto page at all: https://bridges.torproject.org/howto/
![bridges-howto-unstyled](/uploads/6fa807f8ce9a584b92c82f023091c5f5/bridges-howto-unstyled.png)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40016"io.Copy inside CopyLoop io: read/write on closed pipe" in log of standalone ...2020-10-27T17:40:19ZDavid Fifielddcf@torproject.org"io.Copy inside CopyLoop io: read/write on closed pipe" in log of standalone proxy*Copied from the [public bug-reporting pad](https://pad.riseup.net/p/tor-anti-censorship-bugs-keep).*
My standalone snowflake proxy has been working well up to this point (at least as far as I can tell), but recently started to generate...*Copied from the [public bug-reporting pad](https://pad.riseup.net/p/tor-anti-censorship-bugs-keep).*
My standalone snowflake proxy has been working well up to this point (at least as far as I can tell), but recently started to generate the error "io.Copy inside CopyLoop generated an error: io: read/write on closed pipe."
I got this message before occasionally, means, once within a few days, however since about 2 days this happens every single time straight after a connection has been established.
OS in use is Debian bullseye/sid, nothing about my setup changed.
Example output:
```
2020/10/12 17:01:05 starting
2020/10/12 17:01:16 NAT type: restricted
2020/10/12 17:05:38 sdp offer successfully received.
2020/10/12 17:05:38 Generating answer...
2020/10/12 17:05:41 OnDataChannel
2020/10/12 17:05:41 Connection successful.
2020/10/12 17:05:41 OnOpen channel
2020/10/12 17:05:42 connected to relay
2020/10/12 17:06:02 OnClose channel
2020/10/12 17:06:02 io.Copy inside CopyLoop generated an error: io: read/write on closed pipe
2020/10/12 17:06:02 datachannelHandler end
```
All I could come up with when searching for this error is #33211, which seems unrelated though, since there's no spike in CPU usage.
Can you point me in any direction on how to debug this (or is it actually fixable on my end?)?David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40011"Just give me bridges!" should use the default transport of the Advanced Options2021-07-16T10:08:40Zsajolida"Just give me bridges!" should use the default transport of the Advanced OptionsCurrently:
- The "Just give me bridges!" button gives me vanilla bridges.
![Screenshot_from_2021-04-10_18-32-31](/uploads/aa0cf0a9387a67712f04e09bc0bcf162/Screenshot_from_2021-04-10_18-32-31.png)
- The "Get Bridges" button in the Adva...Currently:
- The "Just give me bridges!" button gives me vanilla bridges.
![Screenshot_from_2021-04-10_18-32-31](/uploads/aa0cf0a9387a67712f04e09bc0bcf162/Screenshot_from_2021-04-10_18-32-31.png)
- The "Get Bridges" button in the Advanced Options gives me obfs4 bridges by default.
I think that both should give the same type of bridges by default, currently obfs4.
I'm also unsure whether offering vanilla bridges is useful in the Advanced Options. According to [metrics.torproject.org](https://metrics.torproject.org/userstats-bridge-transport.html?transport=!%3COR%3E&transport=obfs4&transport=%3COR%3E) vanilla bridges are only marginally used. So maybe you should consider not serving them anymore on bridges.torproject.org.
Tell me if you prefer tracking this in a separate issue.Sponsor 30 - Objective 2.3meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25471"log to pt_state directory" option for snowflake-client2020-06-27T13:40:39ZDavid Fifielddcf@torproject.org"log to pt_state directory" option for snowflake-clientFrom legacy/trac#25449:
[comment:3:ticket:25449 dcf]:
> My removal of default logging in [12922a232b](https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=12922a232ba63bd8d94c92ced32e23aa2fb055ed) was arguably ras...From legacy/trac#25449:
[comment:3:ticket:25449 dcf]:
> My removal of default logging in [12922a232b](https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=12922a232ba63bd8d94c92ced32e23aa2fb055ed) was arguably rash: while obviously eventually we would have to stop logging by default, requiring a `-log` option with a path prevents writing to a log file that's inside the `pt_state` directory, which, in sandbox situations, may be the only place the transport plugin is allowed to write. obfs4proxy just has a boolean option `-enableLogging` that doesn't take a path, unconditionally writing to `pt_state/obfs4proxy.log`. Perhaps something like that would be better, even if it's less convenient for development.
[comment:4:ticket:25449 arlolra]:
> Maybe just add another flag, `-logToStateDir` or the likehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10679"make match" fails to validate sha256 checksums2020-06-27T13:44:00Zkpdyer"make match" fails to validate sha256 checksumsUpon successful completion of building the 3.6-beta branch of [1], "make match" fails to correctly validate binary packages.
```
$ make match
./check-match.sh versions
--2014-01-18 10:56:58-- https://people.torproject.org/~linus/builds...Upon successful completion of building the 3.6-beta branch of [1], "make match" fails to correctly validate binary packages.
```
$ make match
./check-match.sh versions
--2014-01-18 10:56:58-- https://people.torproject.org/~linus/builds/3.5.1/sha256sums.txt
Resolving people.torproject.org (people.torproject.org)... 2620:0:6b0:b:1a1a:0:26e5:4818, 38.229.72.24
Connecting to people.torproject.org (people.torproject.org)|2620:0:6b0:b:1a1a:0:26e5:4818|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6072 (5.9K) [text/plain]
Saving to: `sha256sums.txt'
100%[============================================================>] 6,072 --.-K/s in 0.007s
2014-01-18 10:56:59 (891 KB/s) - `sha256sums.txt' saved [6072/6072]
--2014-01-18 10:56:59-- https://people.torproject.org/~linus/builds/3.5.1/sha256sums.txt.asc
Resolving people.torproject.org (people.torproject.org)... 2620:0:6b0:b:1a1a:0:26e5:4818, 38.229.72.24
Connecting to people.torproject.org (people.torproject.org)|2620:0:6b0:b:1a1a:0:26e5:4818|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 836 [text/plain]
Saving to: `sha256sums.txt.asc'
100%[============================================================>] 836 --.-K/s in 0s
2014-01-18 10:56:59 (21.2 MB/s) - `sha256sums.txt.asc' saved [836/836]
gpg: keyring `/tmp/tmp.dbVtqBLbzn/secring.gpg' created
gpg: keyring `/tmp/tmp.dbVtqBLbzn/pubring.gpg' created
gpg: /tmp/tmp.dbVtqBLbzn/trustdb.gpg: trustdb created
gpg: key 23291265: public key "Linus Nordberg <linus@nordberg.se>" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
gpg: no ultimately trusted keys found
gpg: Signature made Fri 17 Jan 2014 02:21:48 AM PST using RSA key ID 23291265
gpg: Good signature from "Linus Nordberg <linus@nordberg.se>"
gpg: aka "Linus Nordberg <linus@nordu.net>"
gpg: aka "Linus Nordberg <linus@torproject.org>"
gpg: aka "[jpeg image of size 2906]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8C4C D511 095E 982E B0EF BFA2 1E8B F349 2329 1265
diff: ../sha256sums.txt: No such file or directory
make: *** [match] Error 1
```
[1] https://git.torproject.org/user/dcf/tor-browser-bundle.gitkpdyerkpdyerhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/35"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration...2024-03-25T11:21:06ZGus"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration protocol and will be destroyed."A bridge operator reported that their WebTunnel bridge stopped to work and found this message in their logs:"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration protocol and will be destroyed".
After restarting ...A bridge operator reported that their WebTunnel bridge stopped to work and found this message in their logs:"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration protocol and will be destroyed".
After restarting Tor, the bridge went back, but today it stopped again. Any ideas on why the webtunnel-server has crashed? Which logs they should provide for further analysis?shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/9678"Select Language" button on bridges.tpo2020-06-27T13:43:20ZNima Fatemi"Select Language" button on bridges.tpoSince we're serving this page in many different languages, it would be nice to have a "select language" button somewhere at the top or bottom of the page.
In case a user wants or need to change it manually.Since we're serving this page in many different languages, it would be nice to have a "select language" button somewhere at the top or bottom of the page.
In case a user wants or need to change it manually.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/103"settings" isn't documented at https://bridges.torproject.org/info#settings2022-04-04T09:53:45ZRoger Dingledine"settings" isn't documented at https://bridges.torproject.org/info#settingsOn relay-search, we have some bridges which have been assigned the distribution pool "settings" by rdsys. For example, here is one of the lines from the bridge-pool-assignments/ file on collector:
```
29e1f1ffbc4f4b306f3e3ffb52f58757620e...On relay-search, we have some bridges which have been assigned the distribution pool "settings" by rdsys. For example, here is one of the lines from the bridge-pool-assignments/ file on collector:
```
29e1f1ffbc4f4b306f3e3ffb52f58757620ea34c settings transport=obfs4 ip=4 blocklist=ru
```
This causes relay-search to list "settings" as the distribution method (which is ok, since that's what the pool file said), and relay-search links users to https://bridges.torproject.org/info#settings for an explanation of what it is. But that page doesn't have any explanation.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/42"Snowflake is off. Could not connect to the bridge."2022-07-09T04:32:31ZRoger Dingledine"Snowflake is off. Could not connect to the bridge."I checked my Snowflake proxy in my Firefox, and it told me "Snowflake is off. Could not connect to the bridge." and gave me the option to retry.
I clicked retry, and it connected and seemed happy again.
Was it going to retry on its own...I checked my Snowflake proxy in my Firefox, and it told me "Snowflake is off. Could not connect to the bridge." and gave me the option to retry.
I clicked retry, and it connected and seemed happy again.
Was it going to retry on its own at some point?
This is either a UX bug, "it should tell me it will retry so I don't get anxious that it's broken forever, and maybe the button should be called 'retry now'" or a more serious snowflake bug, "we have a bunch of snowflakes that gave up and we don't know about it". Hopefully the former. :)https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/56"The Tor Browser" -> "Tor Browser"2024-02-27T11:04:51ZRoger Dingledine"The Tor Browser" -> "Tor Browser"In working on https://gitlab.torproject.org/tpo/web/support/-/issues/341 I noticed that gettor has "the Tor Browser" in its strings too.
We should go through and get rid of the "the" when appropriate.
There is also a screenshot on the ...In working on https://gitlab.torproject.org/tpo/web/support/-/issues/341 I noticed that gettor has "the Tor Browser" in its strings too.
We should go through and get rid of the "the" when appropriate.
There is also a screenshot on the https://tb-manual.torproject.org/downloading/ page that could probably use an update once the new strings are in place.
We could also use this opportunity to update the rest of the strings as needed, but it is fine if not too. :) Thanks!https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/11467"Type the two words" on BridgeDB CAPTCHA confusing to users2020-06-27T13:43:13ZColin Childs"Type the two words" on BridgeDB CAPTCHA confusing to usersThe "Type the two words" comment under the CAPTCHA on https://bridges.torproject.org/bridges is currently confusing to users, as the CAPTCHA is not always 2 separate words.The "Type the two words" comment under the CAPTCHA on https://bridges.torproject.org/bridges is currently confusing to users, as the CAPTCHA is not always 2 separate words.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/11297'No bridges currently available' if you want IPv62020-06-27T13:43:14ZMatt Pagan'No bridges currently available' if you want IPv6Requesting IPv6 bridges over the web interface returns the error message in the title and no bridges. I've reproduced this over several days from different parts of the internet, and it has been reported to the help desk.Requesting IPv6 bridges over the web interface returns the error message in the title and no bridges. I've reproduced this over several days from different parts of the internet, and it has been reported to the help desk.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248(More) Distributed servers2023-09-17T15:22:17ZWofWcawofwca@protonmail.com(More) Distributed serversStanding on the shoulders of #40129, I propose the following.
This should allow clients to connect to _any_ accordingly set-up bridge (or even a regular entry node) they choose (say, distributed through moat, or any other channels), eli...Standing on the shoulders of #40129, I propose the following.
This should allow clients to connect to _any_ accordingly set-up bridge (or even a regular entry node) they choose (say, distributed through moat, or any other channels), eliminating the need of maintaining several centralized, set-in-stone Snowflake servers (bridges), which, mind, [costs quite a bit to operate, upgrade](https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations) and optimize.
What the parties need to become capable of doing so all this can work:
* Severs (a.k.a. bridges (or relays)): set up a Tor bridge, and set up a Snowflake server coupled with it, with a dedicated port (say, `7901` see #40166)
* Proxies: set [allowed relay pattern](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/7db2568448fed6d883b33db11e3a497c69f1748f/proxy/main.go#L28) to `*:7901` (any host, at port `7901`, see #40166)
* Clients: choose a server (bridge) that is set up accordingly, set up the Snowflake client to forward connections to that server, then connect Tor to it as a bridge.
From what I see, it should be quite possible upgrade all the current bridges ([or better public relays](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248#note_2875147)) this way (maybe even by embedding a Snowflake server in the Tor relay package), or upgrade bridge distribution mechanisms with a way to filter bridges by whether they accept Snowflake connection (like it is with obfs4). At which point it should become possible to let the Tor client choose the entry node itself, not manually specify a bridge you want (ahh, just remembered that it needs to learn the addresses of the nodes first. Maybe it can connect to directory authorities through Snowflake as well).
This idea is a based on these other ideas: #40166, #40168.
A step further would be to combine the server (bridge) and the proxy on one machine, but I haven't thought about it enough (see #40165, for example).https://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/-/issues/7(Request) Add a counter like the browser extension has that says how many peo...2022-03-15T21:48:31ZMatthew123456789006(Request) Add a counter like the browser extension has that says how many people were helped.It would be great if a simple counter like what the browser extension has was added that just says how many people were helped in the last 24 hours or some other duration.It would be great if a simple counter like what the browser extension has was added that just says how many people were helped in the last 24 hours or some other duration.https://gitlab.torproject.org/tpo/anti-censorship/bridge-port-scan/-/issues/1/scan/ URL requires a trailing slash2020-07-02T00:54:18ZDavid Fifielddcf@torproject.org/scan/ URL requires a trailing slashDuring the [2020-06-30 Internet Measurement Village talk](https://www.youtube.com/watch?v=g6xEfNHkFKY), participants in chat tried to access a URL that doesn't work:
* https://bridges.torproject.org/scan ([archive](https://web.archive.or...During the [2020-06-30 Internet Measurement Village talk](https://www.youtube.com/watch?v=g6xEfNHkFKY), participants in chat tried to access a URL that doesn't work:
* https://bridges.torproject.org/scan ([archive](https://web.archive.org/save/https://bridges.torproject.org/scan)) gives status 404
It only works if you include the trailing slash:
* https://bridges.torproject.org/scan/ ([archive](https://web.archive.org/web/20200630152455/https://bridges.torproject.org/scan/))https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/890.7.3 rejected from mozilla2024-03-28T04:37:33Zmeskiomeskio@torproject.org0.7.3 rejected from mozillaWe got this email:
> Due to issues discovered during the review process, one or more versions of your add-on Snowflake will be disabled on addons.mozilla.org in 14 day(s). Please
> see the reviewer’s comments below for more information.
...We got this email:
> Due to issues discovered during the review process, one or more versions of your add-on Snowflake will be disabled on addons.mozilla.org in 14 day(s). Please
> see the reviewer’s comments below for more information.
>
> ********
> Details:
> - Reproducing the submitted release version based on the provided source code package and instructions failed.
>
> You can access the console output at https://paste.mozilla.org/kOCS6sFe
> Environment used for building: Node 20.10.0, npm 10.2.3 on Ubuntu 22.04 LTS x64 (10GB RAM, 6 CPUs)
>
> Please test your build in a clean environment to make sure it is reproducible. If necessary, update the source code package and/or the instructions to
> reproduce.
> Please read through the instructions at https://extensionworkshop.com/documentation/publish/source-code-submission/ .
>
> Version(s) affected:
> 0.7.3
> ********
>
> Please address the issues raised in the reviewer's notes and inquire about any unclear items. Afterwards, please upload a new version of your add-on at
> https://addons.mozilla.org/en-US/developers/addon/torproject-snowflake/versions.
>
> To respond, please reply to this email or visit https://addons.mozilla.org/en-US/developers/addon/torproject-snowflake/versions. If we do not hear from you
> within 14 day(s) of this notification, these versions will be removed from addons.mozilla.org. Current users of these versions will be unaffected.Cecylia BocovichCecylia Bocovich