That is true. However, we are the people who beg the PHBs for a budget so we can have a decently working IDS, SecurID cards so VPN users who get compromised by malware on their laptops don't allow remote intruders, or allow for a sane security policy that actually works.
The PHBs don't see that. They see that they are paying money for something that does not bring them anything. Instead, they spend the $100,000 to get the highest sales guy a new BMW so he can impress clients. The PHBs don't learn by example. They think Airbus or other incidents like that are just bad luck. Even if disaster strikes, there is always some IT guy that can be thrown under the bus.
You hit the nail on the head here. Encryption, and security in general has no ROI. Therefore, a number of businesses will do the absolute minimum to keep up appearances. They will happily take the risk of a breach, because they can always put out an apology, push out a GPO blocking changes of the average company user's wallpaper and say they increased security. Other places believe they can just call a contracting team to clean up the mess, believing it will not happen.
You won't see serious security and encryption demands coming from the private sector. This will have to come from governments who are tired of intrusions and passing strict data privacy laws with data retention limits. Only this will get the private sector to pay more than just tired old lip service to security.
That is good to know. I like cheap cellphone availability, mainly because for $15 and a top-off of minutes, I have a temporary number I can use for Craigslists transactions or other services where I don't want to give out my main cellphone. This way, if something bad does happen, I can give the cellphone (sans SIM card) away to someone at random, and pick up another.
Caveat: Make sure the phone is unlocked [1]. This shouldn't be a big deal, as you can send the model of phone and the IMEI number to an unlocker service and get a code back.
[1]: Unlocked != jailbroken/rooted. You can have a "#" sign on your phone, but still be locked out if you use another network's SIM card.
Sprint has some surprisingly good phones too. The Samsung Moment comes to mind which Sprint doesn't seem to advertise, but can compete well head to head against the Droid.
My concern is that Sprint is also betting the house on their Clear 4G technology, as opposed to going to LTE, which Verizon, T-Mobile, and AT&T are migrating to eventually. I've seen some relatively eye-popping bandwidth numbers on Clear devices (although ~110ms latency isn't the best for gaming.) However, because they are the odd man out and can't share towers with the other guys, and will have to match them tower for tower for equal coverage.
I'd use Sprint, but I'm quite happy with a GSM provider where I can swap the SIM card out of my smartphone into a basic unit I take when I don't need the functionality (or care about E-mail) of the Android device.
T-Mobile has some decent prepaid phones for $15. They are low end candybar Nokias, but are great as a backup phone, and are relatively bulletproof for such a low end device. If you need BlueTooth support, they also sell a flip phone for $40 that has basic Web browsing.
Clarification here: This is for versions of IE less than 8. IE 8 is good enough to use as an everyday browser, as long as you have Protected Mode selected for all zones (even trusted), and that DEP is on (it ships that way.)
It is crazy, but there are sites out there that consider anything but IE6 unauthorized, and actually do scripting tests to validate what someone is using.
You would be surprised. There are still a lot of websites out there which will not just tell you to take a hike if you are not using IE, but actually run JavaScript tests to check if someone spoofed the user agent field.
My solution: Run IE... but in a limited user session in a virtual machine that rolls back to a known good snapshot when closed. This works on Macs, and Windows boxes. Since Windows 7 offers XP as a download, might as well take advantage of it. This way, any zero days just mean that the VM user in the guest OS gets infected, and that infection gets dumped the second I'm done dealing with the website in question and close the VM.
One of the better systems I've seen for doing this was one implemented for a company that had a private network that was disconnected fron the Internet just for embedded devices:
The internal network for reporting on embedded stuff had one machine that polled the embedded controllers and pulled data from them. The corporate intranet had another box which took the data and moved it to a Web server. Connecting the two was a serial cable, which was fast enough at 19200 BPS to move the small datasets, and a cronjob did this this every several minutes. The box on the embedded network had a custom kernel that had no SLIP/PLIP/PPP capabilities, and would poll the controllers, gpg sign the output and send it via the serial connection to the other machine. Even the serial cable was cut so data only flowed one way. The machine the data was pushed to would sit there, read the incoming serial connection and decode the gpg packets before pushing to the website.
This way, the worst that happens is the machine on the LAN gets compromised, with no physical way to jump across to the embedded network. This setup has worked for years with no reported incidents. It may sound like overkill, but it ensured that barring physical compromise, the chances of a remote attacker getting onto the network with the embedded stuff is very slim.
I'm sure there are faster ways to do a serial connection than this, but for what was needed, this got the job done well.
If you have decent encryption, the number of backups doesn't matter. When I mean decent, I mean using a known good program. On the commercial Windows front, Retrospect and Backup Exec both have government certified [1] AES library implementations. For large hard disks, depending on OS, there is TrueCrypt, OS X's Disk Utility, EncFS, BitLocker To Go, and LUKS. For tapes, HP sells tape drives (LTO4s) that use AES encryption in hardware [2].
With all the encryption options, having multiple backups isn't going to reduce the security by any real amount, assuming the keys are protected and stored well.
[1]: Certified can be argued to not mean secure, but it means that the company paid for a third party to look at the AES implementation and confirm it meets standards.
[2]: With tape drives that support SPIN/SPOUT functionality, you can manually set a key for every tape, or let backup software handle the key management for you.
I'm pretty sure they would likely move to it, or seriously consider a move to it once it becomes stable, perhaps a little bit after that for hidden gotchas to be found and squashed. Even now, in the unstable/testing phase, it has remarkable performance and stability features. I can't wait until it gets into the stable phase.
I'm sticking with ext3 because it has been tried and true, with few reports of data loss due to the filesystem. The only filesystem which I'd upgrade to would be btrfs once that becomes production ready.
Meta tags would be nice to have, I agree there. Another thing I'd love to have is where the filesystem stored a SHA-256 or SHA-512 hash of files. This would be excellent for backups because all the backup program would have to do for deduplication would essentially be to pull the hashes, take the first file if there are multiple with the same hash. No need to guess if a file is changed by the mtime.
With TrueCrypt, what I used to do when moving files between college and home was to create a TC volume, stuff the goodies in it at one destination, using a keyfile off a smart card, then upload that. Then when I arrived at the other destination, I'd pull the TC volume from the cloud storage site, get to work, then re-upload it when done. Because I'm using a keyfile on a smart card, the cloud provider isn't going to have the relatively [1] easy attack surface that just a passphrase offers. This also helps mitigate "dumb" keyloggers. A keylogger might be able to grab my smart card's PIN, but without the card, it won't do the remote blackhat much good. However a "smart" keylogger that can snarf the PIN, then forge an access session to the smart card, yanking out the keyfile, then sending that to the attacker's site is feasible, especially if a target is a high value.
[1]: Relative is the word here, because a 20+ character password is extremely hard to guess, while a randomly generated keyfile that only exists on a smart card pretty much forces an attacker to have to brute force the whole 256 bit keyspace.
This was an EXTREMELY great fear in the early to mid 90s, when the government was trying to get everyone to standardize encryption on all devices using the Clipper chip (and key escrow in general). The chip had good throughput... but it allowed for people to pull out any keys if they had access to the LEAF (law enforcement access field). The algorithm was classified secret, and the chips were made in one factory, then moved to another factory where the algorithm was slapped on, before being shipped out
Funny thing, the cypherpunks were right. As soon as the algorithm was declassified, it was ripped apart in several days, and laid to rest months later. Had this been in every computer and communications device on the Web (and other cryptographic algorithms forbidden by law which was the other shoe that was feared to drop), the security of the Internet would have depended on the fact that the algorithm was unknown, and the second a blackhat figured it out who knew differential cryptanalysis, people would have had to permanently disconnect their businesses from the Internet for weeks to years until something was able to replace this, like another hardware device. As a twist of irony, blackhats could zero out the LEAF making their communications and keys un-escrowable.
So, leaving a back door for law enforcement seems like a good idea. However, it would completely ruin any trust customers give a product should blackhats find it present, and start using it. Obligatory car analogy: Nobody wants every car thief on the streets to have a master remote that unlocks their car and starts it up just at a button press, with no way of disabling this.
Have you see what root CA certs are in a browser? I'm sure that if one pulls it up and sees the list of trusted root certificates, there are offshore companies that people have not heard of, but yet not just hold charge of what is valid or not, but can delegate to people unknown who gets a green toolbar, and who doesn't. To boot, all it takes is just one of these to be compromised, and someone can start doing bogus certificates. Combine this with using Unicode text (the Cyrillic "C" is not the ASCII "C"), and one could completely spoof a legit site in an advanced phishing attack... or just threaten that legit site with the spoofing so they would pay protection fees.
What I'd like to see in Web browsers is perhaps something similar to what is done in ssh, where the Web browser keeps track of the SSL certificate that the bank uses. If it changes, the browser will pop up a notice, and perhaps show some pertinant info, showing that this is either legit, or maybe show that someone spoofed a CA and the cert is completely bogus.
Hushmail does exactly this. If you use the Java (as opposed to the Javascript/SSL) client, the only place E-mail gets decrypted is on your personal computer. I use Hushmail for both secure E-mail (PGP encrypted), as well as aliases that I can dispose of, such as when I'm posting to Craigslist and only want the address to last the duration of the buy/sell/work transaction.
(Yes, Hushmail did have to give information to LEOs a couple years ago, but that doesn't mean that anyone and everyone has access to one's stored data.)
If it paid the salary, I wouldn't care if I was paid to just keep one Windows Small Business Server PC up and running. You get what you can take in this economy. No, it wouldn't be as fun as a rackful of high end suns with a root prompt just waiting for you, but it is better than nothing.
You *can* run apps from the SD card, but it takes rooting and unionfs to do so. Something I would not recommend to anyone who does not have both a UNIX background, and a bit of modding experience. Similar with enabling swap so the phone doesn't run out of memory.
I know Google did this for security (because SD cards do not have a filesystem that supports UNIX permissions, so one app can mess with another if it is on the card.) However, what would be nice is if Google would dig up the long dead UMSDOS filesystem project and consider using that to enforce permissions on removable media. This way, the SD card can appear as a FAT or FAT32 volume when attached to a computer, but on the phone, permissions would be enforced by the OS and the "--LINUX-.---" files in directories. As an alternative to this, have a loopback mounted partition on the SD card that supports ext3, YAFFS, or a similar filesystem that handles UNIX style permissions.
Before mid 2007, it was Windows Mobile versus BlackberryOS that were the high end choices for the smartphone market. Microsoft made the mistake of not shifting the OS from stylus-based input (as per PDAs) to finger-based as fast as they should have, and MS's offering got left in the dust.
People make fun of Windows Mobile but it is a good OS. It has a very simple, but very workable model for encrypting data on memory cards in WM 6 and newer, and can be wiped from remote either via Exchange, or Microsoft's MyPhone service.
I wish Android could take three features of Windows Mobile: SD card encryption (block level -- LUKS , or filesystem level like EncFS), support for Exchange wipe requests via remote, and the ability to have push E-mail. Samsung's phones offer push E-mail support, but it isn't a feature of Android, even 2.0. At best, most Android devices just check the Exchange server every 15 minutes.
In this market, I'm grateful to see -any- significant R&D done by US firms. In most companies, research is mainly to add features or reasons why consumers should buy this year's product over last year's. There is very little R&D done for revolutionary concepts (which in reality, the Volt is. People can talk about this type of car, or show some egg-shaped prototype at an auto show, but getting a vehicle mass produced and into driveways in the US and Europe while threading through all the safety and other regulations is a major feat.)
The Volt isn't perfect, but it is a step in the right direction. Someone has to do the version 1.0 and get it out the door [1]. Then we will see people improving on that.
[1]: The first recent hybrid vehicle in mass use in the US was the Honda Insight. Was a very good car, but consumers didn't like it because it was too small. However, once Honda did the dirty work, it wasn't hard for other automotive companies to see what went wrong and leapfrog with improved designs.
I think plugin cars will eventually hit the roads as a mainstream choice, more as evolution than revolution, similar to how more vehicles are getting dual mode gasoline/electric subsystems.
However, until supercap technology becomes mainstream, I don't see gas stations offering this service, just for the reason that it takes too long to charge a vehicle, even at 440 volts.
As for employers, I'm sure that some will make a token effort, just like how some will drop a bike rack nearish the front entrance and maybe have a rusting shower in the basement. However, most either do not have enough control of the property they are on to drop multiple electric circuits, or really just are not interested enough in spending thousands of dollars in an electrical infrastructure that doesn't boost their bottom line.
Maybe this is pie in the sky, but what I'd like to see is an unattended charging mode. You turn your car off then flip a switch so the gasoline engine stays on until the batteries are fully charged. The advantage of this is that one can regulate when the car is consuming fuel. A good use for this would be having a vehicle run and charge itself up while parked at a hotel, then in the morning, fill it up. This would give one maximum driving range for a long trip.
Gasoline doesn't go stale that fast. Yes gasoline does break down, but I've seen a tank's worth be usable months if not years later. What makes gas "stale" is almost always a fuel system that allows water in the lines, either via condensation, or through leaks. This will make a tank of gasoline unusable if there is enough water in the system.
If I'm storing a vehicle for medium term storage, I may or may not bother with gasoline preserver additive. Instead, I make sure the gas tank is full to minimize any effects of water getting in the system. So far, this has worked out well. Long term storage (years) is a different beast altogether. Here, I would drain the fuel system completely.
It is becoming more and more common for Web forum administrators on larger sites to either not allow accounts to be automatically created from "free" E-mail sites, or outright block access altogether for this exact reason. A "pay" provider means that someone shelled out something for the account, and thus there is a way to trace the payment to a real person (even if the person is a victim of ID theft.)
Of course, a blackhat can jack a custom domain and go at it until the domain gets blackholed, but that takes a lot more work (and only would last a limited time) than just trying to break CAPTCHAs on a popular provider and automate account creation. Because the big E-mail sites are so popular, nobody is going to blackhole them as a matter of policy. (I have seen high dollar clients use aol.com for their main E-mail addresses, so even though the domain may get a lot of spam or fradulent mail coming from it, I can't filter on domain origins alone.)
Then there is the privacy aspect. I have a pay domain and use an E-mail provider which has no free access. This way, barring civil/criminal issues, my domain's data is mine. No third party advertiser or data miner gets to sift through it for marketing reasons, add taglines on the bottom advertising crap, or display ads if I'm using Web access. To boot, the whole website is SSL based (Google does this, most providers don't), so if I end up on a network with an in-transit ad server, it cannot intercept or sniff what is going on the wire, barring a successful certification authority key forgery.
So, I do have the old reliable E-mail on the "free" providers for most mailing lists. However, for anything business or work related, I use my custom domain.
Ultimately, I'd like to see a simple/advanced install dialog. The simple one is what Android uses now. The user is presented with what the app wants to function optimally, user accepts or denies. The advanced one would require more than just one set of permission requests:
First, the absolute minimum to run with any functionality at all. So a syncing app would require at the minimum access to what you want synced, and a network connection. If an app has autoupdate functionality, instead of updating automatically, the app will tell the user to manually check for updates at this privilege level.
Second, the optimal permissions. For example, if an app has update functionality, this would be included here. Similar if a syncing app would want to read other utility data files.
Finally, the maximum permissions an app can ever have: For example, some apps should never be run as root, just because they never, ever need anything UID 0 offers. Web browsers for example. A simple Tetris clone might just need the ability to check for updates, and that is it. It would never need access to contacts or any other data files than its saved high scores. So handing a program access it will never need in its installed lifetime is stupid. Max permissions might come into play when one wants to have a utility that normally is a diary writer, but wants to use it to read/edit binary files in a directory not owned by it. Normally, few users would want to let the program out of its sandbox, but an advanced user who trusts the program can manually install it with these abilities.
The other thing I'd like to see is something like Droidwall, but part of the OS (perhaps buried somewhere so a novice user doesn't hamstring themselves on it). I shouldn't need to root my phone and have to see if some modder added iptables in order to ensure that some apps that don't need it either have no network connectivity, or only communicate to the few sites they are authorized to.
What I can see is that carriers would have their own Android app stores, similar to how one carrier in the US used to require not just Microsoft code certificates on signed executables, but the carrier's as well. If the app wasn't signed by a certificate either from the carrier, or a key allowed by the carrier, the app won't install on the phone. Of course, the certs can be yanked at a moment's notice.
Slashdot Mirror
That is true. However, we are the people who beg the PHBs for a budget so we can have a decently working IDS, SecurID cards so VPN users who get compromised by malware on their laptops don't allow remote intruders, or allow for a sane security policy that actually works.
The PHBs don't see that. They see that they are paying money for something that does not bring them anything. Instead, they spend the $100,000 to get the highest sales guy a new BMW so he can impress clients. The PHBs don't learn by example. They think Airbus or other incidents like that are just bad luck. Even if disaster strikes, there is always some IT guy that can be thrown under the bus.
You hit the nail on the head here. Encryption, and security in general has no ROI. Therefore, a number of businesses will do the absolute minimum to keep up appearances. They will happily take the risk of a breach, because they can always put out an apology, push out a GPO blocking changes of the average company user's wallpaper and say they increased security. Other places believe they can just call a contracting team to clean up the mess, believing it will not happen.
You won't see serious security and encryption demands coming from the private sector. This will have to come from governments who are tired of intrusions and passing strict data privacy laws with data retention limits. Only this will get the private sector to pay more than just tired old lip service to security.
That is good to know. I like cheap cellphone availability, mainly because for $15 and a top-off of minutes, I have a temporary number I can use for Craigslists transactions or other services where I don't want to give out my main cellphone. This way, if something bad does happen, I can give the cellphone (sans SIM card) away to someone at random, and pick up another.
Caveat: Make sure the phone is unlocked [1]. This shouldn't be a big deal, as you can send the model of phone and the IMEI number to an unlocker service and get a code back.
[1]: Unlocked != jailbroken/rooted. You can have a "#" sign on your phone, but still be locked out if you use another network's SIM card.
Sprint has some surprisingly good phones too. The Samsung Moment comes to mind which Sprint doesn't seem to advertise, but can compete well head to head against the Droid.
My concern is that Sprint is also betting the house on their Clear 4G technology, as opposed to going to LTE, which Verizon, T-Mobile, and AT&T are migrating to eventually. I've seen some relatively eye-popping bandwidth numbers on Clear devices (although ~110ms latency isn't the best for gaming.) However, because they are the odd man out and can't share towers with the other guys, and will have to match them tower for tower for equal coverage.
I'd use Sprint, but I'm quite happy with a GSM provider where I can swap the SIM card out of my smartphone into a basic unit I take when I don't need the functionality (or care about E-mail) of the Android device.
T-Mobile has some decent prepaid phones for $15. They are low end candybar Nokias, but are great as a backup phone, and are relatively bulletproof for such a low end device. If you need BlueTooth support, they also sell a flip phone for $40 that has basic Web browsing.
Clarification here: This is for versions of IE less than 8. IE 8 is good enough to use as an everyday browser, as long as you have Protected Mode selected for all zones (even trusted), and that DEP is on (it ships that way.)
It is crazy, but there are sites out there that consider anything but IE6 unauthorized, and actually do scripting tests to validate what someone is using.
You would be surprised. There are still a lot of websites out there which will not just tell you to take a hike if you are not using IE, but actually run JavaScript tests to check if someone spoofed the user agent field.
My solution: Run IE... but in a limited user session in a virtual machine that rolls back to a known good snapshot when closed. This works on Macs, and Windows boxes. Since Windows 7 offers XP as a download, might as well take advantage of it. This way, any zero days just mean that the VM user in the guest OS gets infected, and that infection gets dumped the second I'm done dealing with the website in question and close the VM.
One of the better systems I've seen for doing this was one implemented for a company that had a private network that was disconnected fron the Internet just for embedded devices:
The internal network for reporting on embedded stuff had one machine that polled the embedded controllers and pulled data from them. The corporate intranet had another box which took the data and moved it to a Web server. Connecting the two was a serial cable, which was fast enough at 19200 BPS to move the small datasets, and a cronjob did this this every several minutes. The box on the embedded network had a custom kernel that had no SLIP/PLIP/PPP capabilities, and would poll the controllers, gpg sign the output and send it via the serial connection to the other machine. Even the serial cable was cut so data only flowed one way. The machine the data was pushed to would sit there, read the incoming serial connection and decode the gpg packets before pushing to the website.
This way, the worst that happens is the machine on the LAN gets compromised, with no physical way to jump across to the embedded network. This setup has worked for years with no reported incidents. It may sound like overkill, but it ensured that barring physical compromise, the chances of a remote attacker getting onto the network with the embedded stuff is very slim.
I'm sure there are faster ways to do a serial connection than this, but for what was needed, this got the job done well.
If you have decent encryption, the number of backups doesn't matter. When I mean decent, I mean using a known good program. On the commercial Windows front, Retrospect and Backup Exec both have government certified [1] AES library implementations. For large hard disks, depending on OS, there is TrueCrypt, OS X's Disk Utility, EncFS, BitLocker To Go, and LUKS. For tapes, HP sells tape drives (LTO4s) that use AES encryption in hardware [2].
With all the encryption options, having multiple backups isn't going to reduce the security by any real amount, assuming the keys are protected and stored well.
[1]: Certified can be argued to not mean secure, but it means that the company paid for a third party to look at the AES implementation and confirm it meets standards.
[2]: With tape drives that support SPIN/SPOUT functionality, you can manually set a key for every tape, or let backup software handle the key management for you.
I'm pretty sure they would likely move to it, or seriously consider a move to it once it becomes stable, perhaps a little bit after that for hidden gotchas to be found and squashed. Even now, in the unstable/testing phase, it has remarkable performance and stability features. I can't wait until it gets into the stable phase.
I'm sticking with ext3 because it has been tried and true, with few reports of data loss due to the filesystem. The only filesystem which I'd upgrade to would be btrfs once that becomes production ready.
Meta tags would be nice to have, I agree there. Another thing I'd love to have is where the filesystem stored a SHA-256 or SHA-512 hash of files. This would be excellent for backups because all the backup program would have to do for deduplication would essentially be to pull the hashes, take the first file if there are multiple with the same hash. No need to guess if a file is changed by the mtime.
With TrueCrypt, what I used to do when moving files between college and home was to create a TC volume, stuff the goodies in it at one destination, using a keyfile off a smart card, then upload that. Then when I arrived at the other destination, I'd pull the TC volume from the cloud storage site, get to work, then re-upload it when done. Because I'm using a keyfile on a smart card, the cloud provider isn't going to have the relatively [1] easy attack surface that just a passphrase offers. This also helps mitigate "dumb" keyloggers. A keylogger might be able to grab my smart card's PIN, but without the card, it won't do the remote blackhat much good. However a "smart" keylogger that can snarf the PIN, then forge an access session to the smart card, yanking out the keyfile, then sending that to the attacker's site is feasible, especially if a target is a high value.
[1]: Relative is the word here, because a 20+ character password is extremely hard to guess, while a randomly generated keyfile that only exists on a smart card pretty much forces an attacker to have to brute force the whole 256 bit keyspace.
This was an EXTREMELY great fear in the early to mid 90s, when the government was trying to get everyone to standardize encryption on all devices using the Clipper chip (and key escrow in general). The chip had good throughput... but it allowed for people to pull out any keys if they had access to the LEAF (law enforcement access field). The algorithm was classified secret, and the chips were made in one factory, then moved to another factory where the algorithm was slapped on, before being shipped out
Funny thing, the cypherpunks were right. As soon as the algorithm was declassified, it was ripped apart in several days, and laid to rest months later. Had this been in every computer and communications device on the Web (and other cryptographic algorithms forbidden by law which was the other shoe that was feared to drop), the security of the Internet would have depended on the fact that the algorithm was unknown, and the second a blackhat figured it out who knew differential cryptanalysis, people would have had to permanently disconnect their businesses from the Internet for weeks to years until something was able to replace this, like another hardware device. As a twist of irony, blackhats could zero out the LEAF making their communications and keys un-escrowable.
So, leaving a back door for law enforcement seems like a good idea. However, it would completely ruin any trust customers give a product should blackhats find it present, and start using it. Obligatory car analogy: Nobody wants every car thief on the streets to have a master remote that unlocks their car and starts it up just at a button press, with no way of disabling this.
Have you see what root CA certs are in a browser? I'm sure that if one pulls it up and sees the list of trusted root certificates, there are offshore companies that people have not heard of, but yet not just hold charge of what is valid or not, but can delegate to people unknown who gets a green toolbar, and who doesn't. To boot, all it takes is just one of these to be compromised, and someone can start doing bogus certificates. Combine this with using Unicode text (the Cyrillic "C" is not the ASCII "C"), and one could completely spoof a legit site in an advanced phishing attack... or just threaten that legit site with the spoofing so they would pay protection fees.
What I'd like to see in Web browsers is perhaps something similar to what is done in ssh, where the Web browser keeps track of the SSL certificate that the bank uses. If it changes, the browser will pop up a notice, and perhaps show some pertinant info, showing that this is either legit, or maybe show that someone spoofed a CA and the cert is completely bogus.
Hushmail does exactly this. If you use the Java (as opposed to the Javascript/SSL) client, the only place E-mail gets decrypted is on your personal computer. I use Hushmail for both secure E-mail (PGP encrypted), as well as aliases that I can dispose of, such as when I'm posting to Craigslist and only want the address to last the duration of the buy/sell/work transaction.
(Yes, Hushmail did have to give information to LEOs a couple years ago, but that doesn't mean that anyone and everyone has access to one's stored data.)
If it paid the salary, I wouldn't care if I was paid to just keep one Windows Small Business Server PC up and running. You get what you can take in this economy. No, it wouldn't be as fun as a rackful of high end suns with a root prompt just waiting for you, but it is better than nothing.
You *can* run apps from the SD card, but it takes rooting and unionfs to do so. Something I would not recommend to anyone who does not have both a UNIX background, and a bit of modding experience. Similar with enabling swap so the phone doesn't run out of memory.
I know Google did this for security (because SD cards do not have a filesystem that supports UNIX permissions, so one app can mess with another if it is on the card.) However, what would be nice is if Google would dig up the long dead UMSDOS filesystem project and consider using that to enforce permissions on removable media. This way, the SD card can appear as a FAT or FAT32 volume when attached to a computer, but on the phone, permissions would be enforced by the OS and the "--LINUX-.---" files in directories. As an alternative to this, have a loopback mounted partition on the SD card that supports ext3, YAFFS, or a similar filesystem that handles UNIX style permissions.
Before mid 2007, it was Windows Mobile versus BlackberryOS that were the high end choices for the smartphone market. Microsoft made the mistake of not shifting the OS from stylus-based input (as per PDAs) to finger-based as fast as they should have, and MS's offering got left in the dust.
People make fun of Windows Mobile but it is a good OS. It has a very simple, but very workable model for encrypting data on memory cards in WM 6 and newer, and can be wiped from remote either via Exchange, or Microsoft's MyPhone service.
I wish Android could take three features of Windows Mobile: SD card encryption (block level -- LUKS , or filesystem level like EncFS), support for Exchange wipe requests via remote, and the ability to have push E-mail. Samsung's phones offer push E-mail support, but it isn't a feature of Android, even 2.0. At best, most Android devices just check the Exchange server every 15 minutes.
In this market, I'm grateful to see -any- significant R&D done by US firms. In most companies, research is mainly to add features or reasons why consumers should buy this year's product over last year's. There is very little R&D done for revolutionary concepts (which in reality, the Volt is. People can talk about this type of car, or show some egg-shaped prototype at an auto show, but getting a vehicle mass produced and into driveways in the US and Europe while threading through all the safety and other regulations is a major feat.)
The Volt isn't perfect, but it is a step in the right direction. Someone has to do the version 1.0 and get it out the door [1]. Then we will see people improving on that.
[1]: The first recent hybrid vehicle in mass use in the US was the Honda Insight. Was a very good car, but consumers didn't like it because it was too small. However, once Honda did the dirty work, it wasn't hard for other automotive companies to see what went wrong and leapfrog with improved designs.
I think plugin cars will eventually hit the roads as a mainstream choice, more as evolution than revolution, similar to how more vehicles are getting dual mode gasoline/electric subsystems.
However, until supercap technology becomes mainstream, I don't see gas stations offering this service, just for the reason that it takes too long to charge a vehicle, even at 440 volts.
As for employers, I'm sure that some will make a token effort, just like how some will drop a bike rack nearish the front entrance and maybe have a rusting shower in the basement. However, most either do not have enough control of the property they are on to drop multiple electric circuits, or really just are not interested enough in spending thousands of dollars in an electrical infrastructure that doesn't boost their bottom line.
Maybe this is pie in the sky, but what I'd like to see is an unattended charging mode. You turn your car off then flip a switch so the gasoline engine stays on until the batteries are fully charged. The advantage of this is that one can regulate when the car is consuming fuel. A good use for this would be having a vehicle run and charge itself up while parked at a hotel, then in the morning, fill it up. This would give one maximum driving range for a long trip.
Gasoline doesn't go stale that fast. Yes gasoline does break down, but I've seen a tank's worth be usable months if not years later. What makes gas "stale" is almost always a fuel system that allows water in the lines, either via condensation, or through leaks. This will make a tank of gasoline unusable if there is enough water in the system.
If I'm storing a vehicle for medium term storage, I may or may not bother with gasoline preserver additive. Instead, I make sure the gas tank is full to minimize any effects of water getting in the system. So far, this has worked out well. Long term storage (years) is a different beast altogether. Here, I would drain the fuel system completely.
It is becoming more and more common for Web forum administrators on larger sites to either not allow accounts to be automatically created from "free" E-mail sites, or outright block access altogether for this exact reason. A "pay" provider means that someone shelled out something for the account, and thus there is a way to trace the payment to a real person (even if the person is a victim of ID theft.)
Of course, a blackhat can jack a custom domain and go at it until the domain gets blackholed, but that takes a lot more work (and only would last a limited time) than just trying to break CAPTCHAs on a popular provider and automate account creation. Because the big E-mail sites are so popular, nobody is going to blackhole them as a matter of policy. (I have seen high dollar clients use aol.com for their main E-mail addresses, so even though the domain may get a lot of spam or fradulent mail coming from it, I can't filter on domain origins alone.)
Then there is the privacy aspect. I have a pay domain and use an E-mail provider which has no free access. This way, barring civil/criminal issues, my domain's data is mine. No third party advertiser or data miner gets to sift through it for marketing reasons, add taglines on the bottom advertising crap, or display ads if I'm using Web access. To boot, the whole website is SSL based (Google does this, most providers don't), so if I end up on a network with an in-transit ad server, it cannot intercept or sniff what is going on the wire, barring a successful certification authority key forgery.
So, I do have the old reliable E-mail on the "free" providers for most mailing lists. However, for anything business or work related, I use my custom domain.
Ultimately, I'd like to see a simple/advanced install dialog. The simple one is what Android uses now. The user is presented with what the app wants to function optimally, user accepts or denies. The advanced one would require more than just one set of permission requests:
First, the absolute minimum to run with any functionality at all. So a syncing app would require at the minimum access to what you want synced, and a network connection. If an app has autoupdate functionality, instead of updating automatically, the app will tell the user to manually check for updates at this privilege level.
Second, the optimal permissions. For example, if an app has update functionality, this would be included here. Similar if a syncing app would want to read other utility data files.
Finally, the maximum permissions an app can ever have: For example, some apps should never be run as root, just because they never, ever need anything UID 0 offers. Web browsers for example. A simple Tetris clone might just need the ability to check for updates, and that is it. It would never need access to contacts or any other data files than its saved high scores. So handing a program access it will never need in its installed lifetime is stupid. Max permissions might come into play when one wants to have a utility that normally is a diary writer, but wants to use it to read/edit binary files in a directory not owned by it. Normally, few users would want to let the program out of its sandbox, but an advanced user who trusts the program can manually install it with these abilities.
The other thing I'd like to see is something like Droidwall, but part of the OS (perhaps buried somewhere so a novice user doesn't hamstring themselves on it). I shouldn't need to root my phone and have to see if some modder added iptables in order to ensure that some apps that don't need it either have no network connectivity, or only communicate to the few sites they are authorized to.
What I can see is that carriers would have their own Android app stores, similar to how one carrier in the US used to require not just Microsoft code certificates on signed executables, but the carrier's as well. If the app wasn't signed by a certificate either from the carrier, or a key allowed by the carrier, the app won't install on the phone. Of course, the certs can be yanked at a moment's notice.