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

[David Fifield]

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=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?

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/88F745840F47CE0C6A4FE61D827950B06F9E4534

> > 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. 

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:
> 
> 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.

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.

> 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.

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.