With SSDs becoming more commonplace coupled with filesystem-level deduplication, I wonder if this might be a good thing. Throw not just applications, but multiple instances (browser tabs, for example) into completely separated VMs.

MS has a ways to go to catch up to VMWare, especially with features like transparent page sharing and other memory management techniques that ESXi uses to handle RAM overcommits. However if they can catch up in those departments, it wouldn't be far-fetched to have every simple application instance to have its own OS and filesystem space, and be well secured.

Add a software firewall as a VM (think something like PFSense), and if one of the VMs gets compromised, the amount of damage it can do would be limited.

Long term, with filesystem level deduplication becoming more common, I wonder if the best thing would be to move back to statically linked executables. With the same code deduplicated by the filesystem, there wouldn't be much need for dynamic linked executables, and even though it may take up a bit more space, it would save on aggravation, version conflicts, and other headaches.

Even non-DLLs can be an issue. For example various applications requiring specific JVM versions. It would be nice to have that built into the program itself, as opposed to having to play "guess that smell" and hope the JVM in use isn't too insecure.

The ironic thing is that this can be done under Windows. VMWare's ThinApp, and Evalaze are utilities which can take a Windows package and turn the whole thing into a single file. ThinApp could even find the latest update of a packaged application in a share, so if one ran Word, it would execute the latest one.

It takes up disk space, but it would be nice to have Windows offer a completely virtual machine (with virtual FS and Registry) so one could click on an application, and its data would be stored in a part of the user's home directory, completely isolated from other utilities. Of course, there would have to be something put in so an E-mail program could fetch an attachment from the spreadsheet directory, but that is definitely not an impossible task.

Storage is in tiers, and each tier is different. From the stuff in registers to what is stashed on Amazon Glacier, and everything in between (RAM, SSD, HDD, etc.) A revolution at one strata will have a completely different impact than a revolution at another level.

Take RRAM, MRAM, or some random access memory technology which is up to speed with DRAM, except cheaper and doesn't need refreshed. This would end up not just supplanting RAM, but also making inroads on SSD, depending how inexpensive it is. Will this fundamentally change computing? Somewhat, although I doubt that RRAM would ever drop near the price of HDD or even SSD.

Or, take WAN bandwidth. If the average home had terabytes of bandwidth, a phone had the same, this would change things fundamentally. Cloud storage could go from stashing occasional files to being a tier 2 NAS, especially with proper client security and encryption. However, this is extremely unlikely as well.

Perhaps a tape drive company is able to make reliable media with the bit density of hard disk platters, and is able to fit 100 TB on a cartridge for $10, with drives costing $500. Far-fetched, but if this happens, it would have a different impact to computing than memory costing 1/100 of what it does... but it would be significant.

Improvements in the middle tiers may or may not help things. Bigger hard drives will have to deal with currently small I/O pipes, making array rebuild times longer, and forcing businesses to go past RAID 6 to ensure the drives have protection when things get degraded. Already, some arrays can take 24 hours to rebuild from one lost HDD, and if capacity increases without I/O coming with it, we might have to have RAID levels that factor in not just two levels of parity, but three or four, perhaps with another level just for bit rot checking.

So, when someone says that there are storage breakthroughs... it really depends on the tier that the breakthrough happens at.

I remember mention way back in the Android 2.2 days about having Android be more modular so that even though a phone may be relatively old, it would still be able to run the latest code.

The lesson to this is to get a device with at the minimum, an unlockable bootloader. That way, even if there are no unofficial patches, one can still find a ROM like CyanogenMod or another party which keeps updated.

Of course, something like the Xposed framework is quite useful as well, especially items like XPrivacy which help with on device security extremely.

What I've wondered about is something that was present on Compaqs back in 1993-1994 -- an "enable flash" jumper.

Having this would put a kibosh on flashing option ROMs without the user knowing. Of course, there is always the dancing bunny attack, where a pr0n site asks a user to follow some detailed instructions before downloading a codec, or a dodgy device from China won't work unless the user follows directions (including flipping that jumper and disabling signature enforcement.) However, a master switch would be a significant security boost.

