Re: [tor-talk] Tor Relay Smartphone App

[Casey Rodarmor <casey@xxxxxxxxxxxx>]

On Mon, Oct 13, 2014 at 2:07 PM, Griffin Boyce <griffin@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk