The Moment also has one of the fastest CPUs in the business. This is something I wish Sprint advertised. Even with the vendor stuff, it still runs pretty well, and the OLED screen is nice too.
Sprint needs to toot their horn when they get a really cool flagship phone. VZW did this with the Droid.
"4g", which I'm stating in quotes will be coming from some interesting sources:
Sprint's baby, clear.com is getting 4G service out various places. This service not just handles mobile phones, but is touted to replace cable and DSL, with wireless modems that go from WiMax to wi-fi.
T-Mobile is going to be upgrading to their next gen stuff using their existing towers and infrastructure, as well as pairing with Comcast to get things rolling in some areas. It is said that what they will end up with can be used by existing devices, and was stated to be in the 4G speed (10Mbps or so).
The Register has an article posted on 23 December stating that Verizon wants to cover 95% of the US population with 4G service (LTE) by 2013. This seems to be a GSM successor, so phones using this technology will use SIM cards, making it perhaps possible to use VZW with unlocked phones in a few years.
AT&T also plans to go LTE, and a press release says they want to reach 90% of their existing 3G network by 2011.
My take: I REALLY wish the 4G LTE networks use compatible frequencies, so if I buy an unlocked device, I can drop a SIM card and use it on VZW's network, AT&T's, or T-Mobile's.
People are wising up though. The Droid's marketing campaign just hasn't gotten people into VZW's doors, it has spurred interest in Android devices in general. I've talked with people who see the Droid, find it interesting, but prefer T-Mobile, and end up coming out with a Samsung Behold, a Motorola Cliq, or a MyTouch 3G. People on Sprint find that the Samsung Moment offers one of the fastest processors. The only carrier that has no current offering is AT&T, but supposedly they will be offering a Dell Android phone. AT&T also has the iPhone, so just business common sense says that Android devices will be second fiddle to AT&T's mainstay.
I like both designs. The candy bar style phone is great with a touch screen, large display, and many features. It makes a great work phone.
However, I don't like being in "work mode" 24/7 unless I am doing a project or I'm on call. I like a basic featured flip phone because it is small, unobtrusive, and fits nicely in a pocket. If the flip phone gets dropped, splashed in water, accidently microwaved, or otherwise trashed, I'm down $15 to $40, the cost of a bubble pack generic GSM "pay as you go" phone. If I'm really unlucky, I'm out a $20 SIM card. That's far better than the $400 my main phone would cost if that got ruined. Plus, unless I'm on call off hours, having no Exchange support or pushed E-mail is just fine with me. I'm still reachable in a bona fide emergency, it just takes the effort of making a call or a text message.
There is a cost of letting them store data: You lose assurance of physical access. For some things, this is just fine. I highly recommend offsite backup utilities (Mozy or Carbonite) for students and SOHO people because combined with a keyfile stored in another safe place, it offers good security even if someone's office gets destroyed. But this doesn't scale. My Carbonite keyfile that protects the data stored offsite for three machines is not going to be a usable solution for a SMB with an IT department with turnover.
For small businesses with a single point of contact, maybe cloud storage is fine. However, for bigger businesses, it is better off to just go with a d2d2t solution, and offsite backups. This way, data is physically protected from compromise, but is stored redundantly.
On the cheap with the DIY storage, perhaps consider buying multiple terabyte drives, and using a tape rotation system to keep data backed up, with multiple drives brought on and offsite. This will provide decent disaster protection, but you still have physical control of the data.
SSL is different. The encryption key that is used is used just for the communication, then is tossed. In general, one will not have a SSL negotiated key for last week's bank transaction on their computer.
Because the SSL key management is about keys that are tossed, there isn't much of an issue with the nodes in between.
Cloud computing is about long term, persistant storage. The session key that gets chucked in SSL has to be kept permanently somewhere when it comes to storage, and key management is a major headache. Have too little redundancy, you can lose access forever to data. Have too much redundancy, and keys can wind up in the hands of blackhats and people who you really don't want to have access.
Don't forget: The US isn't the only company with a USAPATRIOT-like law.
Store data on an Elbonian server, and the data is available to their intel agencies and law enforcement (who likely will use the data to help their companies compete, or if they don't like the West, direct attackers to soft targets.)
Those archives of tax records stored on a cloud? Better hope your encryption is tight, not just now, but can stand attacks 20 years from now. I'm sure that in 20 years, AES will have cracks starting to show, just like DES had its small keyspace and 64 bit block size make it irrelevant for today's encryption tasks.
Cloud computing violates the first rule of security: Don't let the data be accessible in any shape or form to those not authorized. It goes with one of the fundamental rules of the Internet which is often ignore:, don't put anything on a Net accessible computer that you would be afraid of it ending up linked off of 4chan.
Cloud computing has some seductive properties for PHBs: It is just a network jump away through an API, requires no dedicated equipment on the client site, and the big named company salespeople who play in the same foursome at the golf course sell the stuff.
However, if one drops the smoke and mirrors, there isn't much difference between cloud storage and FTP-ing files onto a remote site.
So, what does one do? Before someone states "encrypt it!" one has to know that there are two parts to encrypting:
First is choosing the algorithms (AES-256, and if worried about an AES crack, chain AES and Serpent or Twofish [1]) and how they are implemented (ECB bad, XTS good). You also add to this how one can tell if the key is valid, and one of the most secure ways is to have the key use a salt, decrypt part of the cyphertext, and check it against a known value. TrueCrypt does this when validating if a filesystem is OK to mount.
The second part is not as obvious, but it means as much to secured data as the cypher: Key management is where you feel the burn. The simplest key management is having some random passphrase the maximum length allowed stored in a file on a USB flash drive and printed out for safekeeping. However, this runs you into the same issues as using WPA2-PSK, if the key is divulged on one area, the whole security of the system is now compromised.
Which means that you have to have a system of subkeys where the keys will decrypt the master key, similar to how PGP stores multiple passphrases and public key information to open a PGPDisk. You can give everyone a different passphrace to remember, or you can give them some type of smart card that unlocks the information. If a passphrase is divulged, it will suck, but given time, it can be removed from the authorized list.
Don't forget not just using one volume key for the data, one needs to use a different one every so often, so a compromised subkey which allows someone to slurp up the main decryption key won't compromise everything.
In reality, after a company goes through their iterations of a key management system, going from passphrases to RSA keys (because passphrases are hard to remember), then going from a list of keys to a full blown PKI with multiple recovery mechanisms, companies usually end up going to a smart card system. Of course, this is expensive and requires an elaborate support structure, but it is the best way of dealing with key management we have. And of course smart cards have driver hell in most cases.
So, with all the complexity that one needs to have in place for an encryption layer before stuff ends up stored offsite, it gets to a point where why should one even bother? Instead, for a number of SMBs with a non trivial amount of employees, they should just buy tape libraries and a backup program that has encryption. Some drives (like some of HP's) have encryption functionality in hardware. Then after the tapes are backed up, they are either stored in the data center (with restricted access), a tape safe, or an Iron Mountain tub.
What is the advantage of going back to tape even though cloud computing is seductive and seems like all problems of storage are just an Internet connection away? You know who has physical possession of the data at all times. It is a lot easier to deny someone access to physical media by rekeying locks, yanking their HID card access, or striking their name from the authorized user rolls at the offsite system than it is to deny access to stuff where you don't know even where it is stored.
With physical media, you have two pieces of security. The physical media itself, and the encryption on it. With cloud storage, ALL your se
As an alternative, one could use a port knocking system in combination with a script that blocks the ssh port from various IP ranges. This way, a spider just sniffing out ports will run a portscan, see no port 22 is open, and go on its merry blackhat way. The only downside of port knocking is that some places (open wireless networks) disallow any outbound ports other than 22, 80, 443, and maybe 1723 out, so one wouldn't be able to tap the ports that would allow ssh in from the IP range you are at.
Even if a robot worked 100%, it doesn't mean all humans are useless. Moving parts wear out, metal expands and contracts out of calibration, heavily loaded parts get fatigued, screws work loose, lubricants degrade. So, no matter how good the robots are, they need to be put offline to be recalibrated, replacement parts installed, bearings repacked and regreased.
Of course, minor adjustments may require major software modifications. I'll use the common tape robot as an example. Say one is made to take AIT cartridges. To make it work with DLT media would take a major recalibration, if it would even be possible.
This isn't to say robots are important, but in no way they can completely replace humans, as someone has to service them when (not if) they fail.
There is one other algorithm that the Courier had that the Sportster lacked: the USR proprietary algorithm, HST. On some nights, you could have a 28.8 with this technology, and it could go up to 40kbps. This was pre-56k on uncompressed data, so it was a big YMMV type of thing. However back then, it was cool to be able to download something overnight. It beat running to the university campus's 24 hour computer lab with a boxful of floppies and a pkzip splitter.
One of the better innovations with modems, but one that was not heralded much was MNP3. MNP5 is a superset and offered compression which helped things, but MNP3 dealt away with the aggravation of line noise, and this by itself made a lot of difference in file transfers.
ISDN did dent modem sales, but at the time in the mid 1990s, ISDN was fairly expensive (about $150-$300 a month.) However, it had the advantage of very low latency. Modems (and mom/pop ISPs) really didn't die off until cable and DSL connections became both widespread and decently inexpensive.
Ironically in the US, modems have not been driven away completely. There are still plenty of areas that do not have cable or DSL access. Sometimes using a cellular "modem" [1] provides a solution, but sometimes that doesn't work (especially in hilly areas). Also, some people just don't do much with broadband, so they have downgraded to dialup because it is cheap.
[1]: Technically it isn't a modem, but a CSU/DSU. However, most people call the USB devices that plug into a laptop modems, even though they do no analog modulation or demodulation.
A good compromise is to make sure your sudo setup is good, and disable root logins via ssh completely. You can combine ssh with a utility that will drop in temporary (or permanent) ipchains rules denying IPs or an IP block access to the ssh port after a number of bad password guesses. This way, you won't need your private key if logging on from another host, but still have good resistance against people trying to crack root from remote.
If a Federal LEO, intel agency, or a well funded (and clued) forensics organization has my server, all bets are off. They would have dumped the RAM, fetched the BitLocker and TrueCrypt keys, dumped the hard disks via a hardware write blocker to a.vmdk file, and would be sifting through the results with every tool known to man.
If it is an ISP, then BitLocker + TPM is more than enough to keep the data on the machine out of their hands. Especially if one uses virtual machines with the disk files in TrueCrypt partitions. This case, they wouldn't just have to bypass BitLocker + the TPM, but ninja-install a keylogger. Even with a keylogger, they would still have to figure out what keyfile(s) I use. Unless they have a RAM dumping device, the only real avenue of attack they have is remotely rooting the host OS, or attacking the client operating systems on the VM.
Ironically, the only OS I know of that has encryption that allows for remote reboots while protecting the contents of encrypted volumes are newer versions of Windows that use Bitlocker with TPM chips. If someone yanks drives out of a Bitlocker protected system, the won't be decodable unless one has the recovery key, or one has the billion dollar resources of a chip fab to do disassembly of the TPM chip on the IC layer level in effort to yank out the stored decryption key.
I've found great success with coloced machines using BitLocker, then stacking client operating systems on that using VMWare or Hyper-V.
What killed the first iteration of mp3.com was the "music locker". This allowed one to read a CD in via some app, and allow playback of a track from their server. They were put down hard and very expensively in the courts by the powers that be, bankrupting the company. Had they kept with their core store model, I'm sure they will either still be in business (a la emusic.com), or bought up by someone else (perhaps Apple for the base of iTMS.)
mp3.com wasn't all evil. Yes, it had some bad policies, but it gave bands a showcase, and users a decent way to find related bands they like for a reasonable cost. It was also the central focus for bands to go to. When they went under, this scattered all the artists to many separate "new indie music" sites, making it hard to find a central place for new stuff to listen to, as well as related bands.
Before the Internet became widespread, high schools and libraries had to pay big dollars ($20 a query, as well as a monthly fee) so they would have dialup access to a database that would search for sources. Usually you had to be *very* good at phrasing, else you would get absolutely nothing relevant (as the database only would show the first 20-30 hits), and have to do another expensive query with better terms.
Do we want to go back to this model, where we would have to subscribe to a paywall to keep Google's bots running and their server farms up? I'll take Google's text ads instead of having to have a credit card on file and pay big cash per search.
"Are you sure" functionality is OK, but one of the things I try to drill into users' minds is to not rely on this alone. If a user is working on a thesis or valuable document, have mechanisms [1] to back up the critical documents so if one winds up with a blank document, it isn't a semester or career ending loss. Even making sure Previous Versions is turned on in recent Windows version may head off disaster (although this isn't a recommended backup method.)
[1]: Never back up critical files just one way alone. Use multiple methods, even if they are manual such as burning to CD or copying to a USB flash drive. And never store all your copies in the same place.
This gets me wondering about the supercap technology that bubbles up onto/. every so often. It is touted to have a much longer life than a capacitor because it stores the actual charge, not converts energy into a chemical process to be undone when discharging.
I'd love to see this type of battery pop up on the market. Very fast charging time so it can get from a deep cycle discharge to top off, combined with not having to replace it every 1-5 years. I'm sure the disadvantage is that if the battery is pierced and it grounds out, the discharge will be pretty explosive, combined with the fact that carbon nanotubes used to increase surface area of the electrodes is (IIRC) not friendly stuff when it comes to the environment.
Tape is the best way of doing offline backups, but it has three disadvantages these days:
1: Tape drives that can store decent capacities are expensive. Expect to shell out $3-4 grand for a drive, and lots more for an autochanger.
2: Tape drives require a large I/O path all the time. There is a reason why no tape drives made recently use USB -- they require a SAS or at the low end Ultra 160 on a dedicated card. If the box can't dish out up to the 100 mbps that the tape drive wants, the tape starts shoe-shining, causing wear and tear, and increasing the chance of bad sectors.
3: Tape drives are horrid at random access.
Of course, tape has some excellent advantages, because they have such a long archival life. So, if you have a tape drive (and I wish someone would be able to make one that could keep up with TB drives), the best thing to do is pair it up with a storage array and do D2D2T (disk to disk to tape). This way, backups go directly to disk, while on the own time, the backups can be moved to tape without depending on any other subsystem.
As an alternative to an external disk that goes to multiple machines, this might cost some, but perhaps consider a backup server?
The advantages to this setup:
1: The server initiates the backups, and can warn you in case something can't be read. 2: Most backup software stores snapshots, and some deal with the full/incremental/different cycle by using synthetic full backups. This makes restores to a certain point in time pretty easy. 3: More sophisticated backup software allows you to transfer backup sets to another media. This way, you just plug in a drive, do a transfer, and you have an offsite archive. 4: If one of the backup client machines gets hacked or malware installed, existing data stored on backup media cannot be altered.
The disadvantages:
1: You will need an active computer which is significantly more expensive than a hard disk. 2: Amanda/Zmanda for open source, Retrospect, Backup Exec, for commercial. The software costs a hefty chunk of change. 3: You have to make extremely sure that the backup server box is locked down tight. If someone compromises your backup server, they got data of every box you have. If you can, perhaps consider buying a router to put the backup server behind and only allowing the vital ports incoming. 4: Backup servers should have some redundancy for stored data. Because there is so much data stored from multiple boxes, a failure of a drive hurts more than on a normal machine. 5: Restoring a machine may vary in difficulty.
It would be nice for Verizon and Sprint to use R-UIM cards. From what I know, Chinese CDMA providers use these on a widespread basis. It saves them money over time because a user can upgrade devices without needing to have the cellular provider need to enter the device's IMEI number at their end.
Windows Mobile may be locked down on non touch screen/keyboard devices, where the WM6 API has two levels of security, but if you get a PocketPC, it definitely is not locked down. I'm sure there are exceptions though. I purchased my PocketPC from a provider who does not lock down their stuff in general.
My last WM phone allowed for incredible customization. Not just unlocking it for any GSM provider, but being able to completely cook a custom, flashable ROM for the device. This allowed me to have remove provider personalization stuff that took up precious memory, while letting me have the apps I wanted. It even allowed me to overclock it which made things like Skype run better. And of course, security was good because there were two methods to remotely wipe the phone, and anything stored on the external card was encrypted.
The other issue is population imbalances. If you know you are playing a MMO where most people play rocks in PvP, you are not going to bother playing scissors, and either are going to play paper or a better equipped rock. This is why you see certain classes in MMOs heavily populated while others rarely represented -- if you can't beat them, join them.
Slashdot Mirror
IIRC, VZW's 4G is going to be GSM, so there may not be a need for a CDMA iPhone, if Apple decides to second source.
The Moment also has one of the fastest CPUs in the business. This is something I wish Sprint advertised. Even with the vendor stuff, it still runs pretty well, and the OLED screen is nice too.
Sprint needs to toot their horn when they get a really cool flagship phone. VZW did this with the Droid.
"4g", which I'm stating in quotes will be coming from some interesting sources:
Sprint's baby, clear.com is getting 4G service out various places. This service not just handles mobile phones, but is touted to replace cable and DSL, with wireless modems that go from WiMax to wi-fi.
T-Mobile is going to be upgrading to their next gen stuff using their existing towers and infrastructure, as well as pairing with Comcast to get things rolling in some areas. It is said that what they will end up with can be used by existing devices, and was stated to be in the 4G speed (10Mbps or so).
The Register has an article posted on 23 December stating that Verizon wants to cover 95% of the US population with 4G service (LTE) by 2013. This seems to be a GSM successor, so phones using this technology will use SIM cards, making it perhaps possible to use VZW with unlocked phones in a few years.
AT&T also plans to go LTE, and a press release says they want to reach 90% of their existing 3G network by 2011.
My take: I REALLY wish the 4G LTE networks use compatible frequencies, so if I buy an unlocked device, I can drop a SIM card and use it on VZW's network, AT&T's, or T-Mobile's.
People are wising up though. The Droid's marketing campaign just hasn't gotten people into VZW's doors, it has spurred interest in Android devices in general. I've talked with people who see the Droid, find it interesting, but prefer T-Mobile, and end up coming out with a Samsung Behold, a Motorola Cliq, or a MyTouch 3G. People on Sprint find that the Samsung Moment offers one of the fastest processors. The only carrier that has no current offering is AT&T, but supposedly they will be offering a Dell Android phone. AT&T also has the iPhone, so just business common sense says that Android devices will be second fiddle to AT&T's mainstay.
I like both designs. The candy bar style phone is great with a touch screen, large display, and many features. It makes a great work phone.
However, I don't like being in "work mode" 24/7 unless I am doing a project or I'm on call. I like a basic featured flip phone because it is small, unobtrusive, and fits nicely in a pocket. If the flip phone gets dropped, splashed in water, accidently microwaved, or otherwise trashed, I'm down $15 to $40, the cost of a bubble pack generic GSM "pay as you go" phone. If I'm really unlucky, I'm out a $20 SIM card. That's far better than the $400 my main phone would cost if that got ruined. Plus, unless I'm on call off hours, having no Exchange support or pushed E-mail is just fine with me. I'm still reachable in a bona fide emergency, it just takes the effort of making a call or a text message.
There is a cost of letting them store data: You lose assurance of physical access. For some things, this is just fine. I highly recommend offsite backup utilities (Mozy or Carbonite) for students and SOHO people because combined with a keyfile stored in another safe place, it offers good security even if someone's office gets destroyed. But this doesn't scale. My Carbonite keyfile that protects the data stored offsite for three machines is not going to be a usable solution for a SMB with an IT department with turnover.
For small businesses with a single point of contact, maybe cloud storage is fine. However, for bigger businesses, it is better off to just go with a d2d2t solution, and offsite backups. This way, data is physically protected from compromise, but is stored redundantly.
On the cheap with the DIY storage, perhaps consider buying multiple terabyte drives, and using a tape rotation system to keep data backed up, with multiple drives brought on and offsite. This will provide decent disaster protection, but you still have physical control of the data.
SSL is different. The encryption key that is used is used just for the communication, then is tossed. In general, one will not have a SSL negotiated key for last week's bank transaction on their computer.
Because the SSL key management is about keys that are tossed, there isn't much of an issue with the nodes in between.
Cloud computing is about long term, persistant storage. The session key that gets chucked in SSL has to be kept permanently somewhere when it comes to storage, and key management is a major headache. Have too little redundancy, you can lose access forever to data. Have too much redundancy, and keys can wind up in the hands of blackhats and people who you really don't want to have access.
Don't forget: The US isn't the only company with a USAPATRIOT-like law.
Store data on an Elbonian server, and the data is available to their intel agencies and law enforcement (who likely will use the data to help their companies compete, or if they don't like the West, direct attackers to soft targets.)
Those archives of tax records stored on a cloud? Better hope your encryption is tight, not just now, but can stand attacks 20 years from now. I'm sure that in 20 years, AES will have cracks starting to show, just like DES had its small keyspace and 64 bit block size make it irrelevant for today's encryption tasks.
Cloud computing violates the first rule of security: Don't let the data be accessible in any shape or form to those not authorized. It goes with one of the fundamental rules of the Internet which is often ignore:, don't put anything on a Net accessible computer that you would be afraid of it ending up linked off of 4chan.
Cloud computing has some seductive properties for PHBs: It is just a network jump away through an API, requires no dedicated equipment on the client site, and the big named company salespeople who play in the same foursome at the golf course sell the stuff.
However, if one drops the smoke and mirrors, there isn't much difference between cloud storage and FTP-ing files onto a remote site.
So, what does one do? Before someone states "encrypt it!" one has to know that there are two parts to encrypting:
First is choosing the algorithms (AES-256, and if worried about an AES crack, chain AES and Serpent or Twofish [1]) and how they are implemented (ECB bad, XTS good). You also add to this how one can tell if the key is valid, and one of the most secure ways is to have the key use a salt, decrypt part of the cyphertext, and check it against a known value. TrueCrypt does this when validating if a filesystem is OK to mount.
The second part is not as obvious, but it means as much to secured data as the cypher: Key management is where you feel the burn. The simplest key management is having some random passphrase the maximum length allowed stored in a file on a USB flash drive and printed out for safekeeping. However, this runs you into the same issues as using WPA2-PSK, if the key is divulged on one area, the whole security of the system is now compromised.
Which means that you have to have a system of subkeys where the keys will decrypt the master key, similar to how PGP stores multiple passphrases and public key information to open a PGPDisk. You can give everyone a different passphrace to remember, or you can give them some type of smart card that unlocks the information. If a passphrase is divulged, it will suck, but given time, it can be removed from the authorized list.
Don't forget not just using one volume key for the data, one needs to use a different one every so often, so a compromised subkey which allows someone to slurp up the main decryption key won't compromise everything.
In reality, after a company goes through their iterations of a key management system, going from passphrases to RSA keys (because passphrases are hard to remember), then going from a list of keys to a full blown PKI with multiple recovery mechanisms, companies usually end up going to a smart card system. Of course, this is expensive and requires an elaborate support structure, but it is the best way of dealing with key management we have. And of course smart cards have driver hell in most cases.
So, with all the complexity that one needs to have in place for an encryption layer before stuff ends up stored offsite, it gets to a point where why should one even bother? Instead, for a number of SMBs with a non trivial amount of employees, they should just buy tape libraries and a backup program that has encryption. Some drives (like some of HP's) have encryption functionality in hardware. Then after the tapes are backed up, they are either stored in the data center (with restricted access), a tape safe, or an Iron Mountain tub.
What is the advantage of going back to tape even though cloud computing is seductive and seems like all problems of storage are just an Internet connection away? You know who has physical possession of the data at all times. It is a lot easier to deny someone access to physical media by rekeying locks, yanking their HID card access, or striking their name from the authorized user rolls at the offsite system than it is to deny access to stuff where you don't know even where it is stored.
With physical media, you have two pieces of security. The physical media itself, and the encryption on it. With cloud storage, ALL your se
As an alternative, one could use a port knocking system in combination with a script that blocks the ssh port from various IP ranges. This way, a spider just sniffing out ports will run a portscan, see no port 22 is open, and go on its merry blackhat way. The only downside of port knocking is that some places (open wireless networks) disallow any outbound ports other than 22, 80, 443, and maybe 1723 out, so one wouldn't be able to tap the ports that would allow ssh in from the IP range you are at.
Even if a robot worked 100%, it doesn't mean all humans are useless. Moving parts wear out, metal expands and contracts out of calibration, heavily loaded parts get fatigued, screws work loose, lubricants degrade. So, no matter how good the robots are, they need to be put offline to be recalibrated, replacement parts installed, bearings repacked and regreased.
Of course, minor adjustments may require major software modifications. I'll use the common tape robot as an example. Say one is made to take AIT cartridges. To make it work with DLT media would take a major recalibration, if it would even be possible.
This isn't to say robots are important, but in no way they can completely replace humans, as someone has to service them when (not if) they fail.
There is one other algorithm that the Courier had that the Sportster lacked: the USR proprietary algorithm, HST. On some nights, you could have a 28.8 with this technology, and it could go up to 40kbps. This was pre-56k on uncompressed data, so it was a big YMMV type of thing. However back then, it was cool to be able to download something overnight. It beat running to the university campus's 24 hour computer lab with a boxful of floppies and a pkzip splitter.
One of the better innovations with modems, but one that was not heralded much was MNP3. MNP5 is a superset and offered compression which helped things, but MNP3 dealt away with the aggravation of line noise, and this by itself made a lot of difference in file transfers.
ISDN did dent modem sales, but at the time in the mid 1990s, ISDN was fairly expensive (about $150-$300 a month.) However, it had the advantage of very low latency. Modems (and mom/pop ISPs) really didn't die off until cable and DSL connections became both widespread and decently inexpensive.
Ironically in the US, modems have not been driven away completely. There are still plenty of areas that do not have cable or DSL access. Sometimes using a cellular "modem" [1] provides a solution, but sometimes that doesn't work (especially in hilly areas). Also, some people just don't do much with broadband, so they have downgraded to dialup because it is cheap.
[1]: Technically it isn't a modem, but a CSU/DSU. However, most people call the USB devices that plug into a laptop modems, even though they do no analog modulation or demodulation.
A good compromise is to make sure your sudo setup is good, and disable root logins via ssh completely. You can combine ssh with a utility that will drop in temporary (or permanent) ipchains rules denying IPs or an IP block access to the ssh port after a number of bad password guesses. This way, you won't need your private key if logging on from another host, but still have good resistance against people trying to crack root from remote.
Depends on who is doing the possessing:
If a Federal LEO, intel agency, or a well funded (and clued) forensics organization has my server, all bets are off. They would have dumped the RAM, fetched the BitLocker and TrueCrypt keys, dumped the hard disks via a hardware write blocker to a .vmdk file, and would be sifting through the results with every tool known to man.
If it is an ISP, then BitLocker + TPM is more than enough to keep the data on the machine out of their hands. Especially if one uses virtual machines with the disk files in TrueCrypt partitions. This case, they wouldn't just have to bypass BitLocker + the TPM, but ninja-install a keylogger. Even with a keylogger, they would still have to figure out what keyfile(s) I use. Unless they have a RAM dumping device, the only real avenue of attack they have is remotely rooting the host OS, or attacking the client operating systems on the VM.
Ironically, the only OS I know of that has encryption that allows for remote reboots while protecting the contents of encrypted volumes are newer versions of Windows that use Bitlocker with TPM chips. If someone yanks drives out of a Bitlocker protected system, the won't be decodable unless one has the recovery key, or one has the billion dollar resources of a chip fab to do disassembly of the TPM chip on the IC layer level in effort to yank out the stored decryption key.
I've found great success with coloced machines using BitLocker, then stacking client operating systems on that using VMWare or Hyper-V.
What killed the first iteration of mp3.com was the "music locker". This allowed one to read a CD in via some app, and allow playback of a track from their server. They were put down hard and very expensively in the courts by the powers that be, bankrupting the company. Had they kept with their core store model, I'm sure they will either still be in business (a la emusic.com), or bought up by someone else (perhaps Apple for the base of iTMS.)
mp3.com wasn't all evil. Yes, it had some bad policies, but it gave bands a showcase, and users a decent way to find related bands they like for a reasonable cost. It was also the central focus for bands to go to. When they went under, this scattered all the artists to many separate "new indie music" sites, making it hard to find a central place for new stuff to listen to, as well as related bands.
Before the Internet became widespread, high schools and libraries had to pay big dollars ($20 a query, as well as a monthly fee) so they would have dialup access to a database that would search for sources. Usually you had to be *very* good at phrasing, else you would get absolutely nothing relevant (as the database only would show the first 20-30 hits), and have to do another expensive query with better terms.
Do we want to go back to this model, where we would have to subscribe to a paywall to keep Google's bots running and their server farms up? I'll take Google's text ads instead of having to have a credit card on file and pay big cash per search.
"Are you sure" functionality is OK, but one of the things I try to drill into users' minds is to not rely on this alone. If a user is working on a thesis or valuable document, have mechanisms [1] to back up the critical documents so if one winds up with a blank document, it isn't a semester or career ending loss. Even making sure Previous Versions is turned on in recent Windows version may head off disaster (although this isn't a recommended backup method.)
[1]: Never back up critical files just one way alone. Use multiple methods, even if they are manual such as burning to CD or copying to a USB flash drive. And never store all your copies in the same place.
This gets me wondering about the supercap technology that bubbles up onto /. every so often. It is touted to have a much longer life than a capacitor because it stores the actual charge, not converts energy into a chemical process to be undone when discharging.
I'd love to see this type of battery pop up on the market. Very fast charging time so it can get from a deep cycle discharge to top off, combined with not having to replace it every 1-5 years. I'm sure the disadvantage is that if the battery is pierced and it grounds out, the discharge will be pretty explosive, combined with the fact that carbon nanotubes used to increase surface area of the electrodes is (IIRC) not friendly stuff when it comes to the environment.
Tape is the best way of doing offline backups, but it has three disadvantages these days:
1: Tape drives that can store decent capacities are expensive. Expect to shell out $3-4 grand for a drive, and lots more for an autochanger.
2: Tape drives require a large I/O path all the time. There is a reason why no tape drives made recently use USB -- they require a SAS or at the low end Ultra 160 on a dedicated card. If the box can't dish out up to the 100 mbps that the tape drive wants, the tape starts shoe-shining, causing wear and tear, and increasing the chance of bad sectors.
3: Tape drives are horrid at random access.
Of course, tape has some excellent advantages, because they have such a long archival life. So, if you have a tape drive (and I wish someone would be able to make one that could keep up with TB drives), the best thing to do is pair it up with a storage array and do D2D2T (disk to disk to tape). This way, backups go directly to disk, while on the own time, the backups can be moved to tape without depending on any other subsystem.
As an alternative to an external disk that goes to multiple machines, this might cost some, but perhaps consider a backup server?
The advantages to this setup:
1: The server initiates the backups, and can warn you in case something can't be read.
2: Most backup software stores snapshots, and some deal with the full/incremental/different cycle by using synthetic full backups. This makes restores to a certain point in time pretty easy.
3: More sophisticated backup software allows you to transfer backup sets to another media. This way, you just plug in a drive, do a transfer, and you have an offsite archive.
4: If one of the backup client machines gets hacked or malware installed, existing data stored on backup media cannot be altered.
The disadvantages:
1: You will need an active computer which is significantly more expensive than a hard disk.
2: Amanda/Zmanda for open source, Retrospect, Backup Exec, for commercial. The software costs a hefty chunk of change.
3: You have to make extremely sure that the backup server box is locked down tight. If someone compromises your backup server, they got data of every box you have. If you can, perhaps consider buying a router to put the backup server behind and only allowing the vital ports incoming.
4: Backup servers should have some redundancy for stored data. Because there is so much data stored from multiple boxes, a failure of a drive hurts more than on a normal machine.
5: Restoring a machine may vary in difficulty.
It would be nice for Verizon and Sprint to use R-UIM cards. From what I know, Chinese CDMA providers use these on a widespread basis. It saves them money over time because a user can upgrade devices without needing to have the cellular provider need to enter the device's IMEI number at their end.
Windows Mobile may be locked down on non touch screen/keyboard devices, where the WM6 API has two levels of security, but if you get a PocketPC, it definitely is not locked down. I'm sure there are exceptions though. I purchased my PocketPC from a provider who does not lock down their stuff in general.
My last WM phone allowed for incredible customization. Not just unlocking it for any GSM provider, but being able to completely cook a custom, flashable ROM for the device. This allowed me to have remove provider personalization stuff that took up precious memory, while letting me have the apps I wanted. It even allowed me to overclock it which made things like Skype run better. And of course, security was good because there were two methods to remotely wipe the phone, and anything stored on the external card was encrypted.
The other issue is population imbalances. If you know you are playing a MMO where most people play rocks in PvP, you are not going to bother playing scissors, and either are going to play paper or a better equipped rock. This is why you see certain classes in MMOs heavily populated while others rarely represented -- if you can't beat them, join them.