Cloud storage is another type of media with distinct advantages/disadvantages. Yes, that 1TB HDD is about $75, but items stored on a cloud service can be accessed anywhere, and there is less chance of a single drive failure taking your stuff with it. Of course, cloud drives are vulnerable to malware doing a delete (which likely can't be restored), so long term archival media is always needed, preferably offline items, or perhaps something like Amazon Glacier.
Part of this can be attributed to stagnation. So many companies assume they can make money on ad revenue and selling user data that they focus on that exclusively.
The problem is that how long until there is a saturation. Once companies start logging every single click and character typed that a subscriber (i.e. their product) sends their site and selling that info, there is nothing else they can do other than demanding subscribers run adware on their local machines for access. Once this point is reached, there will be a bust for the Web 2.0 (FB, Twitter, services that do not charge their users for revenue.)
What might happen is that governments step in and desire social networks for their citizens, so companies will focus on trying to sell to countries as the main customer instead of advertisers.
I'm hoping the pendulum will swing in the direction back to paid services so the subscriber is the customer and not the product. However, it is harder to get a ton of people to pay a subscription a month than it is to just hand their data over to various third parties for a guaranteed purchase order every financial period.
I've wondered about having part of a cryptocurrency be a way to have a mechanism for insurance. That way, if/when coins are stolen, there is a way to obtain new ones. Of course, this would have to be carefully made/watched due to fraud ("gee, I had those coins all along in a backup wallet...")
The biggest issue with cryptocurrencies is the fact that they cannot rely on a single trusted third party or parties. This is the new ground. Conventional systems like PayPal, Amazon Wallet, etc. have a "trusted" party, either the core company doing the exchanges, a bank, the bank's insurance underwriter, or a government. With cryptocurrencies, being forced to trust a third party cannot be used as an easy way out.
Take a fifth of that and put it into battery research to create a storage cell that is within 1/10 of the energy density by volume of gasoline, and that would completely change the transportation industry. Electric motors don't have a good chunk of their energy get blown out the tailpipe.
On a large scale, this would make solar better able to handle not just peak load, but core electrical power generation.
Even with bandwidth, there are caps and fees here in the US. Try moving 1TB of data via LTE, and the telco will likely hand the person a five digit bill next month. Do it on some cable company plans, and you will be greeted by a $300 bill. So, large data via the Internet isn't going to happen.
There are a number of solutions for this problem:
1: One of the better ones is a server with decent backup software and a LTO tape drive. Then eight tapes will save the 20 TB. Expensive, but the job is done right.
2: One can always have a 20TB RAID, then plug in removable HDDs and use them with WinRAR or another utility as volumes. I'd buy 5-6 4TB removable drives, use WinRAR to make segments, and have at least one recovery volume so that data can be recovered if a HDD fails.
3: One can always buy a an external RAID enclosure, add drives, and use that as a large volume. Then use multiple enclosures that were swapped around as volumes (with an offsite rotation), so a failure or loss of everything at the site wouldn't mean everything is gone.
4: Buy a RDX drive and media, and use 2TB disks. The drive costs $600, the 2TB disk cartridges around $360. However, this just needs a USB connection, no fast box, no SAS interface required.
If I wanted to do the job "right", I'd buy a dedicated server with its own RAID array, use a decent backup utility, and dump the data to multiple sets of tapes, one set being stored offsite. If the server and where it sits gets destroyed, it can be re-bought. LTO-4 and newer have built in AES-256 tape encryption so just set a long passphrase that you can remember and call it done.
CS/IT is about an oxymoron:
You need to specialize in something so that you have a skill not the average person coming from the degree mills possesses.
BUT you also have to not specialize so much that if/when that skill becomes not needed, one is hosed, be it COBOL, C++ programming, Java clientside applets, etc.
For example, certifications. It is good to have some in several different items because I've found that in previous jobs I've had, auditors will go through the server room, demand certification IDs from staff, and if they are expired (or don't exist), said worker is fired on the spot for "failing to have the authority to operate the device."
This is a tough balance. Error on the jack of all trades, your resume gets tossed. Too far the other way, you end up too specialized and if your specialty goes out the door, you are hosed until you can retool (on your own dime).
Android uses dm-crypt, which has been in the Linux kernel for a while now. The downside is that newer releases only encrypt
Motorola devices used to have their own mechanism for loopback encryption, and they used a version of CFS/EncFS for SD cards, which means the SD card can be pulled and file sizes looked at, but the contents and the file names hidden.
The downside of the iPhone's encryption is that the chip that guards the key is easily openable by Apple. LUKS/dm-crypt is all software based without any obvious backdoors (there can always be ones that are hidden.)
There is one Blackberry/RIM feature I wish was in Android. If the device doesn't get a "ping" from the master server in a certain amount of time, the device wipes itself.
Yes, this can be dangerous, but if someone yanks the SIM, or even worse, tosses the device into Airplane mode, eventually the phone will erase itself.
Malicious apps that gain root are rare. If an app is trying to get root, it is usually an exploit tool for a user to get a "#" prompt on their device, as opposed to malicious software. It usually takes some work with ADB and some user intervention to get it working for most of those. To boot, in Android 4.4, SELinux is turned on, so an app that does manage to carve itself a process at UID 0 will not be able to do much. Of course, the main door to root, the su app is well guarded. Modern su utilities require an app to have a permission on download (ACCESS_SUPERUSER.) (su.chainfire.eu has more details on this.) Even with this, the user is prompted before the app gets access.
I do agree that Blackberry's security model is better with the prompting for permissions. However, Android is a lot more usable for a UNIX platform, even though busybox does not come near a full fledged userland. Android also is decently secure. I trust its disk encryption more than iOS's black box chip that holds keys, with Apple definitely having a master key.
Even better, perhaps a standard of crypto token that works with USB? Right now, there is one for cards, but for USB tokens, I need special drivers for every maker (be it Safenet, Gemalto, or whomever.)
That way, the private ssh key can be used on the device, but never leaves it unless one is doing a backup of it to another device, or to other media where it is stored (encrypted with a passphrase) for safekeeping.
For two factor authentication, things like the Google Authenticator is good enough. The only improvement I can see with that would be going to a public/private key system or having a hardened authentication server that used Kerberos. We really do not need more hardware dongles that are not really a standard. Having standardized hardware key protection for SSH private keys would be nice, but oftentimes, the perfect is the enemy of the good... if we can go with SSH keys/certificates and/or a standardized OTP, that is 95% of the battle right there... an attacker would then have to start attacking individual endpoints.
Here is what I do to secure my Android device:
1: Unlock the bootloader, flash a CM or custom ROM that doesn't sport crapware.
2: Encrypt the device with a screen locker PIN 4+ digits. I personally use six for this, just for ease of typing.
3: Use "su -c vdc cryptfs changepw foobar" to change the passphrase. This separates the passphrase Android asks for at boot versus the screen unlocker PIN. Of course, if you change the screen password, the cryptfs password will change, so you will need to use root and change it again, or use an app for this.
The advantage of this method is that the boot password can be very secure, while the password to get past the screen locker can be easy to type in.
4: Relock the bootloader. This forces someone to have to erase the data partition if they want to reflash.
5: Install a third party security app like Cerberus or Lookout that can locate and remotely erase the device, or just sound a siren until the holder trashes it. Some utilities can go into
6: If the device has a SD card, consider using an EncFS app to mount and store files under. This way, anything written is immediately encrypted.
7: Use Titanium Backup Pro with encryption and saving to a remote cloud provider. TB's encryption is remarkably sane (it uses private/public key, so the passphrase is only needed on a restore), and storing copies of backups remotely means that data is still obtainable even if the phone is lost. It does require root though.
8: Unless directly in use, keep USB and ADB completely off until needed.
9: Use a utility that demands a PIN before various apps can launch, especially preferences and an app that pops up a console/shell window.
10: Use a TRIM utility that runs in the background. This way, if the data isn't encrypted, it is not existing.
These will help protect data on a phone. If stolen, the attacker would have a few guesses on the PIN before the device locks them out. A reboot will force the attacker against the full passphrase. A data wipe will still mean Cerebus or a security program is still in
Of course, there is the physical hardware loss, which insurance might cover (Asurion for example), and stored data can be recovered via Titanium Backup. However, done right, an Android phone can be made decently resistant to theft or physical attacks.
The reason why one should use a utility to PIN protect apps and app groups is that if the phone is swiped before the screen locker comes on (for example, out of the user's hands directly). That way, assuming preferences and other settings are secure, a thief has limited run on what is available on the phone.
SSD has gotten less expensive, but it still is about $75/$1.00 a gig, well more than a comparable spinny platter.
There is also the issue of data retention. This is an unknown with SSD. With a hard disk, the magnetic domains tend to stay magnetized in the patterns they were placed in. SSD, once those electronics are out of the gate, there is no recovery of data, period.
I think eventually something will replace HDDs, such as holographic storage, but for now, HDDs will tend to be a mainstay for tier 2, and the primary media for backups (unfortunately .)
 HDDs are not archival media. Tapes are made for long term storage, and even then, one doesn't assume that data stored will be there forever, so one stored multiple copies. However, a lot of people use external HDDs as archives, which can be risky.
I wouldn't mind seeing 5G add additional security. Since it would likely require a new type of SIM card, now is the time to a couple security features:
1: Ability to store data on a SIM card in a secure manner. For storing Google Authenticator info, PGP/gpg private keys, tetetc... a SIM card would be perfect because it has protection against brute force built in (PIN/PUK). If changing phones, I'd not have to worry about backing up or generating new authenticator codes.
2: Similar to #1, except allow SD-like card storage. Since a lot of devices do not have a MicroSD card, a SIM that also functions as a SDxD card can come in handy as secondary storage.
This might be another reason that one should consider using VPNs, even if on a trusted network. At least an attacker would be able to see traffic go by, but not know where it is going to, especially if there is a program in the background doing random HTTPS queries to various sites for noise.
Of course, the downside of VPNs is that a lot of them have their outgoing IP address flagged, so Google either demands a CAPTCHA before use, or just gives the middle finger and denies access entirely.
Sometimes I wonder about the US building its own refineries for national security's sake. Not contracted out to some offshore firm, but owned by the Federal government. As of now, refineries are a bottleneck. Oil can be a glut, but gas prices remain high because refineries are at capacity, with no new ones (other than the ones mentioned here) being made. Strategic oil reserves are one thing... but having refining capacity to deal with a disaster at another refinery can be just as critical.
Add more refining capacity into the mix, and this will stabilize what can be a very volatile market which affects virtually every other market. For example, one of the biggest causes of price hikes in everything from milk to airline tickets are fuel prices.