Add Libravatar support (Federated Libre Avatar)

[strk]

It would be nice to have the option, as a user, to serve a self-controlled avatar. This ticket is to provide Libravatar support, in addition to (or in place of) the current gravatar support.

There's a Ruby gem for that: https://rubygems.org/gems/libravatar

More info on http://www.libravatar.org

[simonpoole]

At least on first glance this has (at least) nearly all the privacy issues gravatar has, as a consequence adding more such stuff doesn't make sense before https://github.com/openstreetmap/openstreetmap-website/pull/1036 or something similar has been merged.

[strk]

It actually changes the privacy issue (which if I've understood correctly is about giving the has of your email address to a foreign service).

The issue is changed by the fact that you are in control of who will get the has of your email address (assuming you control your email address domain configuration). For my case (for example) the hash of my email would be sent to my own website, and only there (by services supporting libravatar protocol).

Beside, the libravatar API allows to use SHA256 rather than MD5. That may also help (although it would disable compatibility with gravatar.com)

[tomhughes]

Isn't there already a ticket for libreavatar anyway?

[tomhughes]

Hmm can't find one though I'm sure it's come up.

[strk]

Maybe you have in mind this comment: https://github.com/openstreetmap/openstreetmap-website/pull/519#issuecomment-27815045

[strk]

About salted hashes support: https://bugs.launchpad.net/libravatar/+bug/1248456

[tomhughes]

Is that supposed to be be useful in some way? It appears to describe an idea somebody had that has never been implemented...

Ironically while it could work with gravatar it's hard to see how it could work with libravatar given that the salt would have to shared with every possible server, which kind of defeats the whole idea of supporting a federated model, as seems to have been acknowledged in the bug.

[strk]

Was supposed to be useful as a reference, not as a solution for the privacy issue.

So to recap: I confirm using libravatar would still pose the same privacy issues as the gravatar.

That said, I'd still like to be able to choose to serve my own avatar myself.

[strk]

From https://github.com/openstreetmap/openstreetmap-website/pull/519#issuecomment-223545719: the ruby gen does not support a cache, so it would need to be implemented externally (or contributed to the gem code)

[simonpoole]

@strk the problem is that you are generating a unique public id for every user (including such that don't even have a gravatar of any kind) used over multiple sites. There is absolutely no need to try and discover the actual e-mail address when you already have essentially all functionality you could want as your faviourite org with black helicopters. Making the hash more secure doesn't change that a jota.

PS: not to mention that the org with black helicopters likely already has the e-mail addresses of the people they are interested in, gravatar et al simply give them an extremely easy way of tracking their suspects,

[vincentdephily]

The privacy advantage of libravatar is that osm.org could serve the images itself instead of serving a hash that the browser uses to query gravatar.com for the image. Osm.org can do that either by fetching the image itself and caching the results (which is AFAIR forbiden by the gravatar TOS) or by runing its own federated libravatar erver. Neat, but a lot of work.

[simonpoole]

An awful lot of work when the user in question could simply upload it as their user picture.

[strk]

For a user is a lot of work to upload the avatar to each and every service used. And update it when she sees fit.

Federated avatars allow users to centralize management of their avatar so to update it only once.

This ticket is for adding federated (libre) avatar support, not to resolve the privacy issue (which has its own ticket).

[ofalk]

Hi!

As the new lead developer of libravatar, I'd love to see this feature implemented. We take privacy very serious and I'm open to discuss this any time. Either here, or in IRC (Freenode, #libravatar channel). It goes so far, that we do not use any external JS. All requests are served directly by our service. Please let me add that the new version of libravatar, that we launched recently, does support proxying requests to to Gravatar, if no local hash is found. Note: It only sends the hash over to Gravatar, without revealing the origin, in other words, it doesn't redirect, but instead really proxies the request.

[mmd-osm]

By the way, the proposed gem is now unmaintained since about 8 years: https://rubygems.org/gems/libravatar and https://github.com/gugod/libravatar , and there's very little activity and no real users of the lib.

I've never seen this service before, and by looking at some discussion over at HN, I came across 6 posts but no comments whatsoever. This seems all very niche to me. Closing for now.

[strk]

the proposed gem is now unmaintained since about 8 years

@ofalk do know about the state of those Ruby libraries ? Or, given the privacy concern, does it need to be Ruby at all ? I guess the current gravatar code in openstreetmap cold be tweaked to query a different server (rather than gravatar.com) and have this server do the DNS lookup.

This seems all very niche to me

So is openstreetmap... I hope you won't dismiss OpenID-2.0 authentication, which I still use successfully for logging in, as that comes from another niche

[ofalk]

@strk I'm sorry, I have no idea about the Ruby libs - I'm mostly using Python and the Ruby libs are a community contribution from @gugod - maybe it's worth pinging them. At least other repos from them are active.

Overall, API-wise Libravatar didn't change the last decade, only in the backend and additional functionality like transparent proxying to Gravatar to provide more privacy for our users and act as a drop-in replacement were added.

However, if the Ruby lib was developed ages ago, I can imagine it's now problematic with the latest Ruby versions.