I assume you mean places with more sensible security polices and practices, and which are out of reach of foreign national intelligence and law enforcement agencies.

Let us know when you find such a place, but don't bother if it's within ICBM range of America or if it requires more than a month of space travel to get there.

BINGO! Only it will be applied to the person encrypting the data, not the data itself.

How many 360KB floppies does it take to hold each movie in your collection?

Also, "per second" may introduce rounding errors. "Per fortnight" is the traditional unit of time for things as large as a feature film (or rather, for truckloads/planeloades of the same).

This. Very much this.

Even so, a 1:10000 ratio of bandwidth to bit-rate is noteworthy.

I don't see this being practical except in either 1-box-to-many-boxes "point-to-points" situations or in situations where reflection and other characteristics are either very predictable or ascertainable in real-time. The former is uncommon and the latter is hard.

A case of 1-to-many might be in a home or office where a single node is connecting to many fixed-point antennas in an "Internet of things" environment or even to fixed location computers (look ma, no more running wires through the ceiling!).

There are some older drives out there that aren't flashable, at least not over the normal computer/drive connection (look for "service" connections on late-1990s/early-2000s drives).

In light of these revelations, expect vendors to sell (at a premium of course) drives which can't be "flashed" without setting a physical switch/jumper.

Why aren't they all categorized as malicious trojans by all major antivirus providers?

When Nighthawk214 wrote that security wasn't hard, he wasn't wrong, but he was incomplete.

Security by itself isn't necessarily hard. If I want to secure data that I won't need to use without 1 business day's notice, I can just take two disks, each with a copy of the data, to my bank and put it in the safe-deposit box. Not hard at all. With a little extra effort I can encrypt each with a one-time pad and put the 4 disks in different banks.

Security with online or near-online usability requirements by a large number of people is harder/more expensive, and the more usability you want (just a few key employees at one physical location? all employees worldwide? customers too?), the harder/more expensive it can get for a given amount of security.

Yes, for some applications the level of security you need and the level of usability you need do make it a hard/expensive problem for that use case. But if you are at that point, you've probably determined that lack of security and/or lack of usability is more expensive or you wouldn't be going down this path.

The big problem I see in industry is people incorrectly assuming that it's cheaper to skimp on security than to pay for it up-front. A smaller problem is people over-doing it on security, spending $BIGBUCKS to prevent and mitigate a disaster when the actual cost of a compromise multiplied by the risk of that compromise is known to be well below $BIGBUCKS - or it would be well known if they bothered to spend a little time analyzing their particular risk environment.

Connectivity != Internet.

Take traffic lights for example:

Long before the Internet was more than just a government/university/defense-contractor environment, traffic lights had 2-way communication.

Were they hackable? Yes, to someone with physical access to the communications wires and by the 70s or 80s, maybe to someone who had access to the telephone-company infrastructure. That meant someone in the same metro area as the traffic lights themselves. But they probably were not hackable by someone sitting in his mother's basement or in a terrorist's cave in East Elbonistan.

That's just one example.

My personal pet peeve is companies that allow more than "harmless" remote control of their HVAC over either the Internet or telephone without routing all remote access through a very secure gateway/vpn/whatever. It's not so bad if they allow people to remotely turn on the lights or change the HVAC from "night/energy-saving" mode to "day/occupied" mode, as that just wastes money. But if I can remotely change the temperature to 40F or 100F or remotely shut down the HVAC completely, or remotely turn OFF the lights, that's a bad idea unless strong security is in place. Over the Internet, strong security typically means a VPN or other extremely-hard-to-hack pathway in.

Some things just should never be put "on the Internet."

If you must have remote access, either use a dedicated physical connection (with appropriate anti-tampering/tamper-mitigation measures of course) or tunnel them through a rock-solid VPN, but for goodness sake don't put them "on the Internet."

Yes, companies that run industrial equipment, traffic lights, etc., I'm looking at you too.

If by "OS" you mean the factory-installed crypto-signed firmware/bootloader/OS stack which can't be changed without keys the end-user doesn't have, then the answer is "probably more than we would like to think."

Now that the vendor knows this, they may be legally obligated to do a "voluntary" factory recall or face a government-mandated involuntary recall.

We can and do use the insecure internet to securely transmit information.

All to often we do it wrong though. Doing it wrong means we can be fooled.

Sometimes we do it wrong on a technical level, such as using out of date encryption, fundamentally broken encryption, or worse.

Sometimes we do it on a human level, such as not occasionally verifying that the account-holder or bank employee is the one and only person who has used his credendials recently using a non-technical means.

Sometimes we do it wrong in our business practices, such as by not doing frequent-enough random audits and not forseeing that a particular type of attack is worth monitoring for. I will grant some leeway here in that "ridk management" != "risk elimination."

Give me a light bulb with the luminosity and color spectrum of a traditional "soft white" light bulb, the power consumption of a "100W incandescent-bulb-equivalent" LED, and an acceptably-low cost and I'll start replacing all the bulbs in my abode tomorrow.

Bonus points if the bulbs do NOT offer any communications ability or any other I/O other than the electrical on/off switch - that way I know they aren't going to be hacked or used against me.

The OSes that ran on 8086-era computers and on very early Macs, as well as most consumer 8-bit OSes could in principle be patched or even completely overwritten without a reboot.

I vaguely remember an early Mac implementation of Lisp which basically "took over" the machine and gave you a command-line environment (look Ma! No menus!). You "ran" it by running a standard Mac application which basically took over the machine.

I seem to remember some DOS (if you can call that an OS) programs that worked basically the same way: They loaded themselves into memory, kicked the OS out, then when they quit, they asked you to insert a DOS disk and re-loaded DOS from disk without doing a hardware/BIOS-level reboot (or they knew how to read the hard disk boot tracks and loaded it from there).

With the advent of chips that provided real privilege levels and OSes that actually took advantage of them, such "takeovers" without the cooperation of the already-loaded OS became impossible by design (but still possible using exploits of course).

I think mainframes had this long before the '90s.

From the 1970s, Tandem Computers (now part of HP) specialized in high-availability computing. I'm pretty sure they've had the ability to patch their equivalent of a kernel for ages.

1980s-era electronic/digital telephone switches (the kind at telco switching offices, NOT your run-of-the-mill PBX) had uptimes measured in DECADES. I don't know if these switches had "live 'kernel' update" capability or not but they did have an "half and half" mode with "live fail-over" capability. One way of doing updates was to shut down one "half" gracefully, update it, bring it back up, leave it running for awhile, then repeat with the other "half". From a customer perspective, the switch was never "down".