Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes.

There should be a second-stage, preferably device-only, decryption phase.

That is, the entire concept of "identity" is confounded out of a cluster of often only loosely-related concepts. Among them:

1. Who are you?

2. Should I trust you?

3. Did you do X?

4. Is X as you left it?

5. Can you (and ideally you alone) read X?

6. Should I allow you to do X?

7. Do I owe you / you owe me X?

8. Must I pay you (or seek permission) to use/do X?

9. Are you the same X as some other X' (in another place, time, system, ...)?

Accessing the email store (authentication) is not the same as being able to read email (decryption), or being able to say you sent a specific message and that it hasn't been changed (integrity).

Electronic / digital data formats violate many of the trust bases that have formed around material or personal data transfers. Paper, stamps, seals, institutional trust (that, say, the post office isn't opening, reading, and/or censoring mails), etc. It's an entirely different set of physics, if you will.

The rules have changed. Google are playing by the old rules. They are losing, and so are we.



And when your second key is compromised, will it be Google’s fault that they didn’t make you have a third key? Maybe you need a key for Authn and another for Authz and another for decrypting headers and another for decrypting bodies and another if you want to send.


Google needs the auth key or parts of it.

Google does not need the decrypt key.

Separation also reduces phishing risk.


In a model where your decrypt key is sufficient to protect your email, you don't need the auth key.

Also Google does need the decrypt key if you care about things like search or history.


I've considered a no-auth version. My general feeling is that it puts excessive reliance on integrity of the decryption key, but otherwise, yes, that is an option.

Flipped around, if website notifications were encrypted and posts were signed, there'd be little need for website authentication.

Search and history might require initial access to a message but otherwise creaate encrypted indices. Or could be handled fully client-side.


We will have to agree to disagree. I see no value to Gmail users to making them use a secondary key for their mail. If you’re this concerned with security, you won’t be using Gmail because you still have to trust them with all your plaintext at some point.

Not sure what you’re referring to with the website notifications and posts.

Search and history can only be handled client side if you are going to download your entire mailbox, something almost no one does anymore. Initially indexing is theoretically feasible but makes it essentially impossible to ever reindex to fix bugs or improve performance.


There's the option of reducing that exposure to a minimum limited extent. To the extent that this is auditable, verifiable, and based on well-established procedures, it may be an acceptable risk.

This includes encrypting unencrypted messages, after arrival, to the user's own key(s).

Keep in mind that data security consists of numerous elements:

* Access.

* Encryption-in-flight.

* Encryption-at-rest.

* Encryption-to-client.

* Rates of transfer or exfiltration. This has numerous elements, one of which I refer to as the Pennyworth limit. Bruce Wayne has a butler who is privy to Wayne's innermost secrets. But he is not also privy to the secrets of all of Gotham. And even at maximum data transmission rate, can only reveal a few hundred words a minute of information, on the order of a megabyte or so per day (in textual form). Our electronic devices and systems have far more information, in far more detail, on far more people, available at far higher rates, and for the most part, can be tapped with absolutely no awareness by the subject of the information revealed.

* An "entire mailbox" is only a few hundreds of MB or GB, and arrives incrementally. Since reading information client-side requires transmission of that data in any regard, the information is already client-side. There are now microSD devices with capacity approaching or exceeding 1 TB and above. Storage itself is not a limitation.

Unencrypted email can be indexed, the indexes encrypted, and transmitted to the client device.

I'm not saying that the technical considerations here are simple, but the costs of failing to address them, quite literally the future of liberal democracy, are too high to not do so.


> There's the option of reducing that exposure to a minimum limited extent. To the extent that this is auditable, verifiable, and based on well-established procedures, it may be an acceptable risk.

How would it ever be auditable or verifiable? You're talking about secret source code running in private data centers on inaccessible hardware. If you need auditability or verifiability, you cannot rely on GMail or any similar service.

> Our electronic devices and systems have far more information, in far more detail, on far more people, available at far higher rates, and for the most part, can be tapped with absolutely no awareness by the subject of the information revealed.

I'm not dismissive of that concern but I fail to see its relevance to the question of whether Google should add another key to everyone's account. You don't solve this problem by encrypting your mail unless you stop sending your mail through Google. In fact you don't even solve it that way because such a huge chunk of mail you send/receive will flow through Google anyway. You cannot solve the trust problem by adding another unverifiable layer of encryption. If you don't trust Google now, that shouldn't change if they tell you that they started encrypting with your public key at rest.

> An "entire mailbox" is only a few hundreds of MB or GB, and arrives incrementally....Storage itself is not a limitation.

I disagree. I'm using ~10 GB of storage for Gmail. I don't want that space used for mail on my phone. Or my laptop for that matter, which has only ~36GB free at this point. I can't stick an SD card in my phone and if I could I wouldn't because it's slow.

> Unencrypted email can be indexed, the indexes encrypted, and transmitted to the client device.

It really can't. If the index is encrypted, then it can't be updated with new entries. So the best you can do is generate an inverted index per email and send that to the client to combine into a real index. But at that point, don't even bother because the client can probably index each email locally more cheaply than it can stream it from the server.

Given that most people are now using web clients, pushing indexing responsibility onto the client isn't remotely feasible. Imagine you log in from a new browser and GMail tries to push GBs into your localstorage and then your browser churns for hours trying to build the index.

> I'm not saying that the technical considerations here are simple, but the costs of failing to address them, quite literally the future of liberal democracy, are too high to not do so.

I think that's overstating it, mostly because adding a second key does not eliminate the social engineering weakness (maybe it's reduced). But also because I don't think leaked emails constitute the end of democracy.


A thing is made auditable and verifiable by auditing and verifying it.

Google are already under at least one privacy-related consent decree.

https://techliberation.com/2011/03/30/the-ftc’s-google-buzz-...

https://www.ftc.gov/enforcement/cases-proceedings/102-3136/g...


And the same government that wants to tap everything and subpoena email accounts with little cause is going to enforce that Google makes it difficult/impossible to do those things?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: