[tor-dev] Summary of meek's costs, April 2015

[Mike Perry]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150505/0eec03e2/attachment.sig>