Decide how to handle multiple meek backends in Tor Launcher
I made a 3.6.3-meek-2 release that has a meek capable of using both [[doc/meek#GoogleAppEngine|Google App Engine]] and [[doc/meek#AmazonCloudFront|Amazon CloudFront]] as backends.
The idea behind having two (or more) is that one may work where another does not. The question is, how to usefully present the option? How is the user supposed to choose between them?
Activity
Here is how it looks now in 3.6.3-meek-2. There are two separate options, meek-amazon and meek-google.
0001-Add-an-option-to-use-meek-through-CloudFront.patch is how it looks in bridge_prefs.js. It relies on #12776 (moved) being applied first. (Actually 3.6.3-meek-2 was not built with that patch exactly, because the patch is against master, and bridge lines have to look different in the maint-3.6 branch. These two commits: meek tor-browser-bundle are the workaround needed in maint-3.6.)
What I'm worried about is a user looking at this list of weird names and not knowing which to pick. Adding more meeks isn't going to help things.
Maybe we ship one default and return other backends through BridgeDB?
Trac:
Status: new to needs_review
Keywords: N/A deleted, TorBrowserTeam201408 added
Replying to dcf:
What I'm worried about is a user looking at this list of weird names and not knowing which to pick. Adding more meeks isn't going to help things.
Yes, this is the problem...
However, I wonder if the two extra meeks make it that worse. I mean, as long as there is a recommended PT (in this case obfs3), I think that's what most users will try, and only if that fails they will try the other "weird" options.
Maybe changing it to
meek over Amazonandmeek over Googlewill make it more obvious? I think we can use whitespace as normal.Also, instead of ordering the elements alphabetically, maybe it would be better to put obfs3 on top (since it's recommended). Then put fte, and then meek and finally flashproxy? I'm suggesting this because putting obfs3 on top might be more intuitive to users, and also because that's the order I would probably want to try my transports if I was censored.
Maybe we ship one default and return other backends through BridgeDB?
Yes, that could also be an option. But which one? We only have 50GB for free in cloudfront, and google is blocked in China.
What I'm worried about is a user looking at this list of weird names and not knowing which to pick. Adding more meeks isn't going to help things.
One might wonder what the difference between meek-abc, meek-aaa and meek-any would be.
I don't know how to educate people properly or in this case make it obvious what they should select. I like structured things. Once Alice selected meek as her transport she could be presented with a new drop-down menu to choose the backend. Maybe with the description "Please choose the backend you are most likely to connect to."
This makes it more complex, but for me more structured. (I have to pick the transport, whatever this is. And when selecting meek I have to choose a backend, whatever this is.
Possibly there should be a default backend, one that does work for most people.
My geo-location biases me towards knowing Google and Amazon. I feel most people know Google. I'm sure the more meek backends exist the more difficult it will be to guess whenever they will work for me or not. Assuming users are able to check if they can reach Google, I assume it is more difficult to check the other options.
Maybe we ship one default and return other backends through BridgeDB? and/or support request? I think it would be possible to ask questions like if someone is able to visit Amazon and give out those backends on positive answers.
How does BridgeDB know what works for the requesting user? Having him ask for a specific backend requires additional knowledge.
Trac:
Type: defect to task
Cc: N/A to bastik.public@gmx-topmail.deAlso, instead of ordering the elements alphabetically, maybe it would be better to put obfs3 on top (since it's recommended). Then put fte, and then meek and finally flashproxy? I'm suggesting this because putting obfs3 on top might be more intuitive to users, and also because that's the order I would probably want to try my transports if I was censored.
I think it is reasonable to list the most likely working solution topmost, followed by what's next likely to succeed. I agree that if I don't have a clue about any transport I would pick the one that is recommended first. If that fails or there is no recommendation I would go to that list from top to bottom. Flashproxy requires port-forwarding, still, so it is least likely to work for most people.
Replying to asn:
Replying to dcf:
What I'm worried about is a user looking at this list of weird names and not knowing which to pick. Adding more meeks isn't going to help things.
Yes, this is the problem...
However, I wonder if the two extra meeks make it that worse. I mean, as long as there is a recommended PT (in this case obfs3), I think that's what most users will try, and only if that fails they will try the other "weird" options.
Maybe changing it to
meek over Amazonandmeek over Googlewill make it more obvious? I think we can use whitespace as normal.Also note that there are good operation reasons why we wouldn't want to have a lot of backends. Each one requires becoming a CDN customer, which takes money and attention. E.g. currently I have a couple of prepaid credit cards backing the Google and AWS accounts. It hasn't cost much money yet (a little over $2.00 total when I checked last week), but it will increase as we get more users. So we probably won't end up with a dozen meeks in the list, because there's non-negligible cost to establish each one.
Also, instead of ordering the elements alphabetically, maybe it would be better to put obfs3 on top (since it's recommended). Then put fte, and then meek and finally flashproxy? I'm suggesting this because putting obfs3 on top might be more intuitive to users, and also because that's the order I would probably want to try my transports if I was censored.
That's probably the ordering I would use too.
Maybe we ship one default and return other backends through BridgeDB?
Yes, that could also be an option. But which one? We only have 50GB for free in cloudfront, and google is blocked in China.
Eventually we're going to have to find a way to fund the CDN accounts (and a bigger bridge to put behind them) anyway. Google probably works everywhere except China. Amazon probably works everywhere, but I'm a bit less confident in the long-term unblockability of a0.awsstatic.com as a front than I am in www.google.com.
Ok, I merged this without messing with the UI. It will appear in 4.0-alpha-1. Changing the ordering in that dropdown will require a Tor Launcher patch, as well as a mechanism to specify that ordering in the bridge_prefs config file. We need a new ticket for that.
Trac:
Status: needs_review to closed
Resolution: N/A to fixed-
I created #12783 (moved) for the menu ordering suggestion.
mentioned in issue #12783 (moved)
mentioned in issue tpo/applications/tor-launcher#12783 (closed)
