We sort of have that with OpenPGP encrypted files, and Web add-ons. However, it assumes one is going to load their private keys into the Web browser... and because the Web browser is the first thing that gets its face curb-stomped come a 0-day, this may not be a wise thing unless there is OS support for keeping the keys, decryption module, and decrypted text viewer/attachment manager well out of the browser's OS context.

The reason I suggest an old fashioned MUA is because they tend to not be as vulnerable to malformed E-mail messages when configured properly. The spammy E-mails either try to get someone to download a wrapped executable (.scr extensions are commonplace), or get the user to visit a bad site. The E-mail themselves tend to not by themselves be dangerous, assuming scripting is turned off by default.

Maybe only queries or certs that make sense as per laws, such as 13, 18, 21, 25, 65, etc. There wouldn't be a legal reason that a bar would need to know anything more than if they are legal, unless they were doing a retiree special (which the over 65 cert would cover.) The goal is to provide the minimal amount of info as needed for regulations.

I've wondered about an ID system with a smart chip, except based around a certificate and trust model. For example, Alice's ID would have a cert (each cert has a different life span [1]) showing that she is over 21, has a valid driver's license, is a US citizen, is not a felon.

At the bar, the card gets swiped, the cert shows she is over 21, so is allowed in. No birthdate needed.

When going for a loan, there is a cert showing her FICO score is above a threshold, her income is above a certain amount, and she is a US citizen. Just three pieces of info that are needed.

When going for a car purchase, there is a signature stating she has valid insurance, and a valid license. No more details are needed.

This would greatly improve privacy if done right.

[1]: The criminal record certs can have a short life, so someone who gets convicted either has the "not a felon" cert revoked, or it expires in a week's time.

ISIS is becoming a carrier standard for this. It uses NFC, a special SIM card with the ISIS application (so it can have its own PIN separate from the SIM's PIN/PIN2), and an Amex or Wells Fargo credit card.

Is ISIS a good thing? Possibly, but you have to open a new line of credit to use it, in most cases.

Of course, there is Google Wallet and PayPal as well, so there may be a standard war between those three companies.

I wouldn't say it would be the end of credit card fraud. It makes people more dependent on their phone, which means dire consequences if it is stolen, or if malware seizes control of the unit and is able to key-log the PIN.

Another issue is that some protocols are viewed negatively. Tor comes to mind, because it is anonymous and works well... but it becomes a source of abuse, and it is also associated with the Four Horsemen of the Infocalypse. If one could get mainstream users not just using Tor, but setting up usable exit nodes, it might change the perception.

Sometimes, I wonder about an encryption protocol implementation like iMessage being broken up into multiple companies, all separate, perhaps in different countries:

1: The company that codes the client.
2: The company with the servers where messages reside.
3: The company that writes the protocol.
4: The company that officially signs the executables to be distributed, but vets the code base for unauthorized changes before doing so.

By splitting this up, it would take compromise of at least two of the above, and definitely the company with the servers.

I've used both PGP and GPG, but I have run into the spam filters. With S/MIME, I've run into people flipping out when they see the ribbon icon in a received E-mail on Outlook, to the point getting their company's legal department and a LEO involved because they thought a validated signature was malware.

What I'd like to see is a signing system that piggybacks onto GPG, or perhaps S/MIME that would allow for read receipts (provided the receiver chose to allow it to be sent)... but maybe allow for mail to be "un-sent", although the mechanism involved would have to be flawless, or else it would be a big security issue.

Maybe this is pure Ludditism, but the best security is gotten by having a MUA that is separate from the e-mail provider, and the MUA handles PGP/gpg or S/MIME keys.

There is something nice and convenient about Web based E-mail, but it is at a cost of end to end security.

It isn't as good as end to end, but with Exchange, one can do encrypted TLS connectors with other Exchange sites that one does a lot of E-mail or other messaging with. This will secure the E-mail as it goes from site "A" to site "B". However, if site "C" still uses unencrypted SMTP, then anything going there isn't really secured.

I just wonder how long it will be until some microbe evolves that can chew on polymers, breaking them up into something digestible.

In theory, Google can be forced to push out an add-on that slurps up private keys and uploads them. However, no solution is 100%, and anything is better than nothing.

The best solution is to have a MUA, (not a Web browser... a dedicated MUA that isn't a general purpose renderer) handle all E-mail, with separate modules that don't autoupdate that handle PGP/gpg and other encryption. However, anything is better than nothing, and this will do a decent job at protecting against intrusion internally.

1: Compatible with OpenPGP (except for some reasonable caveats. Not bad.)

2: Some thought in building it, not just slinging a beta for download, wise.

3: Keys stored away from where the bad code can compromise a browser... smart.

So far, this seems to be something that can be useful for one who does use PGP or gpg often.

This is probably similar to how some call all digital audio players, "iPods", or any tablet an iPad. For example, someone looking at a tablet, and telling the clerk they wanted the "Samsung iPad".

Is buying an Android phone a "mistake"? To answer a question with a question, is buying a Ford F-350 over a Dodge 3500 a mistake?

Yesterday's WWDC had a lot of stuff being announced, I'd say one of the more useful announcements was the iCloud storage price drop and the fact that iCloud can be used directly as a drive similar to Dropbox. However, Google Drive has had this functionality for a while, and its price is about the same as Apple's offering.

As for Android being a "mistake", not really. I don't know any tasks that you can do on iOS that can't be done on Android unless it is due to Apple-specific stuff like iMessage. Vice-versa, the main thing Android can do over non-jailbroken iOS are fairly esoteric things like accessing a sshfs volume, something that isn't really an everyday thing for most people.

It really depends on the phone. The HTC phone I bought recently has ROMs available before it officially went on sale. In fact, some unofficial ROMs like CM can have support and updates for a long time after the phone has been discontinued. (I bought the HTC phone because it has plenty of disk space, and it had a MicroSD slot, and with a quick app, the SELinux profile allowed for older apps to work with the external card without issue.)

I wouldn't discount Android just yet. Instead, I'd just be careful what model I buy, and watch features/specs.

If a SD card doesn't matter, a Nexus or GPE (Google Play Experience) device almost certainly will have the ability to unlock the bootloader in the future, so that may be the way to go.

There are a lot of places here in the US, where even basic DSL or cellular service is fairly hard to come by, and if one goes with a conventional satellite provider, it becomes very expensive very fast.

This is something that I have high hopes for... done right, and assuming the uplink/downlink antennas are not too expensive, this would allow a baseline of Internet access in a whole region. Latency is "meh", but it is a lot better than what a lot of places have right now.