On Tue, May 05, 2015 at 06:22:47PM -0700, Mike Perry wrote:
David Fifield:
Here's the summary of meek's CDN fees for April 2015.
total by CDN $3292.25 + $3792.79 + $0.00 = $7085.04 grand total https://metrics.torproject.org/userstats-bridge-transport.html?graph=usersta...
Yikes! Are these costs covered by a grant or anything? Should we be running a donations campaign?
It's partly covered by grants but not fully.
I'd be happy with donations but I don't want to handle any money. We also need to think about long-term sustainability: usage and costs will continue to increase(at least until the world changes), and donations will need to increase too.
Look at the "1 year" bandwidth graph for meek-google. It's pretty close to linear since October 2014, increasing 400 KB/s/month. https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E45...
If you want to help reduce costs, you can
- Use meek-azure; it's still covered through a grant for the next four months.
- Set up your own App Engine or CDN account. Then you can pay for your own usage (it might even be free depending on how much you use). Here are instructions on how to set up your own: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/appengine/R... https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure Then you will have to enter a bridge line manually. Follow the instructions at https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtochangethefrontdo... but instead of changing the "front=" part, change the "url=" part. For example, bridge meek 0.0.2.0:1 url=https://<myappname>.appspot.com/ front=www.google.com
Please let me know if anyone takes you up on this!
I am happy to add the meek bridges of anyone who does this as an option in Tor Browser. We can add logic to round robin or randomly select between the set of meek providers for a given meek type upon first install, or even for every browser startup.
Thanks.
In recommending that people run their own reflectors, I actually had a different use case in mind: that they would run one for themself or for their friends, and not announce it publicly. So basically like setting up any other private proxy, except it works in more places.
Given your costs, it also seems worthwhile for us to fund development to improve this situation, so that meek remains a transport of last resort rather than people's first choice.
I don't have the feeling that it's people's first choice. Rather I think we're seeing new users who were not being served by any of the other transports. It's going to be slower than other transports. On the other hand, not needing to find bridges is a big distinction, and once you have something that works there's little incentive to change it.
Here's a couple options:
- We can add a browser notification box for meek users that either
tells them about meek-azure, or tells them that now that Tor Browser works, they can use it to visit https://bridges.torproject.org to get a bridge type that doesn't cost so much money.
I don't want to lean too hard on meek-azure, because its grant runs out in four months and I don't have a plan to keep it going.
I wouldn't want people to feel guilty when they manage to circumvent censorship, especially if nothing else works for them. But yes, we can probably make some UI and backend changes that make the default options less costly.
- Perhaps cleaner: if BridgeDB itself were accessible through a domain
front, we could export its captcha and bridge distribution through an API on this domain front. Once your IP forwarding in https://trac.torproject.org/projects/tor/ticket/13171 is solved, BridgeDB even could still make use of its IP-based hashring logic.
For this purpose you wouldn't even need the full power of BridgeDB. The list of bridges doesn't need to be kept secret for blocking resistance, so you could even just put the list on a web page and domain-front to download it. (It still might make sense to keep the list secret to hinder financial DoS on the operators, but unless there are a ton of operators, they'll still be enumerable and vulnerable.)
I gave a talk about domin fronting at Stanford and that's what the audience suggested: use a centrally paid-for account only to get a bridge on someone else's account, and then use that bridge for all your data transfer. Then the central costs are limited to bootstrapping.
We'll need some added code for robustness, as we can't expect a large number of bridges to individually be as reliable as the handful of curated ones we have now. Like, if someone turned off their account or they reached their daily cost quota.
Would you and/or Isis be able to work on this on the backend? If not, can either of you recommend someone that might be able to help with the domain fronting bits and other bits involved?
Yeah--I don't want to become a bottleneck in terms of people needing to send email to get added to the list, or anything like that though.