With modern PCs, it wouldn't be a jumper/switch per se, but would be something done from a BIOS level app. This utility would be something a user would almost never use, but would be available just in case someone is doing development work. This way, option ROMs that are signed can be used without issue, but unsigned Trojans would be stopped cold. This mechanism also gives the user the ability to purge all loaded option ROMs and restore back to a default, should their machine get nailed.

I like how UEFI is now on x86 machines. Ships enabled, but easily turned off if you have any technical knowledge. Some BIOS config tools even put up a warning to help ward off "dancing bunny" attacks.

Maybe Apple should see about TPMs. On most machines, they ship disabled, but easily turned on. If FileVault 2 used a TPM, this would not just provide resistance to evil maid attacks, but would stop brute force password guess attacks in their tracks, since the key decoding the VEK would be stashed in the TPM. Of course, if that is lost, there are other mechanisms for recovery (the number string Apple tells you to stash in a secure place.) TPMs would also do a decent job at securing local KeyRing storage, so credentials stored there would be well protected from compromise, even if FileVault isn't used, as the TPM would hold that data, not the OS.

Count me in the same camp. Phones and tablets have reached a saturation point. Watches, it will be Apple's Watch for a bit until Samsung or LG comes out with something really top notch.

Self-driving cars are critical... but they are still far out (as stated above.)

VR tech has been a toy for decades. Nothing at CES is going to change that and turn it into a useful day to day tool for mainstream applications.

IoT stuff scares me, because I am pretty sure that it will be made cheaply, by the lowest bidding Chinese factory, and security will be a faint afterthought. This is addressable quite easily. Have a "LAN of things", and a dedicated, hardened appliance that controls what goes out. Giving every doodad a 3G connection and an external IP is only begging for a massive hack which -will- come.

So, that leaves desktops, laptops, and servers. Yes, boring, but there can be a number of things still done with those to spiff them up:

1: Read-only flash drive with the OS media and hardware drivers coupled with the ability to boot into a PE environment (if Windows) or a live CD environment if UNIX. This would make an "oh shit" scan for rootkits a lot easier, as well as reinstalling from scratch.

2: Almost all desktops have RAID available in the drive controller. Why not add more SAN features, such as snapshots, autotiering, maybe even taking snapshots and copying them to an external HDD? This way, a user can toss in a SSD, and a HDD, and the controller figures out what stuff goes where.

3: The ability to have an ESXi hypervisor built into the BIOS, but with the ability to have one VM that can use the keyboard/mouse directly. Of course, this can be turned off if one wants Xen or Hyper-V, but having the machine boot into a L1 hypervisor and then into a desktop OS would provide a number of useful features, be it allowing a user to create VMs to separate tasks, scan a suspended VM's drive image for malware, or just recover/clone from a clean snapshot if they get their VM infected.

4: A dual or quad port NIC that has a SFP slot, as well as the ability to handle 10gigE, function as a FC HBA, and has CNA offloading hardware. This way, one doesn't have to worry about the HBA or NIC... it is ready to go on the motherboard.

5: Thunderbolt support. This was intended to be a PC standard by Intel, and it should be adopted.

6: Similar to #4, but having NICs have hardware firewalling. Ages ago, I had a machine that had a chipset where the NIC on it actually supported rulesets which were completely independent of the OS. Rules like blocking outgoing 25 or adding blacklists of IPs were easy to add and would remain in place even if the OS was compromised.

7: Actual well made, steel, locking cases. Nothing is 100% secure, but even Kensington lock slots are vanishing. It would be nice to be able to have a high security keylock (like what the PS/2s of yore had) to ensure that a machine wouldn't be opened, and if it was, it would be extremely damaged. I don't understand why companies like Apple assume that there isn't a need for a lock slot.

The days of tapes not being in sync (as in the Travan era) is long since gone. LTO tapes are quite stable, even moreso than DLT, and a lot better than 8mm or 4mm when it comes to hard errors. Tape got a bad name back in the 1990s when 8mm drives were common and had a fairly high failure rate, mainly because it was designed as a video format, not for data.

