Modern Anti-Spam and E2E Crypto (2014)
moderncrypto.org
Modern Anti-Spam and E2E Crypto (2014)
1–10 of 49 posts
Re: Modern Anti-Spam and E2E Crypto (2014)
#2Fascinating insight into one of the biggest email operations. I'd be very interested to hear how the other companies in this space differ or are similar.
Question: Is there a curve where pushing this processing back to the phone will become possible? The most powerful counterpoint at the moment is battery life, but I do see that improving to a plausible point where this sort of continual processing is feasible?
Re: Modern Anti-Spam and E2E Crypto (2014)
#3[deleted]
Re: Modern Anti-Spam and E2E Crypto (2014)
#4I think this is an area where functional encryption could help:
https://en.wikipedia.org/wiki/Functional_encryption
This would allow a client to combine a server-provided function that calculates a spam score with their private key such that the resulting function calculates a spam score on encrypted email. The client could then hand that function back to the server so it can perform server-side spam detection.
There are a number of drawbacks, including performance and general questions about the security of such a system. That said, I think this is probably the biggest problem (from the OP):
"The third problem is that spam filters rely quite heavily on security through obscurity, because it works well. Though some features are well known (sending IP, links) there are many others, and those are secret. If calculation was pushed to the client then spammers could see exactly what they had to randomise and the cross-propagation of reputations wouldn't work as well."
Using functional encryption to provide server-side spam detection would still require handing a spam scoring function to the client so they can apply that function to their private key and hand the server a result. This would expose the internals of the spam detection routine to all clients, including spammers.
A difficult tradeoff.
Re: Modern Anti-Spam and E2E Crypto (2014)
#5Perhaps we should put (2014) in the title. I'm sure Gmail has improved a lot in the intervening two years and the information could be outdated.
Re: Modern Anti-Spam and E2E Crypto (2014)
#6Perhaps we should put (2014) in the title. I'm sure Gmail has improved a lot in the intervening two years and the information could be outdated.
This post was also extensively discussed back then. It is a classic but yeah 2014 belongs in the title.
It's interesting that encrypted messaging has exploded since 2014 but spam has not yet become that much of a problem.
Re: Modern Anti-Spam and E2E Crypto (2014)
#7The content in this article about anti-spam techniques is fascinating. But the title should be edited to indicate its vintage: 2014.
Also, by the by, there is some interesting context about the author (Mike Hearn) and his recent activities that are not related to the topic of spam.
Warning: off-topic digression below.
Mike Hearn became one of the most visible Bitcoin core developers, working in that community for 5 years, until a well-publicized departure where he declared Bitcoin a failure[0].
He then joined R3CEV, a startup venture that is building a private blockchain platform for a consortium of 70 of the world's largest banks. Hearn's departure was criticized by members of the cryptocurrency community, such as Bram Cohen, who famously called his exit a "whiny ragequit" [1].
Regardless about how one feels about the internal politics of the bitcoin dev community, the R3 project is technically interesting (to me, at least) because it uses Kotlin [2], a JVM-based functional language, and also because it has some interesting design approaches that depart from the established bitcoin blockchain model [3].
I still think that private blockchain platforms have an uphill battle if they want to compete for developer attention with rapidly evolving broad-based platforms like Ethereum and Bitcoin, but the R3 Corda platform is nevertheless worth tracking.
[0] https://medium.com/@octskyward/the-resolution-of-the-bitcoin...
[1] https://medium.com/@bramcohen/whiny-ragequitting-cab164b1e88
[2] https://twitter.com/hhariri/status/790077263572299780
[3] https://gendal.me/2016/10/25/r3-corda-what-makes-it-differen...
Re: Modern Anti-Spam and E2E Crypto (2014)
#8I like the approach Facebook Messenger takes - I can receive messages from anyone who can view my profile, but first time messages from non-friends end up in a special bucket and require approval.
Re: Modern Anti-Spam and E2E Crypto (2014)
#9I think this is an area where functional encryption could help: https://en.wikipedia.org/wiki/Functional_encryption This would allow a client to combine a server-provided function that calculates a spam score with their private key such that the resulting function calculates a spam score on encrypted email. The client could then hand that function back to the server so it can perform server-side spam detection. There…
The problem with functional encryption is as you say, you need to hand over the "function" somehow to the server (presumably they use machine learning and tools that aren't feasible client-side), and there's no guarantee the private key is hidden unless you use something like indistinguishibility obfuscation, which isn't really practical at all right now.
Did you mean fully homomorphic encryption? (https://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_h...) The server can compute the spam score under the encryption of an email, and client side decrypts and sorts it from there, so not even the server knows if a given email is spam or not. Of course, not that FHE is feasible, but perhaps this special case is...
Re: Modern Anti-Spam and E2E Crypto (2014)
#10I think this is an area where functional encryption could help: https://en.wikipedia.org/wiki/Functional_encryption This would allow a client to combine a server-provided function that calculates a spam score with their private key such that the resulting function calculates a spam score on encrypted email. The client could then hand that function back to the server so it can perform server-side spam detection. There…
Also, in order to build the function, the service needs to collect data about both spam and non-spam emails. So simply providing a function that allows you to calculate a score isn't enough; they would need (at least a large percentage of) users to send back information about their email contents as well. (Like embedded links, as mentioned in the post.)