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=userstats-bridge-transport&start=2015-02-01&end=2015-04-30&transport=meek Yikes! Are these costs covered by a grant or anything? Should we be running a donations campaign? > If you want to help reduce costs, you can > 1. Use meek-azure; it's still covered through a grant for the next four > months. > 2. 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/README > 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#Howtochangethefrontdomain > 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. 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. Here's a couple options: 1. 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. 2. 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. If we make use of this API in Tor Launcher (and we will, as soon as it exists â I'd even pull a crazy and roll it out in the middle of a stable, given the rapid rate of increase in these costs), users would not need to know the magic incantations to access this front, and new bridges could be obtained behind the scenes for them. All they would have to do is keep solving captchas until something worked (until we also implement some kind of fancy crypto like RBridge). Now that we have a browser updater, I think it is also OK for us to provide autoprobing options for Tor Launcher, so long as the user is informed what this means before they select it, and it only happens once. The autoprobing could then keep asking for non-meek bridges for either a given type of the user's choice, or optionally all non-meek types (with an additional warning that this increases their risk of being discovered as a Tor user). 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? -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev