[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Tor Relay Smartphone App

On Mon, Oct 13, 2014 at 12:31 AM, Casey Rodarmor <casey@xxxxxxxxxxxx> wrote:
> 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?

(picking random post to reply to)

You are abit late on the project idea :)

tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to