Openstreetmap-website: Add Libravatar support (Federated Libre Avatar)
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
strk
All 14 comments
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.
simonpoole
on 3 Jun 2016
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)
strk
on 3 Jun 2016
Isn't there already a ticket for libreavatar anyway?
tomhughes
on 3 Jun 2016
Hmm can't find one though I'm sure it's come up.
tomhughes
on 3 Jun 2016
Maybe you have in mind this comment:
https://github.com/openstreetmap/openstreetmap-website/pull/519#issuecomment-27815045
strk
on 3 Jun 2016
About salted hashes support: https://bugs.launchpad.net/libravatar/+bug/1248456
strk
on 3 Jun 2016
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.
tomhughes
on 3 Jun 2016
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
on 3 Jun 2016
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)
strk
on 3 Jun 2016
@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,
simonpoole
on 3 Jun 2016
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.
vincentdephily
on 5 Jan 2017
An awful lot of work when the user in question could simply upload it as their user picture.
simonpoole
on 5 Jan 2017
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).
strk
on 5 Jan 2017
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.
ofalk
on 7 Mar 2019
Related issues
grischard
路
3Comments
kgreenek
路
6Comments
Zverik
路
3Comments
rudolfmayer
路
4Comments
jjiglesiasg
路
8Comments
Most helpful comment
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.