New release: Tor Browser 13.0

Hi,
it’s a sort of known bug.
We use fingerprints to get data for the circuit display, because that’s what Tor always uses.
And if the user doesn’t provide a fingerprint in the bridge line we have some difficulties in getting the actual IP (we can query tor for node information when it’s a standard relay, for bridges it’s more difficult, we won’t know the IP as it’s secret/not even provided for some PTs, such as Snowflake).
We could lie and if there’s only one bridge line and bridges are enabled always tell that this is the current bridge (well, also “current” is another small lie, since Tor often uses two guards/bridges)… but we wouldn’t back that with actual data.
Anyway, I think we could better handle this case and just write unknown bridge.

I must admit that in general vanilla bridges aren’t tested that much, because they aren’t very effective :sweat_smile:.
If I understand correctly, vanilla bridges use the Tor protocol without trying to hide it, therefore they should be quite easy to block. They work well only when the censor blocks the IP addresses of normal relays.

3 Likes