Both external USB hard drives and tape have advantages and disadvantages. With tape, I can set the cartridge read only, and if there is malware on the machine I'm restoring to, the tape will not be affected. On the other hand, USB drives could get easily nuked, especially if they are encrypted [1].

Tape has its place. If some company could make a decently reliable tape drive for around a grand, they would make a lot of money. The days of the 8mm and 4mm horror stories are over two decades behind us, and as threats like malware grow that are set up to nail backups, having a tape drive that can do WORM in hardware can save a business.

[1]: Encryption goes without saying on removable media. However, with encryption comes easier data loss. A format on BitLocker encrypted media will overwrite the areas on the drive holding the volume keys, pretty much ensuring the data won't be able to be decrypted.

SGID is one way, but there are other ways to separate programs. Docker and containers comes to mind. Of course, there will need to be a mechanism that allows a user to move/copy/link a file between the *Office and MUA containers, but that can be easily dealt with.

Those are OK recommendations... but I'd probably add a few of my own:

1: First and foremost, limit the IP address space of what the SSH daemon can communicate with. If the bad guys can't get to the front door, they can't kick it in.

2: Install SSHGuard, Fail2Ban, or a tarpit program. This won't stop the distributed brute force attacks that do 2-3 guesses per IP block, but it is a line of defense.

3: 2FA. I use the Google Authenticator as backup to RSA keys.

4: If root doesn't need SSH access, don't allow it.

My concern is with the bad guys getting in, although cipher choice is important. However implementing SSH is just as much about access control as it is about encryption.

Right now, Windows... but I wouldn't be surprised to see it on OS X and UNIX operating systems since it would be quite easy to write. It would be simple to write a shell script that fetched a public key from key servers, did a find command, passed the output to PGP or gpg to encrypt files, then wipe the old .doc files.

At least with UNIX, there are programs like amanda and bacula which can be used in client/server mode so that malware on a client can't touch the backup server and its data.

Another lesson is to use virtual machines when possible. An infected VM is a lot less of a hassle to deal with than an infected physical box, especially if snapshots are used [1].

For personal use, I wonder about moving to a NAS and two ESXi nodes. Browsing using RDP is just as fast as a local Web browser, and if configured right, none of the stuff in the VMs would have access to the NAS itself, which helps isolate damage to just that VM itself. As for "real" backups, plugging an external drive to the NAS, copying the VMs after suspending them, and unmounting the external drive should do the trick.

[1]: Snapshots are not backups, but they do have their place.

You would be surprised. There are a lot of places out there that consider an EMC Avamar with replication to a hot site the final answer for backups. For most things, this is good enough.

The problem is that for all but human-caused disasters, RAID and hard drives are seductive, especially tier 2 NAS items like Isilons or NetApps where adding more space is quite easy (as opposed to tier 1 SANs where one has to add new logical drives or expand existing ones). Stash data there, it gets deduped, when it gets near full, add a node, drawer, or more drives.

Of course, as stated above, RAID works well... but it isn't a backup. There are some items which -can- help like the SmartLock functionality on Isilons, which keeps data even if someone logs on as root and does an "rm -rf /ifs/data".

As for tape, a lot of installations have moved to VTLs. Of course, the same issue applies to this. As a bad guy, they can log on as the SAN admin, dump the filesystem that is presented as the libraries and tapes, then call it a day.

It would be nice to see a renaissance in tapes (perhaps a slower LTO-6 spec that can handle USB 3 speeds) just because they are the best way to back up data, even against malicious intervention, bar none. A set of cartridges in a tape safe is as secure as data is going to get from malware, especially if the tapes are set to be read only.

What about a photos directory in the FB app structure? If someone wants to upload a photo of their cat, just dragging and dropping it into that, then firing up FB to upload that isn't that much of a hindrance... and it will boost security by a large amount. Same with dropping a file into a subdirectory of a mail program, so the MUA doesn't have the ability to send attachments of every document present.

Yes, it is one extra step, but it would help a lot with security.