So, since recently bugs.debian.org has started using libravatar avatars. Not yet the federated service, but that’s supposedly in the works. But for that, one of course need to run each own service. Which I wanted to do. In a simple way.
So I did it.
1 |
_avatars._tcp.pusling.com. 43200 IN SRV 10 10 80 static.pusling.com. |
and in my root dir for that one I have source/ and avatar/
1 2 |
$ ls avatar source |
In source, I have default.png which I’m serving and a series of avatars for various email addresses
1 2 |
$ ls source/ debian@pusling.com default.png |
and then I have a simple script to generate the right file names:
1 2 3 4 5 6 7 |
#! /bin/sh (cd avatar; ls | while read file ; do [ -L $file ] && rm $file ; done ) for i in source/*@* ; do ln -s ../$i avatar/$(echo -n $(basename $i) | sha256sum | sed 's/-//') ; done for i in source/*@* ; do ln -s ../$i avatar/$(echo -n $(basename $i) | md5sum | sed 's/-//') ; done |
and the last piece of magic to get everything to work:
1 2 3 4 5 6 7 |
$ cat avatar/.htaccess ErrorDocument 404 "/source/default.png" ForceType image/png <Files "index.html"> ForceType text/html </Files> |
and a set of index.html files created with ‘touch’.
So there you go. A simple libravatar service, ignoring some pieces of the spec, but it should be good enough for most people. I might save my rants about the libravatar spec for another day. But it involves implementing a complete redirecting service and scaling of images.
When will debian.org and kde.org start providing avatar services?
Hmmm. One problem with libravatar if it takes off: it would seem to make it trivial to seek out working email addresses to spam. At a minimum, you should not have indexing turned on, but even then this allows email address verification.
Do you really think that spammers are going to use a service like libravatar to figure out if a email might be valid and then send to it, rather than just sending and figuring out that way if the email might be valid?
I kind of agree that if the service becomes popular, like Gravatar, then it can be used to figure out email addresses (and other infos). Exposing user’s email hash can be a problem.
I wrote a post about it here: http://manurevah.com/blah/en/blog/Implementing-Gravatar-Properly
In short, having email md5 hashes can be useful information.
As an example, I hashed a friend’s email and found a few of his comments on various websites that used Gravatar. He had posted using a different name on each site, yet the hash linked them undeniably.
From what I get the issues are the same with Libravatar. The easy fix is for websites to query Libravatar directly and act as a proxy (with or without cache) for their visitors.
Modern spam filters work best when they receive a lot of data – especially obvious spam. Therefore there’s no point in hiding your email addresses any more, at least if you’ve got a half-decent filter set up.
Verified-valid email addresses have higher monetary value to spammers than random email addresses that may or may not work. Any approach that allows a spammer to filter their list lets them make more money selling that list or sending spam. I’d find it surprising if spammers don’t already use gravatar to validate individual email addresses, so using libravatar seems trivial; I’d just suggest not allowing indexing of the email addresses on a domain because that makes mass scraping so much more trivial and gravatar didn’t allow *that*.
Not allowing indexing is trivial and kind of left as an exercise to the reader. I just did touch index.html in a couple of directories.
In my mind, the redirection policy should be mostly up to the domain owner. For example, a company could choose to always serve their logo when a client asks for a non-existent hash, and not implement any redirection (e.g. to Gravatar) at all.
Instead of “ls | while read file” which isn’t safe for files containing whitespace use the shell itself. And quote your variables! This is safer.
for file in *; do test -L “$file” && rm -f “$file” ; done