On Thu, 23 Jul 2015 18:26:33 +0000 Jacob Appelbaum jacob@appelbaum.net wrote:
Also - does this mean that after many many years... that this new version of tor-fw-helper be enabled by default at build time? Pretty please? :-)
Unlikely, AFAIK the general plan was to have it as a separate package.
That is really a major bummer if so - we should be shipping this code and enabling it by default. If a user wants to run a relay, they should only have to express that intent with a single button.
The problem with this (and why we're not shipping it in Tor Browser, even if it would make flashproxy actually usable/useful to a large number of users) is because there is no one that is willing/able to deal with every single instance of:
* "My router crashed" * "My router crashed and I had to factory reset it" * "Why do I need to open a UDP port on my computer's firewall for uPnP/NAT-PMP to work, and how do I do that?" * "Random unrelated port mappings got blown away" * "My router's NAT TCP session table filled up" * "My ISP is complaining that I'm on some random asshole's blacklist because they include every single Tor Relay" * "Sites that used to work no longer work because some random asshole's blacklist includes every single Tor Relay" * etc, etc, etc, etc
And I certainly can't deal with "my router has a strange idea of what the uPnP spec actually says, and it fails to port forward" (unless they have/know how to use wireshark).
I'm as unhappy at the general situation surrounding the codebase as anyone else, and if I thought deploying it would be a good idea, I'd be strongly pushing for it, since I think the new code I wrote will work for a lot of people.
But we have a gigantic userbase, and playing "consumer router support technician" for all of the ones that ship with broken uPnP/NAT-PMP implementations does not fill me with warm fuzzy feelings.
Regards,