The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:43:24Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/8616Improve the interface of the mail distributor of BridgeDB2020-06-27T13:43:24ZGeorge KadianakisImprove the interface of the mail distributor of BridgeDBThe strings and interface of the BridgeDB mail distributor can be improved to be more user-friendly.The strings and interface of the BridgeDB mail distributor can be improved to be more user-friendly.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/8615BridgeDB and Pluggable Transports2020-06-27T13:43:24ZGeorge KadianakisBridgeDB and Pluggable TransportsThis is a parent ticket for all BridgeDB+PTs tickets.This is a parent ticket for all BridgeDB+PTs tickets.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/8614BridgeDB should be able to return multiple transport types at the same time2020-06-27T13:43:24ZGeorge KadianakisBridgeDB should be able to return multiple transport types at the same timeIn https://lists.torproject.org/pipermail/tor-dev/2013-March/004505.html we decided to add a "Get Bridges" button to the HTTP interface of BridgeDB, which will provide users with bridges compatible with the latest obfsbundle.
This means...In https://lists.torproject.org/pipermail/tor-dev/2013-March/004505.html we decided to add a "Get Bridges" button to the HTTP interface of BridgeDB, which will provide users with bridges compatible with the latest obfsbundle.
This means that if the latest obfsbundle supports both obfs2 and obfs3 bridges, the "Get Bridges" button should return both obfs2 and obfs3 bridges (and some normal ones too).
The current BridgeDB code does not allow to return multiple types of bridges at the same time.Matthew FinkelMatthew Finkelhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/8407BridgeDB should help people get non-obfs2 obfsbridges2020-06-27T13:43:24ZGeorge KadianakisBridgeDB should help people get non-obfs2 obfsbridges```
$ grep obfs3 bridges | wc -l
23
```
We are currently distributing 23 obfs3 bridges. That's not too shabby. Seems like we are approaching the multiple pluggable transport deployment stage.
Unfortunately, because of the lack of user ...```
$ grep obfs3 bridges | wc -l
23
```
We are currently distributing 23 obfs3 bridges. That's not too shabby. Seems like we are approaching the multiple pluggable transport deployment stage.
Unfortunately, because of the lack of user education, I bet that no users know that they can use obfs3 bridges with the latest obfsbundles. Furthermore, the bridges.tpo interface is not very helpful either. It just says _Looking for obfsproxy bridges?_ and gives users obfs2 bridges. We should be more friendly towards multiple transports these days.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/8241asking for obfs3 by https doesn't tell you how to ask for obfs3 by gmail2020-06-27T13:43:25ZRoger Dingledineasking for obfs3 by https doesn't tell you how to ask for obfs3 by gmailOn https://bridges.torproject.org/?transport=obfs3 it says
"""
Another way to find public bridge addresses is to send mail to bridges@torproject.org with the line "get bridges" by itself in the body of the mail.
"""
Shouldn't it be tell...On https://bridges.torproject.org/?transport=obfs3 it says
"""
Another way to find public bridge addresses is to send mail to bridges@torproject.org with the line "get bridges" by itself in the body of the mail.
"""
Shouldn't it be telling me how to ask bridges@torproject.org for obfs3 bridges?Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/8194Implement special handling of bridges on dynamic ip addresses2020-06-27T13:43:25ZcypherpunksImplement special handling of bridges on dynamic ip addressesBridgeDB should recognize bridges whose IP addresses change very often. These bridges on dynamic ip addresses should be published with a dedicated promotion strategy.
Someone should open a ticket named "Get more developers" with priorit...BridgeDB should recognize bridges whose IP addresses change very often. These bridges on dynamic ip addresses should be published with a dedicated promotion strategy.
Someone should open a ticket named "Get more developers" with priority "blocker"...Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/7550BridgeDB email responder is not interactive2020-06-27T13:43:25ZAaron GibsonBridgeDB email responder is not interactiveBridgeDB's email response mentions that it supports queries for ipv6 bridges and bridges with specified transports, but the rate limiting feature prevents the responder from being used in an interactive way.
We could modify the rate li...BridgeDB's email response mentions that it supports queries for ipv6 bridges and bridges with specified transports, but the rate limiting feature prevents the responder from being used in an interactive way.
We could modify the rate limiting feature to allow several requests before responding negatively.
Alternately, the first response could include a brief set of instructions only, and only apply rate limiting to subsequent queries for bridges. However, this might be confusing, especially if not all translations are initially available.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/7547BridgeDB email response is confusing2020-06-27T13:43:25ZAaron GibsonBridgeDB email response is confusingBridgeDB's email response should be rephrased.BridgeDB's email response should be rephrased.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/7525Design a system for tracking bridge assignment metrics.2020-06-27T13:43:25ZAaron GibsonDesign a system for tracking bridge assignment metrics.We may want to evaluate bridge allocator strategies (legacy/trac#7524) as part of building a social distributor for BridgeDB (legacy/trac#7520).
If so, we should determine what metrics would be useful, how they can be collected safely, ...We may want to evaluate bridge allocator strategies (legacy/trac#7524) as part of building a social distributor for BridgeDB (legacy/trac#7520).
If so, we should determine what metrics would be useful, how they can be collected safely, and how BridgeDB might export them.
cc'ing karsten for feedback.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/7524Design a system for applying an allocator strategy2020-06-27T13:43:25ZAaron GibsonDesign a system for applying an allocator strategyThe social distributor should support a configurable allocator strategy that will assign bridges to an account by implementing a policy that may take into consideration datapoints such as:
1. age of the account
2. history of bridges all...The social distributor should support a configurable allocator strategy that will assign bridges to an account by implementing a policy that may take into consideration datapoints such as:
1. age of the account
2. history of bridges allocated to this account
3. filtering of bridges assigned to this account
4. frequency of requests for bridges
For example, an allocator strategy might be as simple as "give no more bridges to a user whose bridge was blocked"
Alternately, "give fewer bridges to accounts correlated with more blocking events than 1 standard deviation above the average"
A good idea might be to evaluate multiple simple strategies simultaneously and see which strategies are more effective.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/7523Decide whether reputation should be tracked between accounts2020-06-27T13:43:25ZAaron GibsonDecide whether reputation should be tracked between accountsFrom https://svn.torproject.org/svn/projects/design-paper/blocking.html#tth_sEc7.4:
```
We could track reputation between accounts (if you delegate to somebody who screws up, it impacts you too), or we could use blinded delegation token...From https://svn.torproject.org/svn/projects/design-paper/blocking.html#tth_sEc7.4:
```
We could track reputation between accounts (if you delegate to somebody who screws up, it impacts you too), or we could use blinded delegation tokens [5] to prevent the website from mapping the seeds' social network. We put off deeper discussion of the social network reputation strategy for future work.
```
There are some clear advantages to being able to link accounts. For example, if accounts are *not* linked, a simple attack would be to use one account to harvest tokens (invites) and use subsequently activated accounts to enumerate bridges.
However, we might not want to the liability of storing the social graph, in case the database were compromised. Perhaps we could consider an approach where links between accounts degrade (are removed) over time, or we only track a few links of the account chain.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/7522Design a user interface for redeeming invite tokens2020-06-27T13:43:25ZAaron GibsonDesign a user interface for redeeming invite tokensPlease see [comment #4 on this ticket](https://trac.torproject.org/projects/tor/ticket/7522#comment:4) for a better description of the scope of this ticket. The following description is kept for historical purposes, and is no longer rele...Please see [comment #4 on this ticket](https://trac.torproject.org/projects/tor/ticket/7522#comment:4) for a better description of the scope of this ticket. The following description is kept for historical purposes, and is no longer relevant due to developments in the design of legacy/trac#7520. —isis
### Original Description
Should this interface be web based? Email based with gpg support? Both?
Should a token be redeemed for an account, or be used each time to request a bridge?
If a token is exchanged for an account, BridgeDB would need to store account credentials provided by a user. That might be more convenient for a user to remember, but might lead to problems such as:
account names can be probed (i.e. does an account by a certain name already exist?)
users might re-use nyms, potentially a liability.
On the other hand, an account might be identified by an email address, which could be used to periodically send new bridges or invites. We want to add email subscription support to BridgeDB (legacy/trac#1610), and perhaps these features should overlap.
Perhaps we could support both modes, where a valid token can be used to request bridges and add/remove email addresses. If a user chooses to add an email address, a suitable warning would be displayed to advise the user that the email address will be stored on the system.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/7521Design a system for generating delegation tokens2020-06-27T13:43:26ZAaron GibsonDesign a system for generating delegation tokensDelegation tokens or invites should have the following properties:
Easy for a human to transcribe, from a screen or paper
Hard for a computer to brute force
Should be possible to generate offline, so that any secret key material does no...Delegation tokens or invites should have the following properties:
Easy for a human to transcribe, from a screen or paper
Hard for a computer to brute force
Should be possible to generate offline, so that any secret key material does not need to be present on the deployed system.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/7520Design a social bridge distributor2020-06-27T13:43:26ZAaron GibsonDesign a social bridge distributorThe sixth strategy outlined at https://svn.torproject.org/svn/projects/design-paper/blocking.html#tth_sEc7.4 describes a social bridge distribution strategy:
```
The sixth strategy ties in the social network design with public bridges a...The sixth strategy outlined at https://svn.torproject.org/svn/projects/design-paper/blocking.html#tth_sEc7.4 describes a social bridge distribution strategy:
```
The sixth strategy ties in the social network design with public bridges and a reputation system.
We pick some seeds — trusted people in blocked areas — and give them each a few dozen bridge addresses and a few delegation tokens.
```
Some other services use a similar system to try and restrict the set of users using an invite system. One example is private bittorrent trackers.
In an email, I described such a system:
```
Here's a simple concept for how this model might be applied to bridge
distribution:
The basic idea is:
1. Create a handful of tokens that can be exchanged for an account
that may request a bridge.
2. Periodically give accounts some tokens to hand out to ther friends.
Most (all?) of the private trackers employ a ratio system - and you
lose your account if you don't maintain a ratio above a certain
threshold. That is, they try to separate users by behavior, and drop
the ones whose behavior is undesirable.
In the context of bridges, we want to be able to separate users into
two groups: users who use bridges, and users who block them.
1. Each time a user is given a bridge, note the bridges given to that user.
2. Each time a bridge is blocked, increment a per-user counter for
every user given that bridge.
2a. Shuffle the affected users so that the same users are not given
the same bridges twice. If using a hashring, a key consisting of the
user-id+counter might be sufficient.
3. Periodically, rank users by this counter, and drop the worst N
percent of users.
4. Periodically, allocate new account tokens in proportion to
available bridges to random users in the 100-N percent.
```Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/7296Make bridges.torproject.org more user friendly2020-06-27T13:43:26ZRuna SandvikMake bridges.torproject.org more user friendlyUsers who visit bridges.torproject.org to get obfsproxy bridges are required to specify the transport by name to get a set of IP address. Most users only know these addresses as "bridges", and will not be familiar with terms such as "obf...Users who visit bridges.torproject.org to get obfsproxy bridges are required to specify the transport by name to get a set of IP address. Most users only know these addresses as "bridges", and will not be familiar with terms such as "obfs2" and "obfs3". It would also be great if the page was updated to clearly separate the normal-bridges-page from the obfs2-bridges-page.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/7207BridgeHerder: A tool to manage bridges2020-06-27T13:43:26ZAaron GibsonBridgeHerder: A tool to manage bridgesI am working on a tool that will make it easier to manage bridges on systems with multiple addresses. The tool currently detects the IP networks available on a system, configures addresses and ports and launches a configurable number of ...I am working on a tool that will make it easier to manage bridges on systems with multiple addresses. The tool currently detects the IP networks available on a system, configures addresses and ports and launches a configurable number of bridge instances.
Eventually the tool will be able to reconfigure the listening ports and addresses periodically and provide an interactive user nterface.
The idea is to make it easy to rent a dedicated server or VPS, add some IP networks, and use this tool to rotate addresses periodically (or in response to censorship events). I have a box from a provider who claims "Unlimited Free IP Addresses*" and started writing this tool so I could easily use all the addresses available, and then use this as justification for more addresses; rinse and repeat.
With a handful of people running a similar configuration we should be able to double the number of number of listening ports advertised by BridgeDB.
Some things to consider:
What frequency of address:port rotation helps the most people?
Do frequently rotating bridges (e.g. home users with dynamic IPs) see significant usage?
Should this tool be a component of TorCloud?
What other features would be useful?
Comments welcome!
*with justificationhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/6652migrate phw's brdgrd code to Tor git repo2020-06-27T13:43:26ZRoger Dingledinemigrate phw's brdgrd code to Tor git repoI think we removed all appropriate trac components for this sort of thing, so picking a related one.
We should make a brdgrd Torproject git repo, and let phw (who already has an ldap account) commit to it.
The code is currently at http...I think we removed all appropriate trac components for this sort of thing, so picking a related one.
We should make a brdgrd Torproject git repo, and let phw (who already has an ldap account) commit to it.
The code is currently at https://github.com/NullHypothesis/brdgrd
I've been asking huge bridge operators to set it up, so we should make it into something more official (plus that way more people will look at it).Sebastian HahnSebastian Hahnhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/6513Set up separate bridge email autoresponder for SponsorJ2020-06-27T13:43:26ZRoger DingledineSet up separate bridge email autoresponder for SponsorJSponsorJ wants us to give out the 75 fast bridges through a separate email autoresponder mechanism from bridgedb's bridges@tp.o.
Since these bridges will be mostly static, I think the right way to start out would be to just have a stati...SponsorJ wants us to give out the 75 fast bridges through a separate email autoresponder mechanism from bridgedb's bridges@tp.o.
Since these bridges will be mostly static, I think the right way to start out would be to just have a static string get returned -- the same three bridges from our list. When those stop working, we can reevaluate what to do next.
It would be great to have this set up by mid August. Aaron, are you a good person to pop one of these up next to / part of bridgedb?https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/6396Reachability tests for obfuscated bridges2020-06-27T13:43:26ZGeorge KadianakisReachability tests for obfuscated bridgesBridge authorities are supposed to do reachability tests to bridges.
This becomes problematic when pluggable transports are deployed since the bridge authority will need a pluggable transport to properly communicate with an obfuscated ...Bridge authorities are supposed to do reachability tests to bridges.
This becomes problematic when pluggable transports are deployed since the bridge authority will need a pluggable transport to properly communicate with an obfuscated bridge.
Here are some solutions:
a) All the pluggable transports of a bridge will be considered reachable if the ORPort of the bridge is reachable.
b) The above + a TCP scan on each transport port to make sure that the port is open.
c) The bridge authority supports many the known and widely used pluggable transports and does robust reachability tests on all the transport ports. When it does not recognize a transport, it falls back to a) or b).
As part of legacy/trac#4568 it was decided to go with a) for now. In the future, we should probably drift towards c) since it seems to be the right thing to do (Thandy deployment would also make it a bit easier).
Any ahas, opinions, thoughts or possible solutions?Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/6175BridgeDB learns to choose a reasonable number of bridges to give out2020-06-27T13:43:26ZAaron GibsonBridgeDB learns to choose a reasonable number of bridges to give outBridgeDB should learn to give out a variable number of bridges based on the number of bridges available.
For example, if a user requests bridges with transport foo, and there are only 20 bridges with this transport, BridgeDB could choos...BridgeDB should learn to give out a variable number of bridges based on the number of bridges available.
For example, if a user requests bridges with transport foo, and there are only 20 bridges with this transport, BridgeDB could choose to give out 1 bridge. If there are 21-100 bridges available, give out 2, and more than 100: 3 bridges (or the distributor maximum)
e.g.
```
if len(ring) < 20: n_bridges_per_answer = 1
if 20 < len(ring) < 100: n_bridges_per_answer = min(2,DISTRIBUTOR_N_BRIDGES_PER_ANSWER)
if len(ring) > 100: n_bridges_per_answer = DISTRIBUTOR_N_BRIDGES_PER_ANSWER
```
Or, BridgeDB could choose to avoid giving out more than 5 percent of bridges at a time; and return a minimum of 1 bridge and maximum of the configured DISTRIBUTOR_N_BRIDGES_PER_ANSWER
e.g.
```
n_bridges_per_answer = min(min(len(ring) * .05,1),DISTRIBUTOR_N_BRIDGES_PER_ANSWER)
```Aaron GibsonAaron Gibson