That actually do already exist.
It's a car's collision avoidance system.
It's already standard option from some manufacturer (e.g.: Volvo) (and should become mandatory in EU somewhere soonish).

Some like Mobileye rely entirely on camera, while other are integrating other sensors in the mix, like radar, infra red lasers, etc.

But yeah I see your point: complex task require complex network, way much more than this chip.

The best would be it for such thing to be an actually HTML5 extension.

Gmail, Yahoo, Hotmail, etc. just flag which "TEXTAREA" tag contains the message body (or a greasemonkey script does it for them it they don't support it yet) and then the in-browser functionnality handles the encryption/decryption, completely outside of the reach of the webpage and its javascripts.

Except if only the browser it-self is exclusively in charge of the decryption/encryption.

The browser does the job, and all the webpage and associated javascripts ever see in the TEXTAREA is exclusively an encrypted stream.

That should be done in a plug-in, or even better: in a complete standard way - add it as an extension to HTML5.

...which in real life should only be used by the postman handling the delivery of the mail and shouldn't be mined by some 3rd party.

That is more or less doable (either server-2-server encrytion for the simplest form, or messaging over a tor-like network for the best protection) but has nothing to do with PGP.

PGP is about protecting the content (i.e.: it has nothing to do with the address written *on* the parcel handled by the postman. It's more like the content of the parcel being a safe box which can only be opened by someone having the key corresponding to the padlock on the safe box).

web-of-trust encryption (like PGP, and like the GnuPG implementation) is about encrypting the *BODY OF THE MESSAGE*.

I.e.: everything that comes after the subject is encrypted in a way that only the 2 end-points (author and recipients) are able to decrypt.
Without encryption, the content of an e-mail is as secure as a post-card.

Everything that comes before the subject, i.e.: all the headers that form this juicy "metadata" that the government wants, needs to be also readable to all the middle-men standing between the 2 end-point and who are in charge of distributing the mail. (e.g.: with paper mail, the postman needs to also see the address, otherwise he can't deliver it) But only to those in charge with the actual delivery (e.g.: only the postman sees what's written on the outside of the envelope. You don't want the gardener to keep a list of whom you're writting to).

That is encrypted by a completely different layer: it's the server-to-server encryption (things like the SSL and STARTTLS addition to IMAP/STMP/POP) which are in charge of keeping the metadata from beeing scoped.
But then you need to trust every server that your mail goes through (i.e.: you need to trust that none of all the various postmen who'll handle you mail is actually an undercover NSA spy posing as a postman) and you need to trust their security implementation (i.e.: that the postman delivering your mail pictures isn't clumsy and won't accidentally break your envelope and spill your nude picture on the ground, just right at the moment when a spy is around) (saddly, my comparison sucks: real world postmen aren't so clumsy, but real world cryptography is complex, and it's dead simple to bork something somewhere and leak secret information).

So yeah, metadata are important to protect too, but that's completely ireelevant. That remains instead for future discussion.

Note: perfectly safe messaging including secure metadata would require completely different infrastructure. Something like messaging over a tor network, instead of using a network of mail relay servers.

Well actually that's also the way to do single recipient mail too.

Assymetric encryption is very ressource demanding and only work using fixed-sized blocks.

Better encrypting a session key even for 1 recipient.

But nothing prevents the two end-point on using known-sure browser without backdoor to access the website.
If it's done in a standard manner (i.e.: a browser plugins that provides a standard way to create "securearea" a textarea whose content is transparently encrypted/decrypted by the plugin outside of the reach of the website), or even better if it's integrated into web standards (make the "securearea" tag part of HTML5 just like the "video" tag), then any compatible implementation could collaborate with any compliant webmail provider.
Then it's the same kind of security provided by e-mail client. Nothing prevents the NSA from forcing Microsoft to put a backdoor into Outlook (or more likely, nothing prevents them from using exploit-du-jour to compromise outlook). But in turn, nothing prevents you and your mail correspondant to both pick-up a known-secure and audited copy of Thunderbird from Tor's bundle and use that for swaping your nude-pics privately.

Well, actually *THAT* would be a very good target for standardisation.
Forget about all this bullshit for adding standardised DRM protection on HTML5 videos...

We need a specific and standard way to declare a "public key protected" text fields.
All that the websites and the javascript ever see is just an encrypted string, the browser is in charge of encrypting/decrypting and presenting the content, all outside the scope of the webmail itself.

Same for attachments (browser handle the downloading and decrypting).

And a bit of key handling (well, browsers, already handle public-key infrastructure, it could be only minor modification to be able to also handle web-of-trust), where the webmail provider only has a searchable service for public key, and secure-storage of private key is handled by the browser (as are currently the private PKI keys stored. Or the saved password sotred and synced).

It's already doable with plugins (and some actually do it). But it would be good if it was integrated as an HTML5 extension available on major engines (Firefox/Gecko, Webkit, etc.) so that it could be tapped by interested webmail providers (Yahoo, but maybe GMail or Hotmail, or maybe future successors of Lavabit) or web chats (see CryptoCat for an example of plug-ins doing exactly that)

Then you're not the target audience for this service.

It's targeting:

- The anxious people ("Doctor, the tip of my nose is itchy a bit, am I gonna die ?!") where 99% of the time all you need is to ask them and make sure that there are no other worrying symptoms and reassure them and ask them to come to the office if it persists longer than a week ("Has half of you face melted? No? Then it's definitely *not* Noma, no need to panic. Come see me if next week if it still does persist").

- The very simply common disease that are basically just about renewing the supply of self-medications ("Why do you bother coming here for a common cold?", "But doctor, I'm out of acetaminophene.", "ah, okay. here's your prescription.")

- The recurring simple infection that are actually damn easy to diagnose (e.g.: women who have often bladder infections can very easily recognise them. No new alarming symptom that wasn't there last time? It will probably go away with a simple drug) (e.g.: boyfriend has some bacterial STD? girlfriend needs a prescription to protect her too, and if she doesn't have any symptoms at all, she doesn't require an actual visit to the doctor beyond a few question about allergies).

If you break your leg in an accident, there's no way that a skype conversation will help you.

Well, actually speaking about what you said (needing to listening the lungs, etc) it might work the other way around: there are some people (call them "hyper"-chondriacs if you will) that tend to downplay symptoms because they don't want to bother loosing time going to the doctor's and think that the symptoms will wear of. If you provide them with a phone-line maybe some of them will think giving a call isn't that much bothersome, and will at least call the doctor. That also means that doctor can take the opportunity to explain to them that the thing is a little bit more serious than they've taught and persuade them that maybe it would be good to drop by the office for a more thorough check (or directly rush to the ER).

Actually, it's a nice example of something that would help the addiction:
the drug you mention, Percocet, contains a substance called oxycodon. This one is an opioid. A morphine-class substance. It *is* a narcotic.

So you see the scheme:
- call some tele-doc. pretend to have an episode of intense backpain, pretend to be on a work trip in this city, and being in a hurry. you just need 2-3 days supply of percocet, until you go back home and see your family doctor for an appointment.
- get a presciption. get it from the pharmacy.
- repeat the procedure calling a different skype-doc.
after a while you have a good supply of opioids.

The only way this could be prevented:
- that there exist a reliable electronic patient file
- that there an easy way to access it securily, some chipcard serving as security token (it's doable using the chips on the EU insurance cards, for example).
- that the patient is physically present in the doctor's office so that the doctor can get the security token (chip) to quickly access the patient's file, and notice that the patient has consulted 20x time during the last week with the same story.

But physical presence of the patient is required to transmit the security token.
Otherwise you would need a system, were a doctor can open your file, simply by looking up your name, while you skype him. I.e.: very low security system where anybody could find your file without your consent.

It's a balance between the convenience of a system (just call the doctor), and its abuseability (get any drugs, access any medical information)

I assume that the visit during which you were declined pain medication, wasn't the visit to the ER room right after the accident, but a visit sometime afterward because the pain was still there.

Two things:

- Some doctors are very suspicious of patient asking for pain medication regarding an old accident. Lots of pain meds are addictive and should not be taken long term. You might have been an addict simply trying to persuade the doctor to prescribe your next hit.

- Pain management is complicated. What works in the short term, doesn't necessary on the long term. Morphine-class pain medication (like the codeine depicted in the TV-Show "House") are addicting, you can use them short-term (the emergency response team will give you a shot), but you won't be prescribing them constantly over the several-month-long recovery. There are other drugs used for longer time during the recovery that would be more appropriate: anti-inflammatory drugs and similar class (acetaminophen/paracetamol). There are different drugs helping with some chronic pain (corticoids).
There are some completely different way to treat constant chronic pain (some alternate use of low-dose anti-depressors can actually be benefic against chronic pain). etc...
Some handling of pain might not even include drugs at all: several weeks/months after an accident, what will help the most could be physiotherapy.

I'm not justifying that your doctor behaved like an asshole, I'm simply saying that there are valid reasons (both subjective and objective) not to give drugs.

Now, in your specific case, if you're still having pains a long time after the accident, I suggest you see some pain-management specialists. And/or some orthopedist or rhumatologist: maybe there have been some permanent damages after your accidents.

More proof to your hypothesis:Facebook is currently hiring kernel hackers. With a humorous "we gotta beat FreeBSD!" target, but still. BSD-jokes aside, it's another proof that they are interested in increasing kernel performance and thus people with very good low-level knowledge would be welcome, no matter these people's current product has very few practical application.

Or even better, just ask their own secret service which has been longer at this game and have way much more resource than a simple contractor operating alone.
FSB probably knows a lots more than Snowden would even dream being able to intercept. And probably knows it long time ago, some dating back when FSB still went by the name KGB...

<sarcasm> Yup, I'm positively sure that a single lone rogue simple consultant has unreleased document to bring that are completely unknown to the mighty FSB (a.k.a KGB ( a.k.a tcheka)) and their own information channels~ </sarcasm>

Russia/USSR has been for much more longer time at this spy game and are likely to be damn good at it.

- Snowden is probably of no information-gathering interest to Russia (beyond the fact that he managed to publicly reveal what lot of them already knew but couldn't publicly reveal without bringing suspicion on their own communication channels, and that lots more on the crypto scene suspected but couldn't confirm)

- On the other hand, Snowden has a very good political interest for Russia as a very nice pawn. As you mention, he's a thorn that they can use to frustrate the US. And they can also leverage to look good to the international scene ("Hey look at us! We protect whistle blowers instead of throwing them in solitary at gitmo !")

Yup, it's possible. Basically two ways:
- GPS that have databse of speedlimits (also useful when the GPS computes the fastest route). That's both available at some car manufacturer (as a random example, Volvo's nav does it) and available at 3rd parties (As an exemple, the openstreetmaps database has speed limits, and the opensource navit application does display them, along with color-code (green/red) to tell you if your within/beyond the limits).
That would be rather easy to integrate into TFA's HUD. (as it has on-board and can also connect to smartphones over bluetooth. And maybe could also get the information from the infotainment over the ODB2? No idea about that).

- Optical recognition:
Latest generation camera and image recognition capabilities of crash avoidance systems (like mobilEYE which is one of the major manufacturer and 3rd-party solution provider) are able to detect and decode traffic sign like speed limits. This could also be fed into the HUD's onboard apps, or ask the smart-phone to display it to the hud instead of its own screen).

The radios have a capabilities called RDS on which are broadcast informations like TMC, and its common place nearly everywhere in europe. This information is used by the GPS (either the in-car, or a 3rd party with an integrated FM receiver). Whenever a problem happens, the TMC information about it is digitally broad cast over RDS and your GPS gives a small alert box, telling that you might need to adapt your route to the newest information and giving you the options to read the information (if you haven't heard them over TA/TP) and giving you the option to have the GPS calculate a safe alternate route around the problem.

Again something useful to have on the HUD, and not that complicated to integrate.