You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Orbot now provides an "Ask Tor" feature that will use the circumvention settings API at https://bridges.torproject.org/moat/circumvention/map to choose the best bridges (or lack thereof) based on a user's location.
Looking at Orbot's code for parsing circumvention map results, I noticed that while Orbot will use the suggested bridge lines if the bridge is of type "obfs4", it uses its own builtin snowflake bridge lines if the bridge type is "snowflake". This issue is to use the suggested snowflake bridge returned from the API call rather than the builtin ones.
One of the advantages of the circumvention map API is that we can update it quickly in response to censorship events without having to wait for a release cycle to update builtin bridges. If for example a uTLS fingerprint gets censored in a specific place, we can update the provided snowflake bridge lines immediately. Or, more recently we had to update snowflake bridge lines to fix a problem with the builtin domain front.
As an aside, I'm not very familiar with Kotlin and I'm curious about how the radio button selection works when iterating through the circumventionApiBridges. If only one radio button option can be selected at a time, does Orbot only select the first provided bridge in practice and not iterate through all the bridges in the list?
The text was updated successfully, but these errors were encountered:
Our logic for parsing the API results is basic, and just our first pass. I think we didn't realize the depth of information that could be provided if snowflake or other non obfs4 options were listed. This is good to know, and a good time for us to update that logic.
Until recently, Orbot Apple did the same, but because the rate of changes to Snowflake configuration increased in the recent months, I added updating the built-in configuration via the cirumvention API last week to the IPtProxyUI library, which is used in multiple apps: tladesignz/IPtProxyUI-ios@1fab4c3
I'll release a new Orbot Apple version this week containing the changes.
Orbot now provides an "Ask Tor" feature that will use the circumvention settings API at https://bridges.torproject.org/moat/circumvention/map to choose the best bridges (or lack thereof) based on a user's location.
Looking at Orbot's code for parsing circumvention map results, I noticed that while Orbot will use the suggested bridge lines if the bridge is of type "obfs4", it uses its own builtin snowflake bridge lines if the bridge type is "snowflake". This issue is to use the suggested snowflake bridge returned from the API call rather than the builtin ones.
One of the advantages of the circumvention map API is that we can update it quickly in response to censorship events without having to wait for a release cycle to update builtin bridges. If for example a uTLS fingerprint gets censored in a specific place, we can update the provided snowflake bridge lines immediately. Or, more recently we had to update snowflake bridge lines to fix a problem with the builtin domain front.
As an aside, I'm not very familiar with Kotlin and I'm curious about how the radio button selection works when iterating through the
circumventionApiBridges
. If only one radio button option can be selected at a time, does Orbot only select the first provided bridge in practice and not iterate through all the bridges in the list?The text was updated successfully, but these errors were encountered: