Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-09-01T23:42:21Zhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62Prepare for s28 PI meeting: May 10 20222022-09-01T23:42:21ZCecylia BocovichPrepare for s28 PI meeting: May 10 2022We'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.
We should gather the information we need some days before May 11 (say, by May 5 latest)...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.
We should gather the information we need some days before May 11 (say, by May 5 latest), so there is enough time to organize it into a coherent presentation and enough time to notice missing things (e.g. graphs and diagrams) and collect them too.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)2022-05-11https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/3Create a local test environment for Conjure client, relay station, and bridge2022-06-30T16:27:34ZCecylia BocovichCreate a local test environment for Conjure client, relay station, and bridgeWe're going to have to work with Eric and the refraction networking relay station maintainers to deploy connect the various Conjure pieces we need. Ideally we'd set up a test environment to try out different details and designs first so ...We're going to have to work with Eric and the refraction networking relay station maintainers to deploy connect the various Conjure pieces we need. Ideally we'd set up a test environment to try out different details and designs first so we're not just testing everything in production.
I've done a Docker-based setup for testing refraction networking (a.k.a decoy routing) before with the [Slitheen test-env](https://gitlab.com/slitheen/test-env). Something similar might be repurposed here.Sponsor 30 - Objective 2.3Cecylia BocovichCecylia Bocovich2022-05-27https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/2Create a Tor PT server for Conjure2022-06-30T16:27:34ZCecylia BocovichCreate a Tor PT server for ConjureThere's a few details we need to sort out for what the Conjure bridge is going to actually look like. The [refraction networking relay station code](https://github.com/refraction-networking/conjure) is responsible for negotiating IP endp...There's a few details we need to sort out for what the Conjure bridge is going to actually look like. The [refraction networking relay station code](https://github.com/refraction-networking/conjure) is responsible for negotiating IP endpoints with the Conjure client and speaking the server side of whichever obfuscation protocol the client chose (in our case this will likely be obfs4).
Once the relay station strips off this obfuscation layer, it should send the resulting traffic to our Conjure bridge. We might have to work with Eric and the refracton networking relay station maintainers to sort out the details, but this will ideally speak something like [Tor's ExtOrPort PT spec](https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt#n373) sent over an encrypted connection with with the bridge and be able to carry information like the client's address so we can do metrics.Sponsor 30 - Objective 2.3Cecylia BocovichCecylia Bocovich2022-06-03https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/1Create a Tor PT client for conjure2022-06-30T16:27:34ZCecylia BocovichCreate a Tor PT client for conjureWe can import the [refraction networking client](https://github.com/refraction-networking/gotapdance) code as a library directly from our main program as described in the code snippet in their [README](https://github.com/refraction-netwo...We can import the [refraction networking client](https://github.com/refraction-networking/gotapdance) code as a library directly from our main program as described in the code snippet in their [README](https://github.com/refraction-networking/gotapdance#usage).
This will be done similarly to how the Snowflake client now calls the Snowflake client library from [the main Go package](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/0054cb2dec19e89e07b8c5a6d8b9d23589842deb/client/snowflake.go).Sponsor 30 - Objective 2.3Cecylia BocovichCecylia Bocovich2022-06-10https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/85is Wolpertinger being used?2022-07-21T10:22:02ZGabagaba@torproject.orgis Wolpertinger being used?It seems that nobody is using Wolpertinger anymore. If nobody is using it we are going to
- [x] turn off the service and
- [x] archive the project.
Please add any concern or comment to this ticket if not.
https://gitlab.torproject....It seems that nobody is using Wolpertinger anymore. If nobody is using it we are going to
- [x] turn off the service and
- [x] archive the project.
Please add any concern or comment to this ticket if not.
https://gitlab.torproject.org/tpo/anti-censorship/wolpertingermeskiomeskio@torproject.orgmeskiomeskio@torproject.org2022-07-22https://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/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/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/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/40179Reduce turbotunnel queueSize from 2048 to 5122022-12-08T15:04:48ZDavid Fifielddcf@torproject.orgReduce turbotunnel queueSize from 2048 to 512After yesterday's deployment of `io.Copy` memory mitigations (tpo/anti-censorship/pluggable-transports/snowflake#40177), memory use has crept up above 90% again.
I recommend implementing the [next most effective memory save](https://list...After yesterday's deployment of `io.Copy` memory mitigations (tpo/anti-censorship/pluggable-transports/snowflake#40177), memory use has crept up above 90% again.
I recommend implementing the [next most effective memory save](https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000253.html)
revealed by [profiling](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40086#note_2837328): decreasing the turbotunnel `queueSize`.
This is a fixed block of memory that's allocated per connected client.
In https://gitlab.torproject.org/dcf/snowflake/-/commit/328f0f4137145c08e58311888ad359362abaea79
I've reduced the parameter from 2048 to 512.
I don't know what effect this might have on performance,
apart from reducing memory use.
Past discussion about `queueSize`:
* https://lists.torproject.org/pipermail/anti-censorship-team/2021-July/000188.html
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/48#note_2744619David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-09-27https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40198Out of localhost ephemeral ports ("cannot assign requested address") on link ...2023-06-08T19:26:08ZDavid Fifielddcf@torproject.orgOut of localhost ephemeral ports ("cannot assign requested address") on link between snowflake-server and haproxySince 2022-09-28 10:57:26 (53 hours ago) the snowflake-server log is full of:
```
# grep 'cannot assign requested address$' /var/log/snowflake-server/snowflake-server.log | head
2022/09/28 10:57:26 handleConn: failed to connect to ORPor...Since 2022-09-28 10:57:26 (53 hours ago) the snowflake-server log is full of:
```
# grep 'cannot assign requested address$' /var/log/snowflake-server/snowflake-server.log | head
2022/09/28 10:57:26 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/28 10:57:26 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/28 10:57:26 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/28 10:57:26 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/28 10:57:26 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
# grep 'cannot assign requested address$' /var/log/snowflake-server/snowflake-server.log | tail
2022/09/30 15:44:17 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/30 15:44:18 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/30 15:44:18 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/30 15:44:18 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
2022/09/30 15:44:18 handleConn: failed to connect to ORPort: dial tcp [scrubbed]: connect: cannot assign requested address
```
The error message means that the kernel could not allocate an ephemeral port number
for a localhost TCP connection.
In this case it for the connection between snowflake-server and haproxy.
My analysis at https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000265.html was incomplete:
the total number of localhost sockets does not matter for the purpose of counting 4-tuples,
but it *does* matter for the purpose of allocating ephemeral ports.
There are currently only 21712 sockets open between snowflake-server and haproxy,
which means the remainder of the ephemeral port range is taken up by other
localhost communication.
My immediate plan for this is to move haproxy to 127.0.0.2:10000 rather than 127.0.0.1:10000,
and maybe similarly with the individual tor instances if necessary.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-09-30https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/3O1.3: Implement bridges with pluggable transport HTTPT support.2022-10-04T17:27:22ZGabagaba@torproject.orgO1.3: Implement bridges with pluggable transport HTTPT support.HTTPT is a promising new pluggable transport designed to hide traffic behind HTTPS servers. HTTPT has specific benefits for the case of making Tor more accessible to users in China; specifically that it is immune to replay attacks, which...HTTPT is a promising new pluggable transport designed to hide traffic behind HTTPS servers. HTTPT has specific benefits for the case of making Tor more accessible to users in China; specifically that it is immune to replay attacks, which protects it against China’s active probing; it uses existing web servers, so that it’s harder for censors to discover; it requires minimal overhead; and it relies on TLS, a popular protocol, making it much more difficult for censors to block outright. In this Activity we will make Tor Browser and HTTPT work together before pushing for more users in the target region and launching it in Tor Browser.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoo2022-09-30https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40125Update Landing Page (snowflake.torproject.org)2023-03-15T14:48:30ZsereneUpdate Landing Page (snowflake.torproject.org)We've had feedback that the snowflake.torproject.org landing page has been somewhat confusing / unclear. Many users are unsure whether to install the Snowflake Browser Extension, or run Tor Browser. (eg. Many users in Russia have install...We've had feedback that the snowflake.torproject.org landing page has been somewhat confusing / unclear. Many users are unsure whether to install the Snowflake Browser Extension, or run Tor Browser. (eg. Many users in Russia have installed the extension instead, being proxies instead of clients!)
I threw together a draft of an [updated landing page](https://serene.cx/snowflake-torproject-org-draft/ ) by slightly modifying the [current one](https://snowflake.torproject.org/).
To be improved further, but it's an idea:
![Screen_Shot_2022-04-11_at_18.16.33](/uploads/dccb730fb60564a0b9a4cf26a946a223/Screen_Shot_2022-04-11_at_18.16.33.png)
- I think the Tor Browser screenshot also needs to be updated.
- I have another idea, which I'll include in a separate ticket.
- Is this managed / on a separate host from main torproject.org?
This Snowflake landing page can be the very first place people see, so we should make it much more clear & helpful for the users. Let me know next steps @gus @gaba :)meskiomeskio@torproject.orgmeskiomeskio@torproject.org2022-09-30https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/119Update circumvention map in Iran and provide snowflake as first option2022-09-29T18:08:27ZGusUpdate circumvention map in Iran and provide snowflake as first optioncircumvention map:`"ir":{"settings":[{"bridges":{"type":"obfs4","source":"bridgedb"}},{"bridges":{"type":"snowflake","source":"builtin"}}]}`
Snowflake seems to work quite well in Iran according to [OONI probe tests](https://explorer.oon...circumvention map:`"ir":{"settings":[{"bridges":{"type":"obfs4","source":"bridgedb"}},{"bridges":{"type":"snowflake","source":"builtin"}}]}`
Snowflake seems to work quite well in Iran according to [OONI probe tests](https://explorer.ooni.org/chart/mat?probe_cc=IR&test_name=torsf&since=2022-09-14&until=2022-09-21&axis_x=measurement_start_day), while bridgeDB could be distributing blocked bridges.
So, should we change the priority here? Snowflake first, and if it fails, bridgeDB bridges? (cc: @meskio)shelikhooshelikhoo2022-10-03https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/92Prepare for s28 PI and ECP presentations: Oct 31 and Nov 1-2 20222023-01-08T18:03:25ZRoger DingledinePrepare for s28 PI and ECP presentations: Oct 31 and Nov 1-2 2022In the tradition of https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62, we have another PI meeting coming up at the beginning of November, where we will want to present the current state of Tor anti-censorship, the situat...In the tradition of https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62, we have another PI meeting coming up at the beginning of November, where we will want to present the current state of Tor anti-censorship, the situation with deployment and usage of our pluggable transports (obfs4 and snowflake in particular), what we're up to next, etc.
The text from the previous ticket is still a good summary of info I'll be trying to collect and present:
* (0) Did we make any changes to the Snowflake architecture as deployed on Race? Did we find and/or fix any especially interesting Snowflake-on-Race issues? It's fine if the answer here is "no, we did all the hard work last year, this time it was clear sailing".
* (1) Our deployed transports (Snowflake, obfs4, and meek/moat):
* user-evident dev progress (security and obfuscation fixes, new features, performance changes)
* adoption (trends in growth of users or capacity or load; or different countries joining the story)
* (2) Task Area One (censorship analysis) progress. Who is censoring components of the Tor ecosystem, how, when, where, for how long?
* (3) Task Area Two (reputation-based bridge distribution strategies) progress.
* (4) Progress on our anti-censorship roadmap tasks. We don't need to make progress on every one of them, but we should have something impressive on some of them. Here are some highlights from the Q1 roadmap where progress would count as interesting:
* Snowflake performance (especially in Asia)
* Conjure and httpt
* Scale Tor reachability through mobile Snowflakes
* React and steer our response to censorship
* Monitor bridge health
* Improved UX for users getting bridges in practice (e.g. "Make it easier for humans & harder for censors to get bridges from moat distributor.", "Improve automatic censorship detection during bootstrapping in Tor Browser (desktop and Android)")
* (5) Collaborations or interactions with external anti-censorship research groups or NGOs that caused (or that we think will cause) the world to become a better place wrt censorship. This one is broad, and we've been too busy and too small to interact much lately, but I have it on the list here in case we notice something, and because hopefully in future iterations we'll start having some answers.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Roger DingledineRoger Dingledine2022-10-28https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/99Do obfs4 settings bridges work better in china and hong knog?2022-11-28T13:25:47Zmeskiomeskio@torproject.orgDo obfs4 settings bridges work better in china and hong knog?Right now in China in the circumvention map we recommend snowflake, which in user research has being behaving very slow there. And in Hong Kong we don't provide any configuration, so if tor fails to connect TB will try to use the builtin...Right now in China in the circumvention map we recommend snowflake, which in user research has being behaving very slow there. And in Hong Kong we don't provide any configuration, so if tor fails to connect TB will try to use the builtin bridges.
Let's configure both countries to use obfs4 settings bridges. We'll wait 10 days after enabling them and see if there is an increase of users and/or complains from them in the support channels.
cc: @gus @duncanSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.org2022-11-09https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/109Tor Browser 12.0 will only ship a single multi-locale bundle2022-12-13T14:06:40ZrichardTor Browser 12.0 will only ship a single multi-locale bundleThere will only be 1 version of Tor Browser per platform rather than the current 36; all locales will be bundled in a single package. Get Tor should be updated appropriately.There will only be 1 version of Tor Browser per platform rather than the current 36; all locales will be bundled in a single package. Get Tor should be updated appropriately.meskiomeskio@torproject.orgmeskiomeskio@torproject.org2022-12-16https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40239Experiment with increasing conntrack table size on snowflake-012024-01-22T15:19:37ZDavid Fifielddcf@torproject.orgExperiment with increasing conntrack table size on snowflake-01During performance experimentation we (@linus and I) [disabled connection tracking](tpo/anti-censorship/pluggable-transports/snowflake#40189), suspecting it as a cause of high CPU use and because the conntrack table appeared to be danger...During performance experimentation we (@linus and I) [disabled connection tracking](tpo/anti-censorship/pluggable-transports/snowflake#40189), suspecting it as a cause of high CPU use and because the conntrack table appeared to be dangerously close to being full.
Let we [re-enabled connection tracking](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40203#note_2851633) to no apparent ill effect.
[Performance optimizations in snowflake-server](tpo/anti-censorship/pluggable-transports/snowflake!100) were enough to bring the CPU use under control.
The conntrack table still appears to be close to overflowing, but we are not actually seeing any "nf_conntrack: table full, dropping packet" kernel logs that would indicate an actual problem.
At this moment the conntrack table is 92% full (`nf_conntrack_count` / `nf_conntrack_max` = 240316 / 262144).
It could be that this is normal and nothing to worry about.
Let's try doubling the maximum number of entries and see if it reaches a new equilibrium.
Currently we have:
```
# cat /proc/sys/net/netfilter/nf_conntrack_{count,max,buckets}
240316
262144
65536
```
I'm going to do this:
```
echo 131072 > /proc/sys/net/netfilter/nf_conntrack_buckets
echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max
```
And meanwhile I'll run a tracking script to record `nf_conntrack_count` once per minute.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-12-21https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40056O1.2: Increase the number of Snowflake proxies.2022-07-05T18:08:28ZGabagaba@torproject.orgO1.2: Increase the number of Snowflake proxies.With limited ramp up so far, we already have 6,000 volunteers running Snowflakes. Increasing Snowflake operators through more aggressive promotion will allow us to rapidly increase unblocked bridge entry points to the Tor network by thou...With limited ramp up so far, we already have 6,000 volunteers running Snowflakes. Increasing Snowflake operators through more aggressive promotion will allow us to rapidly increase unblocked bridge entry points to the Tor network by thousands.
- O1.2.1: Run a public campaign to encourage Internet users to install the Snowflake extension in Firefox or Chrome and use their web browser to act as bridges for censored people. This campaign will target individuals who care about free access to information but who may have limited capacity to operate a traditional bridge.
- O1.2.2: Scale Tor reachability through mobile Snowflakes. It’s also possible to build the Snowflake into mobile applications. We can rapidly increase the availability and diversity of bridge IP addresses that are not blocked in China by asking the millions of active Orbot users to “help censored users connect to Tor.” Through the Internews DISRUPT program, Guardian Project is designing and implementing “Orbot as Bridge” capability with the use of Snowflake, and as a result of this Activity, any Orbot user will be able to become a Snowflake bridge to Tor when they are not actively using their device. Guardian Project is also implementing as much of this capability as possible in Onion Browser for iOS.1 To do so, Guardian Project will: continue to improve Tor+Snowflake stability & performance on mobile devices and tune mobile-as-Snowflake bridge usability and performance, especially considering connections from the target regions.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet2022-12-31