This is currently only the accounts system. We are extending it step by step to other systems.
I spent some time working out the best way and I think I have something sensible. On the accounts system, once logged in, you can update contact details by a link on the main page.
This allows contact detail to be updated, including email address, but also allows you to paste in a PGP public key to use.
We don't care what UIDs, emails, or trust there is set in that, as long as not expired or revoked, we will use it to encrypted accounts email to you.
We then email you using new contact details (including encryption key) to confirm, and you have to follow a link. That proves you control the email address and the secret key. Once done the account is updated to use those details from then on. We also email the old details (email and encryption settings) to advise of the change just in case it was not really you!
RevK, thanks, first ISP to use PGP for communication with me (and i work for one) :)
We also allow some controls of emailed content, so text email plus optional PDF and optional XML. You can select PGP/MIME or not (i.e. just signing and encrypting the main body). You can even select if we include a confirmation link in the email or not.
The next step is to cover two main areas - call recordings and KCIs. KCI is Keeping Customer Informed and relates to all the texts/tweets/emails from the control pages. It will take some time to get everything on the control pages moved to KCI.
The principle is likely to the the same - load a key and we will use it.
I think this is an important step for privacy for customers.
P.S. We have had options for a long time on what is emailed, e.g. no itemised bill and no link to get it embedded in the email. This is extra protection to protect the entire contents of the emails. We may add extra layers to protect subjects in due course.
It looks as though Google is, right now at least, enthusiastic about trying to popularise S/MIME. Unlike PGP the S/MIME world has centralised authority, so on the upside you can know the correct key based on the customer's email address. On the downside obviously in normal cases the key is being made by somebody else (the customer probably isn't tech savvy), and both the central authority and whoever is minting the keys people are using can trivially impersonate the customer.
ReplyDeleteSo S/MIME doesn't quite offer that secret agent, "I can't tell you my name or they'll get me" type security some of your customers might care about, but if Google stays enthusiastic it actually will be used by millions of people rather than hundreds and it's a big improvement over "Eh, it's not encrypted it's email".