nbraud
One thing which has been rather fun and successful, is speeding up uutils' implementation of integer factorisation: https://github.com/uutils/coreutils/pulls?q=is%3Apr+author%3... (uutils is a Rust reimplementation of the GNU coreutils and findutils)
I'm not yet satisfied with the performance, and I still have quite a few ideas how to improve it, but it's still more than 44 times faster than it was when I started (measured on factoring everything between 2 and 10⁷; it's a lot more on larger / more-interesting sizes)
The main benefit of setting up a non-profit is not shifting the risk to “the poor saps in the data center”: the police isn't going to kick down the door of the datacenter any more than they would raid your ISP.
The main benefit is that you get listed as abuse contact, and you get contacted the same way an ISP gets contacted: you get a somewhat-polite email (or a fax <3) asking who that IP address belongs to. At that point, you can explain what Tor is and that you do not know the origin of the connection; somehow, it's more difficult to have that conversation when you are in an interrogation room, talking to someone likely believes you are guilty.
Postfix, for instance, has [transport maps](http://www.postfix.org/transport.5.html), but those let you pick a transport based on the email domain, not the MX host.
Right now, some people use [onionmx](https://github.com/ehloonion/onionmx), which maintains both a [static mapping](https://github.com/ehloonion/onionmx/blob/master/sources/map...) from domains to onion services, and a dynamic one using [SRV records](https://github.com/ehloonion/onionmx/blob/master/SRV.md).
More to the point: Google is a more central actor, who gets to see the data of far more users, than your ISP ever will.
Moreover, this moves from giving a third party your data, to giving them your metadata, and while people consistently underestimate the value of metadata, there is still an incremental improvement there.
You seem to misunderstand how Tor works. It doesn't require you to become a relay (i.e. carry other people's traffic) to use, and never has.
Furthermore, my experience with Tor on bad connections is that, once the connection to your entry guard is established (once per reboot, takes 30s to 1 minute on terrible connections with packet loss), Tor was just as slow as the original connection.
For those who have decent Internet access, it just works to watch Youtube videos, for instance, over Tor.
Yes, a simultaneous seizure of the DirAuth would do that, breaking Tor relays and clients until the software is updated (the list is in src/or/config.c if you are curious).
On the other hand, it's a move that would require international cooperation <i>and</i> cost lots of political capital, whose only result would be a temporary (but global) DoS.
AFAIK, Tor developers are willing to implement cover traffic; the main reason it hasn't happened so far is that there is no known way to do this that clearly helps against that kind of threat. Until we have this (either from academic research, the Tor Project's own efforts or something else), it would be at best a placebo.
Yes, but how does your collecting logs impact overall awareness?
Even if it did (say, you make the logs available through some snazzy web interface, it gets mass media attention), how does that balance out with the users who traffic you exposed?
It's basically a documented exit policy (i.e. the configuration stating which outbound traffic you accept to carry) that aims to minimize the potential for abuse while still allowing useful things.
That's very much not them getting convicted for running a Tor exit node.
Seizing the DirAuth wouldn't achieve anything useful: all the data that the DirAuth has access to is a matter of public record (literally, the role of the DirAuth is to collect that data, sign it cryptographically and vote on it).
A group of nation-states looking to attack Tor this way would need to stealthily subvert a majority of the DirAuth, and manipulate the network consensus in a way that is both hard to detect and allows them to deanonymise users; that's very far from trivial.
Misinformed at best: you wouldn't want to DDoS anything over Tor, because 1) the nature of the protocol means that the target receives less data than you are sending; 2) any botnet worth worrying over has much more bandwidth available than Tor's exit bandwidth.
Regarding botnet C&C, the picture is more complicated but 1) there has been a very high-profile case of a botnet using Tor to hide it's C&C activities; “surprisingly”, it's very easy to spot when a significant amount of all Tor clients are bots (i.e. the anonymity set is much too small to hide the botnet); 2) those do not tend to be hosted on behind CDNs.
> But it didn't hurt we did have a law school to call on if anything went south (which it didn't).
That's /very/ true: I would strongly urge anybody who considers running exit nodes to do this within a framework/organization where they can get legal assistance if it is ever needed.
That's why it's not very practical to simply write a deployment script for some major cloud provider and let people run with it. (Also, bandwidth tends to be expensive there)
However, if you mean for 1000 HN denizens to start operating their own exit nodes, then by all means go for it :) (Be aware, though, that some people can get quite obnoxious, regardless of the actual legality of running an exit node.)
PS: As already mentioned in this thread, for the sake of full disclosure, I run a non-profit that runs exit nodes.
There are several reasons one might want to setup a non-profit for this: - we can pool resources (money, but also technical expertise, availability to reply to abuse mails, access to legal expertise ...); - it gives you greater (but still not great) media visibility for advocacy/outreach and running donation campaigns; - it puts you on better footing if/when contacted by law enforcement agencies; - it makes it easier to find networks that aren't heavily represented in the Tor network yet, and are willing to host exit nodes.
Full disclaimer: I am on the board of directors and sysadmin team of Nos oignons [NO], a French non-profit that operates Tor exit nodes.
[NO]: https://nos-oignons.net
The point is that the schema is explicit: worst case, I can go look it up, and I /know/ that the data conforms to it.
The first thing you see in Tor Browser is a tab explaining that you got properly connected to Tor, but that Tor in itself is not a complete solution to online privacy and suggests you follow a link to an informative document written by the Tor Project.
Regarding security, using HTTPS (along with the right measures on externally-hosted content) guarantees (to some extend) that what the users gets is what you meant to publish: an hostile network cannot replace the content with misinformation and cannot inject JS -- to exploit the client or not (as was done with the “Great Cannon” [0] which took down Github).
Privacy-wise, a number of countries routinely spy on their communication infrastructure, and revealing “I visited this website” is far more problematic than “I visited this Tor-related post on this website, and left this comment”.
The last reason for systematic HTTPS is “political”: if we go towards a situation where HTTPS is systematically employed, HTTP-only website will be subjected to increasing amounts of social pressure as adoption rates grow: deploying HTTPS (and preferably best-practices) on your “text-only” website pushes other websites (that might “need” it more) to deploy it too.