[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #3453 [Torouter]: Torouter desires and features



#3453: Torouter desires and features
-------------------------------------------------------+--------------------
 Reporter:  ioerror                                    |          Owner:  ioerror         
     Type:  task                                       |         Status:  new             
 Priority:  normal                                     |      Milestone:                  
Component:  Torouter                                   |        Version:  Tor: unspecified
 Keywords:  torouter tor-fw-helper upnp natpmp debian  |         Parent:                  
   Points:                                             |   Actualpoints:                  
-------------------------------------------------------+--------------------

Comment(by phobos):

 I'd like to keep the Dreamplug separate from the B3.  Call them torouter
 dreamplug and torouter b3 for now.

 My goal is to have the B3 be as user friendly as possible.  Mostly because
 the B3 market already expect that, and we've invested some time and effort
 into making Tor integrate with it.  Think of this as the torouter-stable.

 As for the dreamplug, I'm encouraged if we can provide an open dev
 playground for all.  Think of this as the torouter-alpha.  We have 10
 dreamplugs with jtag boards we can ship when we're ready.  I would also
 like it if we could coordinate, but not depend upon the freedombox
 progress.

 The original idea of the torouter is that it's the gateway to the
 internet.  It has a public IP address that is accessible from the world.
 There would be no need for nat/pmp if there is an external interface
 already.

 __Security and Updates__
 For the dreamplug, we seem to be focusing on security at all costs.  We
 should be careful not to develop a device that is too brittle.  We haven't
 focused on updates for the dreamplug, nor figured out a way to integrate
 with the larger Debian repos and community. We haven't thought about
 usability at all. I think we need some more structured thought processes
 around the dreamplug torouter.

 For the B3, we seem to assume we're going to use a bunch of existing repos
 or run our own.  Running our own repos until we can integrate with debian-
 arm upstream seems a smarter plan.

 __Transparent Tor__

 I'm not convinced transparent tor needs to be a key feature of either
 torouter hardware. My concern is that this is going to encourage people
 do to unsafe things over tor. Even if it isn't encouraged, people will
 use technologies that cannot be properly secured and merely push the risks
 from their local network and ISP to exit relays. The costs to the user
 could be high. Perhaps tor could block known plaintext ports by default
 and/or send these through the local IP per iptables rulesets, thereby
 bypassing tor.

 __Bridge or Relay-by-default__

 At a minimum, the torouter should be a relay by default. A setup screen
 could ask the user if they want to help censored users access the Internet
 (bridge config), or either of a non-exit and exit relay configuration.
 This set of options lacks a tor client-only config on purpose.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3453#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs