Simple Libravatar service

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.

and in my root dir for that one I have source/ and avatar/

In source, I have default.png which I’m serving and a series of avatars for various email addresses

and then I have a simple script to generate the right file names:

and the last piece of magic to get everything to work:

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?

8 comments on “Simple Libravatar service
  1. Anonymous says:

    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.

    • sune says:

      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?

      • Manu says:

        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.

    • Jonathan says:

      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.

  2. Anonymous says:

    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*.

    • Sune Vuorela says:

      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.

  3. 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.

  4. Bob says:

    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

1 Pings/Trackbacks for "Simple Libravatar service"
  1. […] some time, Weblate was showing avatars for users. Just as I’ve discovered Libravatar – free and federated alternative to Gravatar, I thought it would be better […]