3 ms·

Don't mix up "better" with "perfect". That's the mistake made by people who post a link to the trusting-trust: Trust isn't binary. "Perfect or give up" is a fal

Don't mix up "better" with "perfect". That's the mistake made by people who post a link to the trusting-trust: Trust isn't binary. "Perfect or give up" is a false dichotomy. I sometimes say "trust no one", which seems to support that false dichotomy, but I mean to say "Reduce and distribute trust". Open source code and hardware doesn't remove trust. It reduces the amount of trust required and distributes it among more parties. It makes betrayal harder, more expensive, more temporary, and less destructive. That's not perfect, but that's much, much better. There's a world of difference between closed source software from MegaCorporatism Inc and open source -- even if an evil genius is still technically capable of sneaking something into a compiler or chip.

jacquesm 13y ago
Well, in this case it is a binary thing. When you talk about this in an applied sense you're right, then it isn't a binary thing but when you talk about feasibility then it is black-or-white. You're either sure or it might as well be compromised.
- Karunamon 13y ago
  Not necessarily. As the author of the article said, it's easier to rely on software bugs than to ship a crocked piece of hardware like this. If you manage to backdoor a mass-production piece of hardware (let's say this is a wifi card or something else similar), you're just one odd error away from someone curious finding out what's happening, raising the alarm, and the whole operation comes crashing down. From a logistics standpoint, it's easier to break software.
superuser2 13y ago
Open hardware might make you feel better, but it wouldn't be substantially harder for the people who control the manufacturing process to backdoor.
- bigiain 13y ago
  I wonder if the trusting trust "two compiler workaround" could work here? Would it be possible to build a duplicated system with two (or more) of every component, then have them compare themselves to each other. Could you build similar-but-not-identical hardware, sourcing components like pci cards and disks from different vendors, to minimise the chance you've got backdoors in all sets of components? (I'm now thinking that space-shuttle-style multiple computer setups might be a starting point worth investigating.)

jacquesm 13y ago

Well, in this case it is a binary thing. When you talk about this in an applied sense you're right, then it isn't a binary thing but when you talk about feasibility then it is black-or-white. You're either sure or it might as well be compromised.

Karunamon 13y ago
Not necessarily. As the author of the article said, it's easier to rely on software bugs than to ship a crocked piece of hardware like this. If you manage to backdoor a mass-production piece of hardware (let's say this is a wifi card or something else similar), you're just one odd error away from someone curious finding out what's happening, raising the alarm, and the whole operation comes crashing down. From a logistics standpoint, it's easier to break software.

superuser2 13y ago

Open hardware might make you feel better, but it wouldn't be substantially harder for the people who control the manufacturing process to backdoor.

bigiain 13y ago
I wonder if the trusting trust "two compiler workaround" could work here? Would it be possible to build a duplicated system with two (or more) of every component, then have them compare themselves to each other. Could you build similar-but-not-identical hardware, sourcing components like pci cards and disks from different vendors, to minimise the chance you've got backdoors in all sets of components? (I'm now thinking that space-shuttle-style multiple computer setups might be a starting point worth investigating.)