Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2023-03-10T21:31:54Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40177Deploy further snowflake-server performance improvements 2022-09-242023-03-10T21:31:54ZDavid Fifielddcf@torproject.orgDeploy further snowflake-server performance improvements 2022-09-24The snowflake-01 bridge is getting close to its memory limits again after yesterday's deployments
(tpo/anti-censorship/pluggable-transports/snowflake#40173, tpo/anti-censorship/pluggable-transports/snowflake#40175).
The little dip marked...The snowflake-01 bridge is getting close to its memory limits again after yesterday's deployments
(tpo/anti-censorship/pluggable-transports/snowflake#40173, tpo/anti-censorship/pluggable-transports/snowflake#40175).
The little dip marked in the graph below, I investigated it,
and it occurred during a time when the memory was almost 100% full.
You can also tell the server is reaching its limits because the send and recv traces
become a little bit decorrelated.
For comparison, currently, at the right edge of the graph, RAM use is 85%.
![bandwidth on network interface](/uploads/a05f736ab902e70d569fd7dd78bb9abe/g2.png)
[Profiling yesterday](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40086#note_2837328) revealed two major contributors to memory usage:
`io.Copy` buffers and client send queues, each of which accounts for about 25%
of the total memory used by the process.
I have a branch that is meant to resolve the `io.Copy` buffer one.
It exposes the `io.WriterTo` interface of `smux.Stream` through `SnowflakeClientConn`,
which will prevent `io.Copy` from allocating a buffer per client.
I also put in a minor optimization to `ClientMap.SendQueue`,
the benefit of which turns out to be tiny,
but there's no reason not to do it.
https://gitlab.torproject.org/dcf/snowflake/-/compare/a16133ff03d4a7f05bea375e5aa34ff794ee316c...4d4fad30c429bba9062d1b67d56787d45721627d?from_project_id=850
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-09-25https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40176Increase number of tor instances from 8 to 12 on snowflake-01 bridge2022-10-15T02:40:41ZDavid Fifielddcf@torproject.orgIncrease number of tor instances from 8 to 12 on snowflake-01 bridgeAfter the instances were increased from 4 to 8 in tpo/anti-censorship/pluggable-transports/snowflake#40173, traffic has continued to increase, and now the 8 tor processes are each reaching above 90% CPU at times (cf. https://gitlab.torpr...After the instances were increased from 4 to 8 in tpo/anti-censorship/pluggable-transports/snowflake#40173, traffic has continued to increase, and now the 8 tor processes are each reaching above 90% CPU at times (cf. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40175#note_2837026).
Increase the number of instances from 8 to 12.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-09-25https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40175Deploy snowflake-server performance improvements 2022-09-232022-11-16T17:48:41ZDavid Fifielddcf@torproject.orgDeploy snowflake-server performance improvements 2022-09-23The background is greatly increased usage and resulting load on the server in the past 2 days.
* [[anti-censorship-team] Need to increase number of tor instances on snowflake-01 bridge, increased usage since yesterday](https://lists.torp...The background is greatly increased usage and resulting load on the server in the past 2 days.
* [[anti-censorship-team] Need to increase number of tor instances on snowflake-01 bridge, increased usage since yesterday](https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000247.html)
* tpo/anti-censorship/pluggable-transports/snowflake#40173
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40086#note_2836854
snowflake-server is remaining functional, but restarting every few hours due to out-of-memory conditions. I did some profiling yesterday and found a few optimizations. They may help, or they may not.
https://gitlab.torproject.org/dcf/snowflake/-/compare/03b2b56f879879bb379cff8d7352ace1102d8811...c2f7003e2d316112db062540dcbe5ee569e2bd71?from_project_id=43
The plan is to first deploy the optimizations with profiling enabled, for a few hours, to collect profiles under load. Then re-deploy without profiling, later today if nothing goes wrong.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-09-24https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40174Update description in Snowflake extension pages on Firefox and Chrome2022-09-23T14:50:34ZrayaUpdate description in Snowflake extension pages on Firefox and ChromeThere was a discussion in the Tor IRC channel that the description in the Snowflake extension Chrome webstore and Firefox add-ons page does not clearly distinguish between censored/uncensored users:
- https://addons.mozilla.org/en-GB/fir...There was a discussion in the Tor IRC channel that the description in the Snowflake extension Chrome webstore and Firefox add-ons page does not clearly distinguish between censored/uncensored users:
- https://addons.mozilla.org/en-GB/firefox/addon/torproject-snowflake/
- https://chrome.google.com/webstore/detail/snowflake/mafpmfcccpbjnhfhjnllmmalhifmlcie
Opening the issue to say that I could work on updating the description in the next hour if the priority is high!
cc: @arma @gus @shelikhoo @meskiohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40173Increase number of tor instances from 4 to 8 on snowflake-01 bridge2022-12-03T20:40:46ZDavid Fifielddcf@torproject.orgIncrease number of tor instances from 4 to 8 on snowflake-01 bridgeBackground:
https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000247.html
The current 4 tor instances on the snowflake-01 bridge are saturated near 100% CPU since yesterday, due to increased usage. (Right now th...Background:
https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000247.html
The current 4 tor instances on the snowflake-01 bridge are saturated near 100% CPU since yesterday, due to increased usage. (Right now the bridge is at about 200 MB/s outgoing, 140 MB/s incoming.) We need to increase the number of instances.
I am a bit worried that 8 instances will permit more traffic than the hardware of the bridge will permit. I'll watch the performance and be prepared to step it back to 6.
While making the change, also increase `clientIDAddrMapCapacity` because snowflake-server is reporting constant "no address in clientID-to-IP map (capacity 10240)". Previous issue: #40084.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-09-23https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40172Host the privacy policy on snowflake.torproject.org2023-04-11T18:28:29Zmeskiomeskio@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/pluggable-transports/snowflake/-/issues/40171Create continuous integration and continuous delivery for creating container ...2022-08-09T18:59:19ZshelikhooCreate continuous integration and continuous delivery for creating container image for snowflake proxyWe could consider creating the necessary continuous integration and continuous delivery to create and publish container images automatically.
```
Umbrel asked us:"If you push multi architecture builds to Docker Hub after your releases a...We could consider creating the necessary continuous integration and continuous delivery to create and publish container images automatically.
```
Umbrel asked us:"If you push multi architecture builds to Docker Hub after your releases automatically, it would just be super simple PR to update the version number and checksum to keep Umbrel up to date".
```
```
16:25:22 <shelikhoo> Umbrel asked us:"If you push multi architecture builds to Docker Hub after your releases automatically, it would just be super simple PR to update the version number and checksum to keep Umbrel up to date". https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40169
16:25:37 <shelikhoo> I think is comes more to the CI/CD part of things
16:25:42 <ggus> i reached out to luke from umbrel, and he asked me about that
16:26:14 <shelikhoo> currently, I think we are building this by hand
16:26:31 <shelikhoo> and there no automated deployment
16:26:54 <shelikhoo> it will take sometime to get CICD working, but it will save a lot of efforts
16:27:04 <shelikhoo> in the long run
16:27:21 <shelikhoo> otherwise if we still build it by hand
16:27:51 <shelikhoo> we could add updating docker image to our check list
16:30:25 <ggus> sounds good
16:30:29 <shelikhoo> i will create a ticket for adding build docker image to CI
16:31:09 <ggus> thank you, shel!
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40170Create a patch to remove Hello Verify Request in Snowflake's WebRTC2022-08-09T19:15:31ZshelikhooCreate a patch to remove Hello Verify Request in Snowflake's WebRTCThe Snowflake with [patched](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/83) supported_groups [don't](https://ntc.party/t/testing-invitation-for-tor-browser-with-supported-groups-patch-countermeasure-in-snowflake-to-e...The Snowflake with [patched](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/83) supported_groups [don't](https://ntc.party/t/testing-invitation-for-tor-browser-with-supported-groups-patch-countermeasure-in-snowflake-to-evade-censorship-observed-in-russia/2837/2) work. It is suggested that Hello Verify Request is now the signature being targeted.
```
16:07:39 <shelikhoo> the patched version we produced is not working]
16:08:12 <shelikhoo> and one of the possible reason that that Hello Verify is now censored
16:08:24 <shelikhoo> and one of the possible reason is that that Hello Verify is now censored
16:08:34 <dcf1> Hello Verify Request: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030#note_2823140
16:08:50 <shelikhoo> we could patch it again and generate an binary again
16:11:21 <shelikhoo> do we have an existing patch for removing Hello Verify?
16:11:28 <shelikhoo> that we can just apply?
16:11:48 <dcf1> Not as far as I know
16:15:26 <shelikhoo> I can create a ticket to track this issue.
16:16:34 <shelikhoo> https://gist.github.com/xiaokangwang/5cd4437d087b0159146b0cb9d09aa9a5
16:16:55 <shelikhoo> I received such an patch, but I forgot the exact context I got it...
16:18:14 <shelikhoo> I think it changes whether the local will be client or server to avoid some censorship
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40169Update Snowflake Proxy in third party Distribution Channel: umbrel2023-07-27T15:19:55ZshelikhooUpdate Snowflake Proxy in third party Distribution Channel: umbrelSome users requested advise on updating snowflake proxy on umbrel, a server management software that have a software store.
We need to update this file to get it updated.
https://github.com/getumbrel/umbrel-apps/blob/master/snowflake/do...Some users requested advise on updating snowflake proxy on umbrel, a server management software that have a software store.
We need to update this file to get it updated.
https://github.com/getumbrel/umbrel-apps/blob/master/snowflake/docker-compose.ymlhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40168Snowflake as a generic TCP (UDP?) forwarder (like `ssh -L`)2023-01-12T19:19:00ZWofWcawofwca@protonmail.comSnowflake as a generic TCP (UDP?) forwarder (like `ssh -L`)Here's the idea
* When setting up a Snowflake server, you specify **host** and **hostport** you want to forward connections to
* When setting up a Snowflake client, you specify the address of the Snowflake server to connect to and local ...Here's the idea
* When setting up a Snowflake server, you specify **host** and **hostport** you want to forward connections to
* When setting up a Snowflake client, you specify the address of the Snowflake server to connect to and local **port** to listen to (and optionally **bind_address**)
* When a connection to **bind_address:port** is made, it gets forwarded through the Snowflake network and comes out of the Snowflake server to **host:hostport**
If one day we make the proxy allow pattern not so strict (i.e. only allowing connections to `snowflake.torproject.net`) (possibly with the help of #40166), this would open up virtually endless possibilities for the Snowflake network, it would be like a Tor network of its own.
For example, VPN services that are being censored could start deploying their own Snowflake servers to keep serving their clients (in that case we wouldn't even need to ask proxies to connect to arbitrary addresses, a curated white-list would do). Individuals could do the same, and with their own VPNs, in case censorship is super heavy, like it is in Turkmenistan (although Snowflake apparently doesn't work there right now #40024) where self-hosted VPNs get blocked as well.
(Side note - why I seem to be obsessed with VPNs when we already have Tor that already works with Snowflake - because they're faster).
Related: #40131https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40167debian-testing pipeline failed2022-10-10T15:56:59ZCecylia Bocovichdebian-testing pipeline failedFailed job: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/jobs/159231
This seems to be a problem with packaged debian dependencies. I don't think it actually has anything to do with the most recent c...Failed job: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/jobs/159231
This seems to be a problem with packaged debian dependencies. I don't think it actually has anything to do with the most recent commit. But rather that the pipeline hasn't been triggered for a while now. The last time it was run (and passed) [was a month ago](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/jobs/147158).
The exact error is:
```
$ apt-get -qy install --no-install-recommends build-essential ca-certificates git golang golang-github-cheekybits-genny-dev golang-github-jtolds-gls-dev golang-github-klauspost-reedsolomon-dev golang-github-lucas-clemente-quic-go-dev golang-github-smartystreets-assertions-dev golang-github-smartystreets-goconvey-dev golang-github-tjfoc-gmsm-dev golang-github-xtaci-kcp-dev golang-github-xtaci-smux-dev golang-golang-x-crypto-dev golang-golang-x-net-dev golang-goptlib-dev golang-golang-x-sys-dev golang-golang-x-text-dev golang-golang-x-xerrors-dev lbzip2
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package golang-github-xtaci-kcp-dev
```meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40166Dedicated Snowflake server port as a way to tell if host allows Snowflake con...2023-09-17T13:17:29ZWofWcawofwca@protonmail.comDedicated Snowflake server port as a way to tell if host allows Snowflake connectionsDisclaimer: I'm no networking / information security expert.
I was thinking about using Snowflake for non-Tor applications (like 1/2-hop VPN).
Currently Snowflake proxies are configured to only forward connections to certain domains / ...Disclaimer: I'm no networking / information security expert.
I was thinking about using Snowflake for non-Tor applications (like 1/2-hop VPN).
Currently Snowflake proxies are configured to only forward connections to certain domains / domain patterns (i.e. the Snowflake Tor relay), which constrains the usefulness of Snowflake network to Tor only. Not only that, but it also doesn't allow for truly distributed Snowflake relay network (#40129).
And I thought - how about we allow clients to ask proxies to connect to arbitrary addresses, but only to certain port(s)?
This should limit its use for malicious purposes as a botnet, like DDOS (from both malicious clients and malicious broker). For further DDOS protection, proxies could set a timeout for server / client if a connection is rejected by the server (port is closed, or port is open, but host rejected the protocol (either transport-level, or data-level (i.e. there is a Snowflake-specific handshake)), or rejected the client with this IP (if it's forwarded), maybe something else).
Also, as was said in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248#note_2869324, probably need to reject local addresses.
Of course, more thorough analysis is required.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40165Let clients choose proxies (without listing all their IPs)2023-01-12T19:19:01ZWofWcawofwca@protonmail.comLet clients choose proxies (without listing all their IPs)This is practically the same as https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40054
I believe this will require proxies to have identities (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/sno...This is practically the same as https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40054
I believe this will require proxies to have identities (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29260), because the client needs to verify that the proxy it connected to is the proxy it chose (also see https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/22945#note_2823461). Although a non-persistent / rotating identity should be enough.
I think this is the way to solve these:
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40156
* Partly https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651 (see comments)
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31200
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31661
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/43
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25598
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40048
It needs to be kept in mind that this will allow several clients to choose the same proxy. But I have not managed to come up with an idea why it could be problematic, as proxies are in control of how many clients they're willing to serve.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40164perf: trickle ICE (don't wait for ICE gathering to complete before sending an...2023-01-26T18:29:49ZWofWcawofwca@protonmail.comperf: trickle ICE (don't wait for ICE gathering to complete before sending an offer/answer)...and keep sending new ICE candidates after.
I'm not a big expert on WebRTC but from what I've read (UPD: and [experienced](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/68#note_285066......and keep sending new ICE candidates after.
I'm not a big expert on WebRTC but from what I've read (UPD: and [experienced](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/68#note_2850662)), it can take a while for ICE gathering to complete, but a connection can be established before it does complete. [Here](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling#exchanging_ice_candidates) it says:
> Each peer sends candidates in the order they're discovered, and keeps sending candidates until it runs out of suggestions, even if media has already started streaming.
In JS there is `addIceCandidate` and `onicecandidate` (and `canTrickleIce`). In the Go version, there is [`pc.OnICECandidate`](https://github.com/pion/webrtc/tree/master/examples/trickle-ice).
I suspect that this waiting may be the reason why connections time out sometimes (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30498). Also there is ["How come some Snowflake bootstrap attempts are so slow?" in the wiki](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/Vision-for-the-Future).
I believe this will require updates to the broker API. Maybe for each proxy/client pair broker needs to make a WebSocket pair that will forward the ICE candidates between them. Or maybe a conventional HTTP request would suffice, as we already have IDs (e.g. see the `/answer` request). Or can they be exchanged through the P2P connection itself?
Code:
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/2c008d6589e37e77f01a364ab414d6a95218de36/client/lib/webrtc.go#L241-242
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/97dea533da7b6b3b2b1dfbffe7dca3a8350fab0b/proxy/lib/snowflake.go#L403-406
Some more resources about WebRTC:
* https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity#the_entire_exchange_in_a_complicated_diagram
* https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Perfect_negotiationhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40163client: don't timeout connection attempts until some connection succeeds2023-06-21T09:15:24ZWofWcawofwca@protonmail.comclient: don't timeout connection attempts until some connection succeedsSo when trying to connect, instead of dropping a connection, then starting a new one we could just start a new one in parallel, hoping that the old one will succeed. Then, when one (or however many we need) succeeds, drop the other ones....So when trying to connect, instead of dropping a connection, then starting a new one we could just start a new one in parallel, hoping that the old one will succeed. Then, when one (or however many we need) succeeds, drop the other ones.
We probably still need keep the timeout, but make it longer.
I am not sure if there is already code that does this. If there is, then I think `DataChannelTimeout` simply needs to be made greater than `ReconnectTimeout`.
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/c983c13a84554d0ba1ffcdd054491090c0eafc54/client/lib/snowflake.go#L47-57
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/c983c13a84554d0ba1ffcdd054491090c0eafc54/client/lib/webrtc.go#L174-182
Related:
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40025
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25723
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30498https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40162Snowflake Broker Deployment 22-07-222023-07-28T23:47:27ZshelikhooSnowflake Broker Deployment 22-07-22This deployment is needed to fix https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40161.
## Deployment Script
```
sv stop snowflake-broker
cp /etc/service/snowflake-broker/run ./snowflake-broker...This deployment is needed to fix https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40161.
## Deployment Script
```
sv stop snowflake-broker
cp /etc/service/snowflake-broker/run ./snowflake-broker-run-22-07-22-backup-$(date +%N)
install --owner root ./snowflake-broker-run-22-07-22-candidcate /etc/service/snowflake-broker/run
sv start snowflake-broker
```
## New Run File
```
#!/bin/sh -e
setcap 'cap_net_bind_service=+ep' /usr/local/bin/broker
export GOMAXPROCS=1
exec chpst -u snowflake-broker -o 32768 /usr/local/bin/broker --metrics-log /home/snowflake-broker/metrics.log --acme-hostnames snowflake-broker.bamsoftware.com,snowflake-broker.freehaven.net,snowflake-broker.torproject.net --acme-email dcf@torproject.org --acme-cert-cache /home/snowflake-broker/acme-cert-cache --bridge-list-path /home/snowflake-broker/bridge_lists.json --default-relay-pattern ^snowflake.torproject.net$ --allowed-relay-pattern ^snowflake.torproject.net$ -ip-count-log /home/snowflake-broker/metrics-ip-salted.jsonl -ip-count-interval 1h -ip-count-mask ****** 2>&1
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40161Snowflake Broker IP Change Rate Data HMAC Key Used the default value2023-07-29T18:04:14ZshelikhooSnowflake Broker IP Change Rate Data HMAC Key Used the default valueThis is an issue discovered in the https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40151 's configuration that the `ip-count-mask` used the default value, and make the counting result unsuitable ...This is an issue discovered in the https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40151 's configuration that the `ip-count-mask` used the default value, and make the counting result unsuitable for publishing.
I will deploy it again tomorrow with a randomly generated HMAC key. The collected unsalted IP count data will be retained and used for internal research only. It is not useless either, since it has collected data for over a month, and could be used for validation of this feature.shelikhooshelikhoo2022-08-03https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40159Make Snowflake recognize FascistFirewall2022-10-28T19:15:17ZcypherpunksMake Snowflake recognize FascistFirewallSnowflake takes a long time to start a connection when a firewall is blocking outgoing ports. If the tor daemon or Tor Browser is configured to connect only to certain ports, then Snowflake could recognize that setting and not take so lo...Snowflake takes a long time to start a connection when a firewall is blocking outgoing ports. If the tor daemon or Tor Browser is configured to connect only to certain ports, then Snowflake could recognize that setting and not take so long to start a connection. Right now, Snowflake stalls when that setting is enabled, regardless of a firewall.
In the tor daemon, the settings are `FascistFirewall` and `ReachableAddresses`. In Tor Browser, the setting is located at `Settings --> Connection --> Advanced --> "Configure how Tor Browser connects to the internet" (Settings... button) --> "This computer goes through a firewall that only allows connections to certain ports" (80,443)`.
Going further, Snowflake could assume after certain conditions also that Tor Project's [ReducedExitPolicy](https://gitlab.torproject.org/legacy/trac/-/wikis/doc/ReducedExitPolicy) is enabled in the firewall.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40158Change name "Snowflake" -> "North Star"2022-07-18T18:12:15ZWofWcawofwca@protonmail.comChange name "Snowflake" -> "North Star"Of course there's probably no strong reason to do this, just a funny idea I had.
Symbolism: North Star - guidance (to the free internet), North - ICE, cold (like it is now with Snowflake).
"Polaris" would be another layer, but too compl...Of course there's probably no strong reason to do this, just a funny idea I had.
Symbolism: North Star - guidance (to the free internet), North - ICE, cold (like it is now with Snowflake).
"Polaris" would be another layer, but too complicated, I think.
Maybe there's gonna be another similar project that can take this name.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40157Add missing 2.3.0 tag to gitweb.torproject.org2022-07-13T16:22:22ZtlaAdd missing 2.3.0 tag to gitweb.torproject.orgThe tag v2.3.0 is still missing in this repo:
https://gitweb.torproject.org/pluggable-transports/snowflake.git/refs/
Which of these now is the source-of-truth?
I'd say, it's not a good idea, to keep 2 repositories around, but if, the...The tag v2.3.0 is still missing in this repo:
https://gitweb.torproject.org/pluggable-transports/snowflake.git/refs/
Which of these now is the source-of-truth?
I'd say, it's not a good idea, to keep 2 repositories around, but if, they should get synchronized automatically.shelikhooshelikhoo