BridgeDB should consider a user's location

bridges.torproject.org knows the user's physical location and should consider it when returning bridges. For example, if somebody in country X asks for an obfsN bridge but BridgeDB knows that only obfsN+1 works in X (e.g., by consulting the result of tpo/community/outreach#28531 (moved)), it should return obfsN+1.

Ideally, we would do this for all of BridgeDB's distribution mechanisms. We could also do it for email – if the user emailed bridges+CC@bridges.torproject.org. As I understand it, we cannot do it for moat because BridgeDB doesn't get to see the user's IP address in this case.

Trac:
Parent Ticket: legacy/trac#31280 (moved)

added component::circumvention/bridgedb in Legacy / Trac parent::31280 in Legacy / Trac points::10 in Legacy / Trac priority::medium in Legacy / Trac s30-o23a4 in Legacy / Trac severity::normal in Legacy / Trac sponsor::30-must in Legacy / Trac status::new in Legacy / Trac type::task in Legacy / Trac labels

I wonder if you can get the user's IP address in an X-Forwarded-For header using moat?

I also wonder what happens when your GeoIP databases are out of sync (with each other, or with the real world political control of networks). For example, what happens when IP addresses move between countries?

cohosh cc'ing myself on sponsor 30 work

Trac:
Cc: phw to phw, cohosh

changed time estimate to 80h

mentioned in issue legacy/trac#32662 (moved)

mentioned in issue legacy/trac#31280 (moved)

moved from legacy/trac#31875 (moved)

changed milestone to %Sponsor 30 - Objective 2.4

changed milestone to %Sponsor 30 - Objective 2.3

added Sponsor 30 - FINISHED Task labels and removed 1 deleted label

removed 1 deleted label

removed s30-o23a4 label

added Next label

assigned to @meskio

changed the description

AFAIK currently BridgeDB only has two kind of bridges obfs4 and vanilla. We do offer obfs4 bridges by default unless the user does explicitly request a vanilla bridge, except for email that is still vanilla bridges (#40019 (closed)). So adding information about countries might not change much the actual use today. We can achieve the same just adding a warning if a vanilla bridge is being requested telling them that the bridge might not work and they should try an obfs4 one if it fails. Is all this work worth it for the few reward?

I think the most useful thing we can do here right now is to modify moat (or create a new service) that will tell TB if it should recommend using snowflake or a bridge based on the country of origin. We could also use it to recommend snowflake if we know bridges are blocked in other distributors but I would expect the https distributor to be blocked if bridges are blocked and the email distributor will require providing manually the country and that will not be that easy to use.

I guess for now we don't plan to have any automatic tool to produce the country rules, they will be manually produced. Isn't it?

I think the most important tasks I see we need to do are:

• figure out how to provide the country in moat, can the domain fronting sim pass it along?
• define a file format (maybe like tpo/community/outreach#28531 (comment 2560517)) that will be fed into BridgeDB and any other tool that needs it
• extend moat protocol to tell TB what kind of transport will work on this country

Other nice to have:

• extend email distributor to accept a country code as parameter
• geolocate IP addresses on the https distributor
• recommend using snowflake if bridges are blocked in the country
• provide vanilla bridges by default if we know they work on this country

I just found that there is already an issue to do what I'm proposing to do as part of moat but in rdsys: rdsys#34 (moved)

And an existing json format: https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob/main/state-of-censorship.json

added 1h of time spent

marked this issue as related to rdsys#34 (moved)

changed milestone to %Sponsor 30 - Objective 3.3

For now the block list will be integrated in Tor Browser and the firefox geolocation service will be used. We might want to plan for a future just in case the firefox geolocation service gets blocked and maybe moat could offer that service or if the list needs to get updated faster than the TB releases.

added Backlog label and removed Next label

Sorry just seeing these comments now. I think this ticket scope is much smaller than this.

My understanding is that this ticket is not for the more general integration with Tor Browser's automatic location-based circumvention preferences, it's for BridgeDB requests. At this time there is no plan to have the automatic Tor Browser configs provide email or HTTPS BridgeDB bridges as one of the config options anyway (there's no way to perform these directly in Tor Browser before bootstrapping). The automatic local-based circumvention with Tor Browser is being tracked elsewhere. We have this ticket on our side: #40025 (closed)

The idea for this ticket is that if a user sends an email/https/moat request for a vanilla bridge, and their country code indicates that vanilla bridges are not useful, then we give them obfs4 instead. Because of the way the UX works for all of our distribution methods, we default to obfs4 anyway (or will with #40019 (closed)) and users have to try pretty hard to get vanilla bridges. You're right that given we only have two options and we're already providing the strictly better options by default, it's not the highest priority right now.

I'd suggest leaving this ticket until after we have rdsys more fully implemented, rather than adding new and possibly complex features to BridgeDB's distributors.

The idea for this ticket is that if a user sends an email/https/moat request for a vanilla bridge, and their country code indicates that vanilla bridges are not useful, then we give them obfs4 instead. Because of the way the UX works for all of our distribution methods, we default to obfs4 anyway (or will with #40019 (closed)) and users have to try pretty hard to get vanilla bridges.

If we provide obfs4 by default and the user manually asks for a vanilla bridge, I'm not sure how sensible is to provide something different than what the user has explicitly requested. I would expect that users that click on the advanced options will know better than what we can guess of what they need.

Another whole problem is how to know the provenance of the user over the email distributor, they will need to tell use their country of provenance.

If we provide obfs4 by default and the user manually asks for a vanilla bridge, I'm not sure how sensible is to provide something different than what the user has explicitly requested. I would expect that users that click on the advanced options will know better than what we can guess of what they need.

+1 I could see likely edge cases where a user does want a vanilla bridge even if they are blocked in their country.

I'll close this ticket for now. I think we settled on this feature not being useful in the current state, and that we still want users to be able to request vanilla bridges even if they may be blocked in their area. Please re-open if it's a mistake.

closed