A STUN server cannot directly see who is connecting to whom, but it can infer it to some certainty based on timing, i.e. when two STUN requests are sent roughly at the same time by the two peers, if they use the same STUN server.
All STUN does basically is telling the clients what their public IP and port is.
If you are willing to monitor whether the STUN server(s) of your choosing is up, and change it if/when it goes down, you can go ahead.
STUN servers are comparably cheap to run, amount of data per client is very low.
But, for comparison, the Snowflake proxy and the client have to do rendezvous through the broker, which the client has to connect to through third-party services, such as Amazon, so using a private STUN server does not fully eliminate such privacy issues for Snowflake.
To end with a philosophical take, censorship circumvention and privacy are distinct things.
So for now, since there is only one STUN server, Google knows that I’m offering and who is asking but not who actually makes a connection. When commit 9ff205dd goes into production for both the client and proxy then the odds go down to 25%. Kinda. Good idea.
I see two here who also posted on the thread Issue with commit 9ff205dd? that the solution was to revert to 1 STUN server.
OK, so you lost me. In that previous post your solution was to start the proxy with -stun stun:stun.l.google.com:19302 which @WofWca says: To “revert” that commit, try adding -stun=stun:stun.l.google.com:19302 to only use one STUN server again.
In any case what does using 2 STUN servers do for you and the proxy you run. It’s a simple change to make. Really my question is what would that give my proxy.
It’s off-topic for this thread but that other topic is now closed.
I should say that it doesn’t work like this.
Firsly, the client and the proxy use different STUN servers. There are a lot more STUN servers for the client, for censorship-resistance.
Secondly, the proxy will use all of the specified STUN servers, simultaneously. The “pick a few random ones” only applies to the client.
Then I misread that topic. I thought your problem was related to 2 STUN servers. Still, what would 2 STUN servers give me? If to do with opening UDP ports then it is still off the table.
OK, so with that info, then any corelation between client and proxy would be a fluke and thus useless. I looked at the code for the client and only saw one but did not look further.
Reading back this thread it almost sounds like conspiracy theorists in a discussion. I bet Google hasn’t the remotest interest in this corelation even if it were possible.
Maybe this is a real free service from Google and I was wrong. WOW
Edited later: I looked at the Firefox extension code which a proxy. So ignore the comment about looking at the code and only saw one.
Yeah I was just curious as I’m trying to research what route is the best to go for me contributing with the network either a Entry node or snowflake is what I’m looking at.
From what I read here entry nodes are not for a home connection. Bandwidth, blacklist, etc, etc. Correct me if I am wrong.
I run a snowflake proxy on a home connection. Since September, this year, I have never gotten more than 7 open concurrent connections. I started with -capacity 12, then 16, 20, and now 24. Next startup I will try 100 just to see. My upload/download is 10/30 Mbps so maybe this could be it. The machine is a monster thus not the problem. I use my own statistics analysis code.
It was suggested this was because I’m a restricted NAT and opening up UDP ports via forwarding would make me unrestricted and solve this. Documentation clearly states Snowflake takes into consideration this normal behavior of home connections. I see this logic but am not in a position to do so now, and even if I could, am not sure I would want to on my home connection. In September I supplied about 3.5 GiB of circumvention traffic which was not available the month before.
The future may change this opinion. It’s really nice to give censors the middle finger. Is there an emoji for this?