Once again we have someone who is enthusiatic, but uninformed, asking the wrong question. The original question, as posed, is exactly the sort of question that got us encrypted cable boxes. That turned out well, didn't it. This exact problem was solved decades ago. Look up the Red/Black Concept. BTW, the answer to the question is, as has been answered elsewhere, NO!.

A better question would be: What could we do to improve Internet security for online banking, shopping and improved privacy?

You should ask a real security professional. (Not me, I'm just an amateur. ;)

But I'm glad you asked.

Take out your smartphone and look at it. Had we done it better, you could be holding your "Safernet" terminal. Instead, what you have is a privacy stealing, totalitarian regime supporting, tracking device. One not really owned by you, since you have almost no control over the software it runs, nor the hardware inside, nor any say in the hidden capabilities of either.

We could fix that. But how?

First create a protocol to carry your "Safernet". Call it httpRB maybe.

Next split the phone into two (electrically separated) domains. A RED side, (with its own processor and memory,) and a BLACK side, (with its own processor and memory). The RED side owns all the I/O: screen, ports, radios, buttons, etc); and a BLACK side (with the high powered processor for playing games). Nothing gets in or out of the box without passing through the RED side.

When you want security it is only done on the RED side. Everything else gets done in the BLACK. The RED side doesn't do http, or https, or sound or image decompression or even unicode. RED only does simple text, (with limited unicode for foreign language support,) basic math, and if you want an image it consists of simple RLE image tiles. (No, you don't get secure video telephony.) The RED side ensures, via hardware and audited software that none of this ever reaches the BLACK side. Everything on the RED side is open to audit. Everything!

And no, this isn't two separate phones, you don't need two of everything. But you do need economy of scale and support built into the ICs. You need engineering to prevent sidechannel attacks and yes the phones will be a bit bigger, heavier, slower, harder and more expensive to certify. ... Which is why we don't already have them.

And that's it... problem solved...

But it just ain't gonna happen unless it's mandated.

