On Mon, Oct 13, 2014 at 2:07 PM, Griffin Boyce <grif...@cryptolab.net> wrote:
> Casey Rodarmor wrote: > >> I just thought of an additional perk: The custom distro could >> blacklist known-bad hardware. >> > > I think this is a really bad idea overall, but I'd be curious to see > what this would look like in practice. I guess that's what public mailing lists are good for, hearing about random bad-but-interesting ideas from the public internet ;–) > Do you detect the (unpatched for past five years) Cisco routers on the > network? Do you flag the Intel processor? Is the closed-source NVIDIA > driver a dealbreaker? I think that everything around hardware has > tradeoffs. Yeah, definitely. I think that it would probably be best to start with really concrete stuff that was definitely known by general consensus to be problematic. For example, network adapters with mac addresses within a certain range are banned. I'm not sure if there is hardware out there that can be identified concretely, but I would assume that if a piece of hardware can be identified as causing a particular node to do more harm than good, for example by phoning home and linking outgoing/incoming traffic streams as being related, then it could refuse to run. I have no idea if there is any hardware which is known to do, but I would imaging that some fingerprinting might be possible. For example, a piece of hardware has to identify itself with some degree of specificity to the kernel to cause the right driver to be loaded to run it. Unless it has the ability to modify that signature, then you might be able to stop it from even being activated. The only way to modify that signature might also cause it from not even working at all. Non-concrete threats can be identified and advised, if the distro judges that they don't destroy the utility of the node to the network. Non-critical components can be avoided, for example by not even starting the graphics card if it has an iffy driver, or operating it in degraded non-accelerated VGA mode only, or even operating without any graphics at all. Also, any non-critical hardware component doesn't even need to load its driver. A normal distro has to try to get every random piece of crap connected to the box working with no user intervention, because who knows, maybe someone will want to use a floppy disk some day. This distro can selectively identify just the hardware that will get it online and only load that. It may also be able to avoid anything that has volatile storage and be completely memory resident, or do things that would be crazy for another distro, like refuse to run if it sees that you've got what looks like a working CD drive that it isn't be run from. In extra crazy mode it could even burn itself to a CDR if there is blank one in the tray, reboot and run from that to avoid USB keys and hard drives. Maybe it doesn't even need to load the driver for the USB bus. Even if something like this existed and worked well, there'd be a push to > then just not use whatever software had this bundled with it. > I think that's why a distro would be a good idea, since it isn't there to accomplish something other than run a relay. A user would probably rather not run a relay at all if it isn't even working. > Lots of people use Tor on not-great hardware because that's all they > have access to. They can use the browser bundle, or their own software, or Tails for interactive use. This would allow users that only care about running a good relay to self-select. > I say that interested people should come up with ideas for how to pull it off, code it up, put it on github with a large "Danger! High Voltage!" warning, and get feedback from the rest of the community. =) That's how people get started and learn. Again, super hypothetically, what's the best way to get feedback on this idea before I write a bunch of code and create yet another distro that might be totally useless? Ideally I would write a sort of proposal spec, concretely outlining what the distro would do and how it would achieve those goals technically. I would include specific features like, "Use public speed test services on the greater internet to determine connection speed, and then configure tor to use 10% of that bandwidth". I would not be looking for any kind of official approval from the Tor project of any kind, just "This could work in the way that you are describe it working." and "If this did work and users decided to use it, it would advance the general goals of internet freedom and privacy." I could create a spec on github and invite pull requests for corrections and issues for unfixable problems with the idea. What mailing lists should I send it to once I have a first draft? -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
