[messaging] Hashing entries in a transparency log

[Tim Bray]

If the content is end-to-end encrypted and the metadata is also not known
to the ESP, anti-spam becomes very difficult.  If the metadata is known,
this allows use of the very powerful report-spam button in the client.

I’m not inside spam-fighting circles, but the correlation between the
arrival of the report-spam button and the decline of spam in my own stream
to tolerable levels was pretty clear.  I’m thinking that an interim level
of privacy where we have encrypted payload, with the disadvantage of clear
metadata and the advantage of good spam control, might still be be an
improvement over where we are today.


On Thu, Sep 4, 2014 at 9:49 AM, Mike Hearn <mike at plan99.net> wrote:

> True. This is probably due to a number of factors (including not enough
>> per user data)
>
>
> Email addresses are free whereas domains are not. If you allow an attacker
> to insert arbitrary keys into your database then you can very quickly run
> out of resources. Spammers are a tricky lot ....
>
> With respect to your last comment -  the problem is, protecting metadata
> is valuable too. Maybe just as valuable as the content. Gmail is actually
> fairly unique in that it hides origin IP of email sent via the web. This
> metadata scrubbing was very controversial when Gmail first came out and in
> fact quite a lot of people argued it violated the RFCs, that it was the
> wrong thing to do, because it made spam filtering harder.
>
> So this is not a new problem or debate by any means. The email community
> has been playing the tradeoffs between exposing metadata and preserving
> privacy for a long time.
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
>


-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140904/6c8a477f/attachment.html>