In the USA you can get a low-end tablet for under $60 easy. In many urban areas you can get 768Kbps internet for under $20/month. If your carrier allows previous-generation modems (some don't) you can get a used modem dirt cheap.

If Mom or Dad has a smart phone that acts like a hotspot you don't even need a separate internet - just make sure the kids don't use up all of your gigabytes (most low-end cell data plans in America are metered or they throttle to "2G" speed after a certan amount of usage each month).

If you have a project that's too big to fit into 1 person's head and you want it to work right and be maintainable, you either have to have a team of people who practically read each other's minds or you have to have a solid design and maintenance process.

Either that, or you have to accept that unless you get lucky or your code is hardly ever used, you will have problems down the line.

Having a lightweight or non-existent process is fine for projects that can stay in one person's head and which won't need to be maintained by anyone other than the original author.

I can see the advantages of cheap, relatively-high-speed paper RAM but remember, we've had high-density paper ROM since the age of micro-fine printing, and low-density paper ROM since the invention of, well, paper.

We've also had very-slow-to-erase "eraseable ROM" on paper since the invention of the eraser.

In prehistoric times, we had it was low-density ROM on cave walls.

From TFS:

For short-range communications between devices operated by human beings, this isn't as hard as one might think.

Let's say I want my cell phone to communicate with a kiosk at McDonald's, without having to rely on the phone network to do the authentication.

Behind the counter, McDonalds has a poster-sized, easy-to-photograph representation of the kiosk's public key.

Now to exchange keys, I walk up to the kiosk and press a button. It puts a random picture on the screen. My phone takes a picture of it, combines it with a random picture I create, my public key, and a suggested random private key, then it encrypts it with the kiosk's public key. My phone tells me to turn it towards the kiosks's camera. It displays the random picture the kiosk created for a few seconds, then the random picture I created for a few seconds, then a pictorial representation of my public key for a few seconds, then a pictorial representation of the entire encrypted message for a few seconds. After all of this is done my phone tells me to flip it around again. The kiosk sends me new shared key that is based on the suggested shared key that I sent to it, but this time it is encrypted with my public key.

Now we can talk and I can place my order and provide my credit card information securely.

This all works because I got the Kiosk's public key from a trusted, independent source - the sign behind the counter that some human being put up and which the McDonald's employees would've noticed if it had changed recently (e.g. if a hacker had replaced the real sign with his own fake one and concurrently replaced the kiosk's public key with one he controlled).

By the way, this is a hypothetical example - there are easier ways to buy burgers than to spend half a minute or more playing "can we trust each other" with a kiosk.

Can this method be defeated? Yes - but you defeat it by removing the assumption that the McDonald's employees are paying attention to their surroundings for any suspicious changes and the assumption that the McDonald's employees are loyal enough to their employer to not "look the other way" if they notice a change or worse, collude with each other to BE the "man in the middle." But at this point, it's no different than walking into a bank and dealing with a crooked bank teller.

It's his deity. He's dyslexic.

As to whether his deity can copulate or not... well, what happens on Mount Olympus stays on Mount Olympus... except in the case of pregnancies - those are the things of which legends are born.

Please forgive me for taking the article summary at face value when it said

The only way that could be true is if there was no properly functioning hardware reset button.

I've been around /. awhile, I really should know better than to assume article summaries are accurate.

Where's the factory-reset button when you need it?

Consumer-electronics that aren't so cheap they are "disposable" should have a "reset to last known good state" hardware button and for some types of devices, a "save current state as known good state" hardware button. If the second button is missing, the "factory fresh state" will forever be the only "last known good state."

The second button is needed for installing "bios-level" anti-theft software and the like that can't be undone by the first button, if the customer wants to make that software non-uninstallable by a security-savvy thief should it be stolen.

For some products, one or both of these buttons may require opening the case and breaking tamper-evident seals, but they should exist, and they should be true hardware buttons, not defeat-able by software.

They need to be hardware buttons so a virus or malware doesn't "press" them, defeating the purpose of being able to "roll back" the machine to a previous state.

