Lots of people are thinking about the problems we have right now.
I have been thinking of the following and want to get some feedback on the idea:
ComBoxen! Comm box is a VM image that, when run, launches with a set of services that allow fully encrypted communications between other ComBoxes.
Basically a secure linux distro on full lockdown that will register with a central directory only to state it is online. Messages are directly passed between comboxes when both are online. Messages are stored locally on the Combox until a secure direct connection can be made to the recipient.
The whole VM could be a stripped down truecrypted message store that only talks to others on a trust list.
Interesting idea. Instead of a VM though, what about a small, low-power box that you plug into your home network that handles secure communication transparently to the user? I'm thinking something like AdTrap (http://www.kickstarter.com/projects/600284081/adtrap-the-int...) but for email or other sorts of communication.
Why the need to sell hardware? I can accomplish what AdTrap does using a USB stick or SD card and any old i386 hardware I might have lying around. You might call this a "System on a Stick". It boots from the USB/SD media and runs in RAM (no hard disk is needed). You set your other devices (running your favorite graphical OS's) to use it as a gateway/router.
It can block ads. Easily. I do this via DNS and it works like a charm.
But that is only one of many things it can do. Could it establish secure end-to-end connections with other people running the same System? Of course. Could you form your own overlay networks? Yes. Could you run email on top of these overlays? Yes, you could. In fact, you could run almost any program over these networks that you could run on a LAN.
This has all been possible for many years. More than a few people know how to implement it.
Whether there is consumer demand (cf. enterprise demand) for this solution is an open question. At least, so I thought.
There are certain advantages to custom hardware. For example, the OS could be flashed onto a tamper-resistant ROM to prevent it from being surreptitiously altered. The device could include a smart card slot used on boot to decrypt the storage mechanism. And the device itself could be very small, light, low-power, and fanless, perfect for stashing out of the way next to your modem.
There's also advantage in offering up a single appliance for people that don't have the technical expertise to set up the necessary services on their own, who don't have a spare i386 they can use, or even people who just want something to work without spending too much time on it.
Secure communication requires parties on both sides to be capable of it, and it stands to reason that more people would buy into a system that provides the capability if you make it really easy to use. Of course, the communication network itself should be fully interoperable with whatever hardware you want to use to connect to it.
All good points, none with which I would disagree.
The System on a Stick could only be surreptitiously altered by remounting the root device as read-write. This is difficult for any non-technical user to do without instructions.
The System on a Stick is fully preconfigured. Insert Stick, turn on computer and away you go. It is every bit as easy as a new piece of hardware with its OS and configurations flashed on ROM.
I do not see a small, low power, fanless device as being incompatible with a System on a Stick. Plug computers or credit card sized computers should have slots for USB sticks, SD cards or CF cards. And they should be able to boot from them (no on-disk bootloader needed).
Not every consumer may be ready to make a purchase of new hardware. Evidence of this is the fact there are a suprising large number of people still using what we would consider "old" hardware. Desktop PC's in fact. Regardless of a consumer's appetite and budget for new gadgets, certainly they can afford a USB stick, SD card or a CF card. They probably own one already. They might even have a CF card left over from the days when digital cameras used CF cards. The System on a Stick will fit on a 16MB card.
I would imagine most people indeed currently have some i386 hardware, either a PC or a laptop. Thus they have what they need to try out the System _right now_, without making a new hardware purchase. When they eventually make their next hardware purchase (maybe an ARM tablet), they will then have spare i386 hardware.
As the System can run without touching the disk, there is no install anything. It can be used on i386 with OSX or Windows installed without affecting those systems. A user can perform tests of end-to-end connectivity and communications using any smartphone with a web browser.
I like the sound the AdTrap Kickstarter project. An additonal computer ("router") that sits between the user and her modem is I believe the right way forward for solving problems of privacy (e.g. blocking ads) and security (e.g. secure communications), not to mention other increased functionality. I simply wanted to point out that purchasing new hardware is not necessary to get started.
Whatever shape or form that router takes, I think it must be bootable from external media with the bootloader of the user's choosing. Any less means we are purchasing yet another closed system and putting someone else in control. By all means make this router function without any user input (turn it on and you're done). But by no means should the ability of the (more conscious) user to fully control the router be limited. That means open source OS and open source bootloader.
I've had similar ideas for a long while. My flavor is using the router as an encrypted protocol gateway and some other centralized user queues. The centralized queue would hold encrypted messages for first time connections. Subsequent messages could be delivered p2p utilizing the fact that most people's routers are publicly available 90% of the time. A local standard mail client connects to a trusted mail server (router) for short haul com (LAN). For long haul, an app could be developed to decrypt the messages locally.
Yeah, I have been talking about this with people for some time - and while the idea of a box is great - and needed for the long term, a VM is ideal to begin with because it can be widely, swiftly and freely distributed.
Further, I was thinking of the following scenario for message validation - (this is just a thought experiment, so it really needs some critical examination I am not sure this even gains one anything):
You run two instances of your VM. One is run locally to you - another is hosted. When a message is sent to you from another peer - it must reach both the hosted and the local one to be opened. When both instances are online at the same time - a hash is shared of the message between both instances and the local master can trust and open the message.
When you're locally off line and a message is sent - Thus, if your locally offline - your hosted instance receives the message. When you come online - your local instance will receive the message from your hosted instance AND a hash from the senders hosted instance. If the hash from the sender matches the message hash from your hosted instance - the message is trusted and can be opened. Else it is dropped.
The problem is that all these p2p secure connections can still always be slurped.
The addresses are only within the system and one would never know which hosted instance belongs to what actual address.... (This area needs a lot more thought)
And when someone connects to a Commbox, how can they tell (across the network) whether it's operating as described, or an imposter box reporting to the bad guys while pretending to be trustworthy?
This is a problem for a lot of these ideas, not only yours and mine (see my other post where the difficulty comes down to verifying the server).
Logically, the solution would seem to be a tamper-proof (or tamper-evident) hardware subsystem, working much like the evil, so-called "Trusted computing" scheme, except with the owner having full control of all the keys.
See my other post in this thread, where I posted the following. Which, please, tell me if this would work or not:
>You run two instances of your VM. One is run locally to you - another is hosted. When a message is sent to you from another peer - it must reach both the hosted and the local one to be opened. When both instances are online at the same time - a hash is shared of the message between both instances and the local master can trust and open the message.
When you're locally off line and a message is sent - Thus, if your locally offline - your hosted instance receives the message. When you come online - your local instance will receive the message from your hosted instance AND a hash from the senders hosted instance. If the hash from the sender matches the message hash from your hosted instance - the message is trusted and can be opened. Else it is dropped.
The problem is that all these p2p secure connections can still always be slurped.
The addresses are only within the system and one would never know which hosted instance belongs to what actual address.... (This area needs a lot more thought)
Lots of people are thinking about the problems we have right now.
I have been thinking of the following and want to get some feedback on the idea:
ComBoxen! Comm box is a VM image that, when run, launches with a set of services that allow fully encrypted communications between other ComBoxes.
Basically a secure linux distro on full lockdown that will register with a central directory only to state it is online. Messages are directly passed between comboxes when both are online. Messages are stored locally on the Combox until a secure direct connection can be made to the recipient.
The whole VM could be a stripped down truecrypted message store that only talks to others on a trust list.