[tor-bugs] #1853 [Tor bundles/installation]: Project: bridge image for cloud

[Tor Bug Tracker & Wiki]

#1853: Project: bridge image for cloud
--------------------------------------+-------------------------------------
 Reporter:  arma                      |       Owner:  ioerror            
     Type:  task                      |      Status:  new                
 Priority:  normal                    |   Milestone:  Deliverable-Mar2011
Component:  Tor bundles/installation  |     Version:                     
 Keywords:                            |      Parent:                     
--------------------------------------+-------------------------------------
Description changed by Sebastian:

Old description:

> When we first started working on the bridge design, we were thinking to
> ourselves "we should get lots of bridges, so China can't block them all."
> That was wrong. Instead we should be thinking "we should make sure the
> rate of getting new bridge addresses exceeds the rate that China can
> block them." The key resource that bridges need is changeable IP
> addresses. So we should experiment with easy-to-set-up images for the
> cloud, so people can pop up a bridge, and then discard it once it gets
> blocked.
>
> Step one is to set up a bridge on the cloud (say, Amazon) and run it for
> a little while, to make sure there aren't any stupid things making this
> harder than it sounds.
>
> Step two is to learn more about the pricing structures: is baseline time
> cheap but bandwidth is expensive? Or CPU? Etc. How much money are we
> talking here, for a variety of bridge scenarios? Evaluate a variety of
> cloud providers.
>
> Step three, investigate programmatic "get new IP address" cloud functions
> we can use. In the future (e.g. #1849 or others), bridges will be able to
> automatically discover that they need a new IP address. The crude
> approach would be to abandon the bridge image and start up another one
> next door. The better approach would be to teach Tor how to press the
> "new IP address please" button on its host.
>
> Step four is to learn more about automation. What are the steps for
> making it so you can tell other people "just launch image Z and you'll be
> running a bridge"? Do these steps and make it so.
>
> Step five is to write the howto for groups like RFA who want to ask
> people to run bridges for them. Make sure to resolve usability pieces
> like "should my bridges publish in bridgedb or not".

New description:

 When we first started working on the bridge design, we were thinking to
 ourselves "we should get lots of bridges, so China can't block them all."
 That was wrong. Instead we should be thinking "we should make sure the
 rate of getting new bridge addresses exceeds the rate that China can block
 them." The key resource that bridges need is changeable IP addresses. So
 we should experiment with easy-to-set-up images for the cloud, so people
 can pop up a bridge, and then discard it once it gets blocked.

 Step one is to set up a bridge on the cloud (say, Amazon) and run it for a
 little while, to make sure there aren't any stupid things making this
 harder than it sounds.

 Step two is to learn more about the pricing structures: is baseline time
 cheap but bandwidth is expensive? Or CPU? Etc. How much money are we
 talking here, for a variety of bridge scenarios? Evaluate a variety of
 cloud providers.

 Step three, investigate programmatic "get new IP address" cloud functions
 we can use. In the future (e.g. #1851 or others), bridges will be able to
 automatically discover that they need a new IP address. The crude approach
 would be to abandon the bridge image and start up another one next door.
 The better approach would be to teach Tor how to press the "new IP address
 please" button on its host.

 Step four is to learn more about automation. What are the steps for making
 it so you can tell other people "just launch image Z and you'll be running
 a bridge"? Do these steps and make it so.

 Step five is to write the howto for groups like RFA who want to ask people
 to run bridges for them. Make sure to resolve usability pieces like
 "should my bridges publish in bridgedb or not".

--

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1853#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online