On 2/7/16 10:44 AM, nusenu wrote: > > - it is *not* a good idea to run exits from your home (limited exit > policies are no guarantee for no troubles)
It depends only on how finely we can be capable of precisely defining the destinations to which you're sending your Tor exit traffic. If i get all the Google's IP of their 17 Autonomous System and will only enable that configured in an Exit Policy, do you expect to receive abuse requests from Google? I don't think so. Those large organizations, all among the top-30 destinations of the internet let's say, are knowledgeable enough in their SOC (Security Operation Centers) that just don't care to waste their time sending abuse requests to Tor Operator's ISPs. So, if you enable only those "no abuse generating / high traffic" destinations, the end-users should not have at least the problem of abuses, that usually is the bigger. > > - most users will probably have asymmetric bandwidth (slow upload) and > contribute little bw and uptime, while every relay takes a certain > amount of bw to be distributed through the consensus to clients > (where is the break-even point?) Well, regarding the bandwidth it depends on the link but in many countries, residential have very high speed connection lines and just by feeling (not by math) maybe a single average home user maybe able to push 1-3TB of bandwidth a month, like a cheap VPS. In terms of netwok design, we may think that those TorBrowser users contributing to the Tor network to become "helpers" of Tor Exit relays. Those "Tor Exit Helpers" may serve a certain amount of "Tor Exit Relays" to get traffic dispatched. That traffic would go only to the top-30 tor network destinations, with explicit opt-in by the end-user about where to let traffic goes among those list. An end-user may wish to enable traffic to Facebook, Google, Twitter, Wikipedia but not YouPorn (assuming that YouPorn would be among the top-30 destinations). A Tor Exit Relay, handling let's say 30 helpers available (connected to him), may at OR-protocol level handle a sort of "302 Redirect" (to use HTTP dialect), redirecting the users for that specific traffic to the "Tor Exit Helper" that will handle it, changing the circuit path for the last-hop. With an approach like that the TorBrowser Clients would not need to know the list of Tor Helpers, the consensus would remain the same, because the relevant data would get served at OR-protocol-level be provided "on demand" from a Tor Relay. > > - most users are probably not fine with publishing a public record of > when they start and stop their torbrowsers (something that could be > deduced from seeing exits showing up on client IP ranges with certain > patterns) > (Makes certain correlation attacks easier where an observer sees your > exit showing up and correlates that with login times of pseudonym accounts?) That's a matter of providing a simple UX wizard to drive the user with basic education on what he shall understand and how to decide whenever it's appropriate for you to enable Tor traffic to one of those "30 top destinations. > > - only a small amount of users will opt-in to something potentially risky Well, that depends on UX design and end-user communication too, if it's easy and it can be made with very reduced risks!. To test out a crowdsourcing of Tor network contribution, it would be required to run a 1 or 2 years beta program, to make it, test it, refine it, fix it, improve it, refactor it, etc, etc I think it's a quite big amount of work a project like that, requiring tons of changes, research and design choices, etc -naif -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
