I think Android will end up thrashing its problems out probably by the end of this year, or first quarter of 2011, as the OS goes from having to be deployed as fast as possible to get marketshare before Apple locks down the market like they did with MP3 players, to changing to a mature app platform that is decently supported across handset makers and cellular carriers. Android 2.2 has taken some steps to get there, but what it will take is getting to where the iPhone OS is right now when it comes to encrypting user data.
Android still lacks some important features before it can make inroads into lucrative markets such as businesses (which buy smartphones by the thousands.) The first is true SD card encryption. Yes, apps on the SD card are encrypted in Android 2.2, but what is needed is encryption of any files the device plops onto the memory card, and to have this able to be enabled via the Exchange server. There is also the need of having other security features, such as erasing the device if someone guesses the PIN too many times, or if the SIM card gets swapped out to an unauthorized one. If this can be done, Android may start nudging the crufty (but secure and reg compliant) Windows Mobile devices out of the business sector.
My hope is that by the time Android gets this functionality, there will be devices that will not just support rooting, but be able to be custom flashed. As time goes on, devices are becoming more and more modder and rooting hostile. If this is the case, I really hope Google offers an ADP3 or ADP4.
I think if handset makers and carriers can do this, getting Android 2.2 as a baseline onto all devices might be what the doctor ordered for this.
The main reason is not just JIT compiling, nor the ability to run apps on the SD card (which is important for older phones). Instead, Android 2.2 offers a lot more modular upgrade path, where before devices in previous versions would have to be completely reflashed just to support one item.
Time will tell if 2.2 gets adopted, or if we still have the version fragmentation issue in the future.
apps2sd uses unionfs (or aufs) so to the app, it doesn't matter if it is located on an ext3 partition on the SD card, or in the internal memory of the phone. This way, no symlinking is needed, and to an app's perspective, it is starting up from internal memory, regardless of where it is located in reality.
Caveat: This only works on rooted phones and requires an ext3 partition on the SD card (for permissions and such) [1].
[1]: Amon-Ra's recovery image can easily partition a SD card, but you lose all data on it.
Between steps 2 and 3, I'd consider doing a nandroid backup. This way, you can fall back to the older ROM in case it doesn't work as well as one expects.
They are advertising the hotspot feature, so unless plans change, I'm pretty certain that it will ship with tethering. I have not heard anything about bandwidth charges or caps, so it might be something worth looking at when it comes out. I do want to see the fine print of the Evo contract though.
JIT compilers do help. A good example of this is.NET, where it uses an intermediary language which is compiled/translated for the CPU it is running on, and the native binaries are cached, and complaints about performance on.NET are fairly few from what I've read.
Java has had a bad reputation in performance, but in reality, those days are in the past. There are other issues with Java, but those are not performance related unless it deals with direct hardware calls, and one can use native code for that.
This is what Titanium Backup is for. Back up your apps (with the Google Market information) to your SD card, optionally back the SD card up somewhere safe, install the new ROM, re-root, and then restore your apps.
Disclaimer: I'm not related to the guys who made TB, just a happy customer.
10km is a good distance. However, if one could be able to both do quantum information across longer distances, and with a decent bandwidth, this would change communications as we know it just like fiber optic cables. Some examples:
Mars rovers could be controlled in real time -- no 4 hour lag time. Astronomy experiments could be done by sending instruments out and being able to observe items with a large virtual radio array in real time. Internet routing would be revolutionized -- it only would be the router's CPU speed that would be the latency limit, not distance.
With real time control of robotics even if they are on another planet, this would allow us to mine, but yet have a human operator on duty that can respond quickly if something happens in the cave -- no need to trust an AI 100% of the time.
ACTA will change the cat and mouse game. If the bar is raised so there is no piracy (such as on the PS3), there will be a fundamental shift to OSS projects, and the IP battle will then be fought on the patent trolls versus OSS project maintainers front.
Necessity is the mother of invention. Right now, BitTorrent + proxies, or BitTorrent + addons is good enough. If BT sites get squashed, someone is going to make a replacement that is distributed, using magnet links and distributed trackers. It might even be a distributed filesystem that stores random blocks on random computers in the network, where when a hash of a file is passed to one node, it will grab a range of blocks from some other nodes, and pass the rest of the block requests to still another node. Of course, throttling and blocking encrypted traffic might slow this down, but it would end up being tunneled over SSL, DNS, and other protocols.
Or, USENET would regain popularity and a lot of sites would pop up with a lot of storage and long alt.binaries.* retention.
What I'd like to see are Web browsers accepting self signed SSL certs, but not show a green lock icon. Instead some other mechanism should be used to show the site is using SSL, but there is no trust of the site's key, as opposed to a key that is signed by a CA in the trusted keys.
Even now, it is still harder to do an active MITM with ssl than just sit by and sniff packets.
Only issue with this: Part of SSL's security is assuring that www.foo.com is actually that site, and not a site which is getting connections via a subverted DNS or other means. Self-signed SSL certs do not provide this protection.
SSL is TCP based, so it does take time for to create the connection and tear it down.
However, a game which uses UDP packets primarily could easily set up a session key via a DH exchange (using an existing mechanism like SSL, or having keys/certs built into the game itself so third party CAs are not an issue), and once this is set up, CPU overhead due to using a symmetric cipher like AES would be very low.
It is apparent that you don't like Google. That's fine. However, that is beside the point. What is important is that the connection between the Google user and Google is only belonging to those two. A third party can slow down or block the SSL transaction, but unless they jack a root CA, compromise one of the endpoints, or break one of the encryption algorithms, they are not going to be seeing what is going on.
To reiterate: Regardless of opinions of Google, this is a good thing. A search query with Google is my business and Google's business. Not the ISP's, not Phorm's, not a MITM watching the traffic go by. I'm sure as time goes on, less scrupulous ISPs will be slavering over ad revenue from in-transit ads.
I see this also useful against Phorm, and other in-transit ad-insertion mechanisms.
All and all, the good guys benefit here. Google doesn't have ISPs modifying their ads in transit, replacing their ads with their own. The user gets search results that have not been tampered with (where a site for product "A" takes you to a different company, or associate IDs are replaced so different parties get credit for ad responses), and have potentially malicious ads thrown in. ISPs can't passively log the connection and sell the data (just like the parent said.)
Lets say that they kept the platform open, left the "Other OS" option available in the Slim, and perhaps made some developer tools that supported an app store. Perhaps a Dalvik-like JVM optimized for the Cell platform. Then hand out the ability for people to write games, stick them the app store and SCEI take a chunk of the proceeds.
This would result in an instant hit. There would be the existing market for console games and downloadables. However, Sony would also get big bucks from indie developers. People would hear about a cool indie game, and buy a PS3 just to be able to play it. Other people would write utilities for the PS3, so the hardware could function as a server appliance.
Instead of a game console, Sony would have a one size fits all appliance that they could sell varying versions of for good money. A server version with more Cell CPUs and storage which could be used as part of a render farm. They could even sell a blade configuration for use for high performance tasks.
However, Sony chose to go the closed route. They can celebrate -- their a console that is extremely resistant to hackers and modders. However, that gives a win in the short term. However, in the medium and long term, Sony could have had FAR more, had they just loosened their grip and made an open platform. They could have been the next SGI (in their heyday, of course) making money hand over foot selling to enterprises. In fact, Sony could have made a UNIX based OS and made money hand over foot with applications tuned for the Cell architecture.
Rooting an Android device and jailbreaking are two different things:
iPhone apps run in a chrooted BSD-based "jail", where by default they have no access to the main filesystem. Jailbreaking gives the iPhone user access to the full filesystem.
Android apps have their own UID and have access to the filesystem. Rooting allows for UID 0 access which allows for kernel level items, such as tethering, having various services on the phone (FTP, ssh, http), and being able to flash custom firmware.
By default, a user has far less access to items on the iPhone than an Android device.
With app2sd, people with custom ROMS have been doing this for a long time by having an ext3 partition on their phone and unionfs.
Now, what I want to see is Google offer encryption functionality not just for apps on the SD card, but all data present. This way, if someone steals the phone, they won't be able to just pop out the SD card and get at all the information on that. Of course, combine this with some way of recovering the encryption key (backup to a computer, store it with a passphrase, etc.)
I also am a fan of Android. The security model is excellent where apps are well isolated, and a potentially malicious app has to ask for permissions to do something before it gets installed. The UI is well done. The app store is great (not perfect, mind you, but does the job.)
My biggest wish or complaint: If Android handset makers want to lock down their phones with signed Linux kernels and such (the Milestone comes to mind on this), it is unfortunate. However, it would be nice to have a few models which are root/modder friendly, are the latest CPU/whatever features, and have different form factors. I like a hardware slider keyboard, while other people wouldn't want the added thickness on their phone. Having the ability to have source code for the ROM images would be nice too.
Thank you. I didn't see that even though I was digging through the Android docs. The encryption is essentially the same method that Windows Mobile 6+ use to encrypt files on the SD card.
The mechanism is excellent -- a user can move apps from the SD card to the internal memory at will, provided there is enough room.
Files stored on the SD are not protected by being root-only, unlike files in main memory. So, either copy-protected apps will not be able to be stored externally, or they will have some form of encryption-based DRM, or varying strength. It could be something as simple as AES-256ing the.APK files and storing the key in a root owned directory with 700 perms, to a system similar to WM-DRM which has yet to see a crack for more than a week or two.
My question: On Android 2.1 and earlier, copy-protected apps are kept in a directory only root has access to,/data/app-private.
Since apps are now installable on the memory card, are copy-protected apps only able to be put into internal memory, or is there a nasty new DRM mechanism put in to guard the apps that are on the SD card?
Just like the PP, If I were to recommend an A/V defense to someone, I rather take the method of having strong locks on the doors as opposed to an alarm system that notifies if someone is already in. Here is what I'd do with Windows:
First barrier to entry: A true hardware firewalling router. Unless the machine is a laptop which travels around, desktop boxes should not be facing the Internet if at all possible (and they are not doing server functions). Some services can be handled either by a port forward or a proxy.
Second barrier to entry: If you can run Windows's software firewall with "No Exceptions" checked, do so. If not, try to cut out as many apps/ports as possible, or as least make the ports only accessible to the local subnet.
Third barrier: Run as a user with no admin rights. If you can, do your system admin stuff under a "aausername", or a "usernamesu", which is a special user dedicated just to system admin functions that isn't root or admin. Yes, malware that infects a user is just one privilege escalation hole from superuser, but that is better than pwning the box just by claiming one user.
Fourth barrier: A web browser protected by an ad filter add-on. Because a lot of websites use unscrupulous third party ad-rotators, it is way too common for malformed Flash or HTML to be used as a possible exploit (the Antivirus 2010 attacks for example.) AdBlock, Privoxy, or even PeerBlock with a subscription come to mind here. Web browser choice comes into play, but this is more of a religious issue once the ads are out of the picture.
Fifth barrier: A basic A/V program. Enterprises need advanced reporting and auditing capabilities of Norton Endpoint Protection. SOHO users don't. So, I'd recommend something decent but lightweight like AVG, Avast!, or Microsoft Security Essentials, which are available (or have a version that is) at no charge.
First layer for after the fact: An external drive and a backup program (Acronis TrueImage, EMC Retrospect, etc.). The backup program Windows Vista offers different features depending on the edition. So, it is best just to use a third party program that allows you to make a restore CD so the PC user can do a "bare metal" recovery if everything gets trashed, as well as being able to get at a file after it was accidentally deleted. I'd rather spend money on a good third party backup utility than some premium version of commercial antivirus [1]. Also, third party backup utilities support encryption.
Second layer for after the fact: Mozy, Carbonite, or Backblaze. Say malware trashes your machine, your external drive, and everything else. This is why you use a keyfile and a remote backup service so you can get your documents back somehow. Since this is coming through the Internet, this is more of a last resort backup mechanism than anything else.
[1]: This goes for home usage. Companies are better off using an enterprise level program so they have audit capability and ability to know that all boxes are protected.
HSMs are pretty good. But if you manage to gain access as an authorized user or role with access to the key, you can go slaphappy signing/decrypting anything you want. And if this is a CA cert that is the top level for an enterprise, or a certificate signing an application, it might cause all kinds of trouble.
This also applies to smart cards. I'm sure eventually there will be malware that can do a MITM attack when a user is using a smart card.
Since Symantec has multiple backup programs, I really wish they would take the codebases of their two lines, and use them to make a really good next generation backup program, that eventually would phase out both BE and NetBackup.
For example, NetBackup allows for bare metal restores. But as soon as you restore, you must re-backup the box. Why not offer a facility to use the bare metal feature as a way to clone? Or shouldn't synthetic full backups be an innate part of the structure, like it is with TSM and Retrospect, while having the old fashioned full/incremental/differental structure available if someone wants it. Similar with deduplication. This should be something that is part of the core backup engine and backup file format, both on a file basis, as well as block by block (for things like duplicate VMs cloned from a single image.)
Certificates are good and bad. If used in a smart WOT, they are great because if you have multiple people trusting someone, you know you are almost certain that that key belongs to that person.
The bad is just blindly trusting root certificates, especially certs from countries who are hostile to the West, and who would be happy to certify with their CA a key belonging to a known bank, then occasionally poisoning DNS or routing queries to the fake site, so they don't get immediately caught.
The best might be a combination all three. You have a "security cache" of keys or signed keys of places and people you have previously interacted with, which is crucial for ssh for the most secure communications. Next, you have a WOT with people you know trusting or not. Finally, you have a CA which may actually be valid, or not. CAs are really a part of WOT, and should be considered with little or no trust, compared to someone coming with (to continue the parent's example) a high Bacon number to yours. The only problem is someone who isn't familar with a WOT giving a key too high a trust that it deserves, but infiltration happens in every network, and with PGP or gpg, it is easy to mark a person's signatures as untrustworthy.
This reminds me of something different: Maybe it is time to get people and start doing PGP/gpg keysigning parties [1] again. This way,
[1]: Of course, there is the proper way of doing the key stuff. Send a list of public keys to the host, host prints out a list for everyone. Everyone then brings a copy of their key ID and hashes. Then go around matching the keys to the individual, perhaps asking for IDs, then circling the ones which pass the validity test. This way, no computers are used, and it is much harder to "compromise" someone's piece of paper showing vetted keys in the length of time it takes for them to leave the party and get home to sign everyone's keys and push the signatures to keyservers.
Slashdot Mirror
I think Android will end up thrashing its problems out probably by the end of this year, or first quarter of 2011, as the OS goes from having to be deployed as fast as possible to get marketshare before Apple locks down the market like they did with MP3 players, to changing to a mature app platform that is decently supported across handset makers and cellular carriers. Android 2.2 has taken some steps to get there, but what it will take is getting to where the iPhone OS is right now when it comes to encrypting user data.
Android still lacks some important features before it can make inroads into lucrative markets such as businesses (which buy smartphones by the thousands.) The first is true SD card encryption. Yes, apps on the SD card are encrypted in Android 2.2, but what is needed is encryption of any files the device plops onto the memory card, and to have this able to be enabled via the Exchange server. There is also the need of having other security features, such as erasing the device if someone guesses the PIN too many times, or if the SIM card gets swapped out to an unauthorized one. If this can be done, Android may start nudging the crufty (but secure and reg compliant) Windows Mobile devices out of the business sector.
My hope is that by the time Android gets this functionality, there will be devices that will not just support rooting, but be able to be custom flashed. As time goes on, devices are becoming more and more modder and rooting hostile. If this is the case, I really hope Google offers an ADP3 or ADP4.
I think if handset makers and carriers can do this, getting Android 2.2 as a baseline onto all devices might be what the doctor ordered for this.
The main reason is not just JIT compiling, nor the ability to run apps on the SD card (which is important for older phones). Instead, Android 2.2 offers a lot more modular upgrade path, where before devices in previous versions would have to be completely reflashed just to support one item.
Time will tell if 2.2 gets adopted, or if we still have the version fragmentation issue in the future.
apps2sd uses unionfs (or aufs) so to the app, it doesn't matter if it is located on an ext3 partition on the SD card, or in the internal memory of the phone. This way, no symlinking is needed, and to an app's perspective, it is starting up from internal memory, regardless of where it is located in reality.
Caveat: This only works on rooted phones and requires an ext3 partition on the SD card (for permissions and such) [1].
[1]: Amon-Ra's recovery image can easily partition a SD card, but you lose all data on it.
Between steps 2 and 3, I'd consider doing a nandroid backup. This way, you can fall back to the older ROM in case it doesn't work as well as one expects.
They are advertising the hotspot feature, so unless plans change, I'm pretty certain that it will ship with tethering. I have not heard anything about bandwidth charges or caps, so it might be something worth looking at when it comes out. I do want to see the fine print of the Evo contract though.
JIT compilers do help. A good example of this is .NET, where it uses an intermediary language which is compiled/translated for the CPU it is running on, and the native binaries are cached, and complaints about performance on .NET are fairly few from what I've read.
Java has had a bad reputation in performance, but in reality, those days are in the past. There are other issues with Java, but those are not performance related unless it deals with direct hardware calls, and one can use native code for that.
Unless the app has been designed for this functionality in the manifest, it won't be able to be moved to the SD card.
http://developer.android.com/guide/appendix/install-location.html has more details.
This is what Titanium Backup is for. Back up your apps (with the Google Market information) to your SD card, optionally back the SD card up somewhere safe, install the new ROM, re-root, and then restore your apps.
Disclaimer: I'm not related to the guys who made TB, just a happy customer.
10km is a good distance. However, if one could be able to both do quantum information across longer distances, and with a decent bandwidth, this would change communications as we know it just like fiber optic cables. Some examples:
Mars rovers could be controlled in real time -- no 4 hour lag time.
Astronomy experiments could be done by sending instruments out and being able to observe items with a large virtual radio array in real time.
Internet routing would be revolutionized -- it only would be the router's CPU speed that would be the latency limit, not distance.
With real time control of robotics even if they are on another planet, this would allow us to mine, but yet have a human operator on duty that can respond quickly if something happens in the cave -- no need to trust an AI 100% of the time.
ACTA will change the cat and mouse game. If the bar is raised so there is no piracy (such as on the PS3), there will be a fundamental shift to OSS projects, and the IP battle will then be fought on the patent trolls versus OSS project maintainers front.
Necessity is the mother of invention. Right now, BitTorrent + proxies, or BitTorrent + addons is good enough. If BT sites get squashed, someone is going to make a replacement that is distributed, using magnet links and distributed trackers. It might even be a distributed filesystem that stores random blocks on random computers in the network, where when a hash of a file is passed to one node, it will grab a range of blocks from some other nodes, and pass the rest of the block requests to still another node. Of course, throttling and blocking encrypted traffic might slow this down, but it would end up being tunneled over SSL, DNS, and other protocols.
Or, USENET would regain popularity and a lot of sites would pop up with a lot of storage and long alt.binaries.* retention.
What I'd like to see are Web browsers accepting self signed SSL certs, but not show a green lock icon. Instead some other mechanism should be used to show the site is using SSL, but there is no trust of the site's key, as opposed to a key that is signed by a CA in the trusted keys.
Even now, it is still harder to do an active MITM with ssl than just sit by and sniff packets.
Only issue with this: Part of SSL's security is assuring that www.foo.com is actually that site, and not a site which is getting connections via a subverted DNS or other means. Self-signed SSL certs do not provide this protection.
SSL is TCP based, so it does take time for to create the connection and tear it down.
However, a game which uses UDP packets primarily could easily set up a session key via a DH exchange (using an existing mechanism like SSL, or having keys/certs built into the game itself so third party CAs are not an issue), and once this is set up, CPU overhead due to using a symmetric cipher like AES would be very low.
It is apparent that you don't like Google. That's fine. However, that is beside the point. What is important is that the connection between the Google user and Google is only belonging to those two. A third party can slow down or block the SSL transaction, but unless they jack a root CA, compromise one of the endpoints, or break one of the encryption algorithms, they are not going to be seeing what is going on.
To reiterate: Regardless of opinions of Google, this is a good thing. A search query with Google is my business and Google's business. Not the ISP's, not Phorm's, not a MITM watching the traffic go by. I'm sure as time goes on, less scrupulous ISPs will be slavering over ad revenue from in-transit ads.
I see this also useful against Phorm, and other in-transit ad-insertion mechanisms.
All and all, the good guys benefit here. Google doesn't have ISPs modifying their ads in transit, replacing their ads with their own. The user gets search results that have not been tampered with (where a site for product "A" takes you to a different company, or associate IDs are replaced so different parties get credit for ad responses), and have potentially malicious ads thrown in. ISPs can't passively log the connection and sell the data (just like the parent said.)
This is going to be their downfall.
Lets say that they kept the platform open, left the "Other OS" option available in the Slim, and perhaps made some developer tools that supported an app store. Perhaps a Dalvik-like JVM optimized for the Cell platform. Then hand out the ability for people to write games, stick them the app store and SCEI take a chunk of the proceeds.
This would result in an instant hit. There would be the existing market for console games and downloadables. However, Sony would also get big bucks from indie developers. People would hear about a cool indie game, and buy a PS3 just to be able to play it. Other people would write utilities for the PS3, so the hardware could function as a server appliance.
Instead of a game console, Sony would have a one size fits all appliance that they could sell varying versions of for good money. A server version with more Cell CPUs and storage which could be used as part of a render farm. They could even sell a blade configuration for use for high performance tasks.
However, Sony chose to go the closed route. They can celebrate -- their a console that is extremely resistant to hackers and modders. However, that gives a win in the short term. However, in the medium and long term, Sony could have had FAR more, had they just loosened their grip and made an open platform. They could have been the next SGI (in their heyday, of course) making money hand over foot selling to enterprises. In fact, Sony could have made a UNIX based OS and made money hand over foot with applications tuned for the Cell architecture.
Rooting an Android device and jailbreaking are two different things:
iPhone apps run in a chrooted BSD-based "jail", where by default they have no access to the main filesystem. Jailbreaking gives the iPhone user access to the full filesystem.
Android apps have their own UID and have access to the filesystem. Rooting allows for UID 0 access which allows for kernel level items, such as tethering, having various services on the phone (FTP, ssh, http), and being able to flash custom firmware.
By default, a user has far less access to items on the iPhone than an Android device.
With app2sd, people with custom ROMS have been doing this for a long time by having an ext3 partition on their phone and unionfs.
Now, what I want to see is Google offer encryption functionality not just for apps on the SD card, but all data present. This way, if someone steals the phone, they won't be able to just pop out the SD card and get at all the information on that. Of course, combine this with some way of recovering the encryption key (backup to a computer, store it with a passphrase, etc.)
I also am a fan of Android. The security model is excellent where apps are well isolated, and a potentially malicious app has to ask for permissions to do something before it gets installed. The UI is well done. The app store is great (not perfect, mind you, but does the job.)
My biggest wish or complaint: If Android handset makers want to lock down their phones with signed Linux kernels and such (the Milestone comes to mind on this), it is unfortunate. However, it would be nice to have a few models which are root/modder friendly, are the latest CPU/whatever features, and have different form factors. I like a hardware slider keyboard, while other people wouldn't want the added thickness on their phone. Having the ability to have source code for the ROM images would be nice too.
Thank you. I didn't see that even though I was digging through the Android docs. The encryption is essentially the same method that Windows Mobile 6+ use to encrypt files on the SD card.
The mechanism is excellent -- a user can move apps from the SD card to the internal memory at will, provided there is enough room.
Files stored on the SD are not protected by being root-only, unlike files in main memory. So, either copy-protected apps will not be able to be stored externally, or they will have some form of encryption-based DRM, or varying strength. It could be something as simple as AES-256ing the .APK files and storing the key in a root owned directory with 700 perms, to a system similar to WM-DRM which has yet to see a crack for more than a week or two.
My question: On Android 2.1 and earlier, copy-protected apps are kept in a directory only root has access to, /data/app-private.
Since apps are now installable on the memory card, are copy-protected apps only able to be put into internal memory, or is there a nasty new DRM mechanism put in to guard the apps that are on the SD card?
Just like the PP, If I were to recommend an A/V defense to someone, I rather take the method of having strong locks on the doors as opposed to an alarm system that notifies if someone is already in. Here is what I'd do with Windows:
First barrier to entry: A true hardware firewalling router. Unless the machine is a laptop which travels around, desktop boxes should not be facing the Internet if at all possible (and they are not doing server functions). Some services can be handled either by a port forward or a proxy.
Second barrier to entry: If you can run Windows's software firewall with "No Exceptions" checked, do so. If not, try to cut out as many apps/ports as possible, or as least make the ports only accessible to the local subnet.
Third barrier: Run as a user with no admin rights. If you can, do your system admin stuff under a "aausername", or a "usernamesu", which is a special user dedicated just to system admin functions that isn't root or admin. Yes, malware that infects a user is just one privilege escalation hole from superuser, but that is better than pwning the box just by claiming one user.
Fourth barrier: A web browser protected by an ad filter add-on. Because a lot of websites use unscrupulous third party ad-rotators, it is way too common for malformed Flash or HTML to be used as a possible exploit (the Antivirus 2010 attacks for example.) AdBlock, Privoxy, or even PeerBlock with a subscription come to mind here. Web browser choice comes into play, but this is more of a religious issue once the ads are out of the picture.
Fifth barrier: A basic A/V program. Enterprises need advanced reporting and auditing capabilities of Norton Endpoint Protection. SOHO users don't. So, I'd recommend something decent but lightweight like AVG, Avast!, or Microsoft Security Essentials, which are available (or have a version that is) at no charge.
First layer for after the fact: An external drive and a backup program (Acronis TrueImage, EMC Retrospect, etc.). The backup program Windows Vista offers different features depending on the edition. So, it is best just to use a third party program that allows you to make a restore CD so the PC user can do a "bare metal" recovery if everything gets trashed, as well as being able to get at a file after it was accidentally deleted. I'd rather spend money on a good third party backup utility than some premium version of commercial antivirus [1]. Also, third party backup utilities support encryption.
Second layer for after the fact: Mozy, Carbonite, or Backblaze. Say malware trashes your machine, your external drive, and everything else. This is why you use a keyfile and a remote backup service so you can get your documents back somehow. Since this is coming through the Internet, this is more of a last resort backup mechanism than anything else.
[1]: This goes for home usage. Companies are better off using an enterprise level program so they have audit capability and ability to know that all boxes are protected.
HSMs are pretty good. But if you manage to gain access as an authorized user or role with access to the key, you can go slaphappy signing/decrypting anything you want. And if this is a CA cert that is the top level for an enterprise, or a certificate signing an application, it might cause all kinds of trouble.
This also applies to smart cards. I'm sure eventually there will be malware that can do a MITM attack when a user is using a smart card.
Since Symantec has multiple backup programs, I really wish they would take the codebases of their two lines, and use them to make a really good next generation backup program, that eventually would phase out both BE and NetBackup.
For example, NetBackup allows for bare metal restores. But as soon as you restore, you must re-backup the box. Why not offer a facility to use the bare metal feature as a way to clone? Or shouldn't synthetic full backups be an innate part of the structure, like it is with TSM and Retrospect, while having the old fashioned full/incremental/differental structure available if someone wants it. Similar with deduplication. This should be something that is part of the core backup engine and backup file format, both on a file basis, as well as block by block (for things like duplicate VMs cloned from a single image.)
Certificates are good and bad. If used in a smart WOT, they are great because if you have multiple people trusting someone, you know you are almost certain that that key belongs to that person.
The bad is just blindly trusting root certificates, especially certs from countries who are hostile to the West, and who would be happy to certify with their CA a key belonging to a known bank, then occasionally poisoning DNS or routing queries to the fake site, so they don't get immediately caught.
The best might be a combination all three. You have a "security cache" of keys or signed keys of places and people you have previously interacted with, which is crucial for ssh for the most secure communications. Next, you have a WOT with people you know trusting or not. Finally, you have a CA which may actually be valid, or not. CAs are really a part of WOT, and should be considered with little or no trust, compared to someone coming with (to continue the parent's example) a high Bacon number to yours. The only problem is someone who isn't familar with a WOT giving a key too high a trust that it deserves, but infiltration happens in every network, and with PGP or gpg, it is easy to mark a person's signatures as untrustworthy.
This reminds me of something different: Maybe it is time to get people and start doing PGP/gpg keysigning parties [1] again. This way,
[1]: Of course, there is the proper way of doing the key stuff. Send a list of public keys to the host, host prints out a list for everyone. Everyone then brings a copy of their key ID and hashes. Then go around matching the keys to the individual, perhaps asking for IDs, then circling the ones which pass the validity test. This way, no computers are used, and it is much harder to "compromise" someone's piece of paper showing vetted keys in the length of time it takes for them to leave the party and get home to sign everyone's keys and push the signatures to keyservers.