Please do.

The only one of the examples I listed in the grandparent post that I plan on implementing are those in a role of a parent.

When I have a 6 year old kid who is using the Internet, no amount of "client-side resistance" that you add is going to stop me from seeing what's on the screen as I watch my kid use the computer.

Question: What's more common and arguably more dangerous than a Windows XP computer that hasn't received any OS updates in the last 2 months?

Answer: An "unpatched" (naive/uninformed) human operating the keyboard.

If counteracting the detecting and blocking bridge notes becomes a problem - and it probably will as soon the the Chinese get good at it - someone will find a solution.

A resource-intensive solution would be to layer the TOR/bridge traffic on top of and steganographically embedded into some seemingly-normal traffic, such as an encrypted streaming video, so that a traffic analysis would say "it's probably just someone watching online TV."

Which is more evil:
Telling employees "we block all encrypted traffic and snoop on everything else"

or telling them

"We MITM all encrypted traffic we can so we can snoop on it, we snoop on everything we can and block the rest"

or telling them

"we block all traffic except traffic to the few Internet resources we know you need, and oh by the way we snoop on that"

or telling the

"we don't think you need a computer to do your job, if you do need a computer to do your job then talk to your boss and he MAY give you the keys to the one room where there is a computer. Oh, by the way, there are TV cameras all over that room so don't even think about using it for non-business purposes."

Substitute "school," "institution," or "parent" for "employer" and substitute "student," "client/end-user," or "minor child who the parents deem too young/immature to use the Internet unsupervised" for "employee."

Speaking of parents, many parenting experts highly recommend that if a kid under a certain age/maturity level wants to use the Internet, he only be allowed to do so under close supervision, as in mom or dad in the room within eyesight of the screen. What age? Experts disagree, but almost all would put the cutoff age where mom can leave the room for a few minutes at somewhere in the elementary school (age 5-12) age range.

Time will come when firewalls inspect all outgoing packets and use heuristics to guess how dangerous encrypted traffic might be.

For example:

• Whitelisted sites Encrypted traffic to an IP address previously whitelisted by the firewall vendor or end user? It's whitelisted, let it pass.
• Heuristically safe sites Encrypted traffic to an IP address known to be associated with a well-known domain whose DNS is known to be valid and who is known to typically use encryption over this port and whose recent activity hasn't been suspicious? Probably safe.
• Suspicious traffic to an okay site Encrypted traffic to whitelisted or probably-safe web sites that is uncharacteristic in size or other known details? Possibly not safe.
• Unknown site Encrypted traffic to anyone else who isn't blacklisted? Possibly not safe.
• Blacklisted site Encrypted traffic to a blacklisted site? Block it.

In the middle three groups, give the user a chance to approve/block/whitelist the traffic or, if the user just wants such traffic logged or just wants to see an on-screen alert but doesn't want to be bothered with the "should I block it" question, log it and/or put up a visible notification to the end-user.

Decades ago - we are talking the 50s and 60s, possibly up through the '70s and '80s, large companies treated employees as a long-term asset not as a short- or medium-term one.

They wanted to cultivate the reputation of "we take care of our employees" more than "we take care of our stockholders."

Back then, it would take a radically different skill-set between those being laid off and those being hired for you to see simultaneous layoffs and hiring from abroad. As a hypothetical example, if a conglomerate were shutting down its meat-packing division and hiring new researchers as it expands its pharmaceutical research division, the odds are that most of those meat-packers wouldn't have the intellectual capacity to qualify for the Ph.D.- or at least graduated-in-the-top-quarter-of-my-class-from-a-good-school B.S.-in-chemistry-or-a-related-field- degree required for the new jobs even if the company was willing to invest 4-6 years to re-train them.

Today, by contrast, if the employee being laid off can't be quickly retrained, the short-term-economic decision is a no-brainer: lay that person off and hire someone for the newly-created job who can hit the ground running.

But don't tell him that.

*joke*