Many people have a very good reasons for not wanting their email linked to a phone number. In places like Syria you could monitor email connections (even if you can't read the content) then use the phone SMS for localization for real time targeting information. This would be a good way to shut down/kill unauthorized and unaware journalists and careless just-in-country NGO personnel, not to mention rebels. You can use a VPN to hide your email connection but then Google goes and phones you back. Then it's fire mission, fire for effect... Not the way I would want to end my day... Perhaps a little dramatic, but the same thing can easily be done to deanonymize anyone...

After reading your references, yes, actually it does look like no one was injured by radiation. There is mention of a 70% higher risk of developing thyroid cancer and a 7% higher risk of leukemia and lower percentages for other cancers. To this level of risk I have to say "so what?". These increases in risk are far far lower than the increased risk of cancer just from being poor, or living down wind of a coal fired power plant, or being an airline pilot. Those are risks we all accept each day. This level of increased risk is laughable. You could probably more than offset this level of risk of death and injury by taking the bus instead of driving in a car for a month. Yes, the article mentions that there might be a lifetime risk of death of 2 to 12 onsite workers, which is immediately followed by a caution that the methodology used in calculating those numbers as a sum of risks for serial low level exposures is unproven and possibly suspect. It's also important to remember that the astronomical radiation levels reported during the event were from short lived isotopes of oxygen (oxygen-15 has a half-life of 122.24 seconds) and nitrogen (nitrogen-13 has a half-life of 9.965 minutes). Tritium with a half-life of 12.32 years was probably the most problematic, but given that it is hydrogen, it would have almost certainly diffused to negligible levels rapidly. Yes there was a release of some cesium-137 with a half-life of 30.17 years and strontium-90 with a half-life of 28.8 years, but we have a lot of experience with mitigating and dealing with the effect of these, to the point where the added risk is practically negligible compared to the other risks we face daily. I would expect the health effects of the panic, relocation, and losing one's home far outweighed any and all radiation risk. Or perhaps that was your point?

Had to do something similar a long time ago. It was a lot of work to set up, but it did work. It went like this: (1) Set up a server attached to a printer. You probably want to set up a firewall to limit who can connect. (2) Configure the web server to accept an HTTP POST or PUT. (FTP might also be an option.) You might want to create a simple web page to facilitate the upload. (3) When you drop a file into the spool directory, it gets scanned for file type. If it's postscript, it gets printed. If it's PDF it gets converted to postscript. If it's text it gets converted to postscript. If it's HTML it gets converted to postscript. There are utilities to perform the conversions on Linux. You just have to write the scripts to scan the spool directory for new files, detect file type, drive the converters, and of course print. (4) Teach your dad how to perform the PUT or POST to get the document to be printed into the spool directory. It took a bit of effort to get this working, but eventually it did work and it worked well. One gotcha we had to deal with was the short attention span of users. They simply wouldn't wait long enough for the process to run, and would frequently drop multiple copies of the same document into the spool directory. To cope with this we captured checksums of each file, and when it's a copy of the file in progress, we deleted it. If it's a file processed within the last minute, we deleted it. This allowed the user to process the same file more than once, but limited the rate to once per minute.

I'm surprised no-one mentioned Brief . Back in the day we had to churn out assembler which was fit for V&V. We only had beige box PCs and built and tested on a separate dedicated machine. The only thing that made it bearable was the speed and flexibility of Brief. It gave us the ability to easily format source code for the V&V tools (via automation) and served as a primitive source code browser. A couple of the guys used vi clones but I grew rather fond of Brief. It got out of the way, let me work on multiple files at once, and yet no matter how complex the edit job it made it easier. I remember it had a stellar macro facility for the time. When I switched to Sun Workstations I switched from Brief to EMACs because it provided the same programmable functionality. It didn't hurt that Brief had employed the basic EMACs command key setup. So for assembly language, (at least umpteen years ago,) I nominate Brief.

I would use an OpenBSD bridge(4). Get a PC with three network ports. Install OpenBSD. Create a transparent bridge between the two networks and use the third connection for access to local ssh(1). I would then configure the pf(4) firewall to allow limited traffic (such as SSH) to cross the bridge. Since the box is a bridge, it's transparent to network traffic and adds an almost negligible latency. Whenever you want to disconnect traffic, log in using ssh (Putty from a Windows box), and turn off the bridge. With an SSH client on a smart phone, you could turn the network off and on from anywhere in the world within a couple of minutes of receiving a phone call. A timeout is easy. Create scripts to enable/disable the bridge and use cron(8), at(1), or a script to fire off the enable/disable scripts at specific times, dates, or intervals.

I've been through a frontend crash "at speed" complete with airbag deployment. The car was a writeoff afterwards. The impact was right on the nose. I always drive with my seat well back (I have fairly long legs) and a tight seatbelt (if you're going to use it, use it correctly). The little Dodge (and airbag) died saving me from injury. I walked away with a slightly dislocated neck, compressed ribs, and a small burn on the back of one hand from the airbag. Some observations: Holding the wheel at 12 o'clock would have broken my arm. Holding the wheel at 10 and 2 would possibly have broken wrists or arms. Gripping at 9 would probably have damaged my left hand when it hit the door. I *only* hold the wheel at 4-5 and 7-8 (or one hand at 6 on long drives). That still allows me to put more force into the wheel than my wife can in any position. If you need the extra leverage you can apply by holding the wheel at 3 and 9, then you have done something very, very wrong (or worse, stupid). When I drive, I try to avoid doing anything stupid. (And since you have to know, don't ever, ever, assume that a car on the freeway is moving in the direction of traffic.)

My connection is far below 5m and since I don't watch movies, my download speed is usually adequate. However, what I haven't heard mentioned here is *latency*. I do a lot of remote work over the Internet and the latency I get is *abysmal*. It seems that ISPs have been sneaking the latency up (by refusing to tune for latency and using default settings for packet queue management). This results in behavior which, much of the time, makes remote NX/VNC connections almost unusable. You can forget about Video over IP and VoIP. Connections over the Internet pretty much require saying "over" when you stop talking so the remote party knows when they can start speaking. We need to make people aware that there are *two* parameters which define broadband quality. Speed is just one of them.