[messaging] Google End-to-End plans on using key directories with a CT-like verification protocol

Mike Hearn mike at plan99.net
Thu Aug 28 13:08:28 PDT 2014

> 3) It creates a potential SPAM problem.

Just re: the spam issues in general (I used to work on the Gmail spam
team), most spam is filtered based on two pieces of metadata:

1) Origin IP reputations
2) Link url domain reputations

This gets you to perhaps 90%+ coverage immediately. There are many other
message features used to filter spam, but those two do the overwhelming
majority of the work. Comparatively little spam is filtered based on raw
text analysis.

The reason is that IP addresses and domain names have a cost to them, and
spammers need a hefty supply to keep campaigns going.

A CT type approach involves that involves publishing public keys to the
world has the obvious problem that spammers can send encrypted emails. I
cannot imagine the gmail spam team ever signing off on a system that would
enable *all* Gmail users to receive unreadable mail immediately.

A system in which to initiate an encrypted conversation requires the
receiver to reply would eliminate that problem almost entirely, as people
would quickly learn to spot fake intro emails and do not reply to spam. But
then you can just embed your public key into the message headers and rely
on DKIM to ensure the key is correct, at which point it becomes mostly a
client engineering problem rather than something requiring large
infrastructure on the provider side.

A possible middle ground is to do a first pass filter based on message
envelope features, then have the users client decrypt the message and
upload any linked URLs for a second pass filtering (or just the domains,
though some advanced filters like Gmail's can sometimes derive value from
the entire URL string). It means the provider learns the outbound links in
the mail, but that may or may not be a big problem for any given

> 3) Make the client notifying the user when a key changes, if the user
> has a key change notification preference set.

I think one good way to do this notification is to tie it to events that
naturally cause key changes, like switching to a new device. If a key
change appears in the message flow as "Bob switched to a Samsung Galaxy S3"
then that leads naturally to the question "why did you just do that Bob. I
didn't know you bought a new phone" for anyone even slightly suspicious
they might be listened in to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140828/ae6dcc8b/attachment.html>

More information about the Messaging mailing list