[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