← Back to team overview

libravatar-fans team mailing list archive

Proposal for proxy API parameter

 

Hello Libravatar fans,

another idea, that came up a few days ago, was the addition of a proxy
parameter to the libravatar CDN requests or general backend of
libravatar. Before everyone yells "Centralization!", let me explain:

The idea is to add a new parameter to the libravatar API. This
parameter should be called `proxy` or short `p`. As value for the
parameter it should contain the domain name of the avatar that is about
to be fetched.

---

How does the new Parameter work? When the parameter is specified, the
libravatar server is supposed to do a regular libravatar domain lookup
(checking the SRV record) for the domain provided in the parameter. 

If there is a SRV record and a working libravatar server provided, the
libravatar server should fetch the avatar over a secure connection for
the given hash and return it to the client. 

The resulting avatar can be cached for at least 24 hours or longer, if
the cache-control header allows so. The cached avatars should only be
used for avatars providing the same proxy value for the proxy
parameter.

If there is no libravatar SRV record set for this domain, the server
should ignore the proxy parameter and continue to handle the request as
usual. If there is a `referer` or `origin` header is send along with
the HTTP request, and the request contains a proxy header, the
libravatar server should return a 403, unless the implementation is
running in some sort of debug mode.

---

Why this API endpoint might be needed? Privacy, Security, Compliance
and Adoption.

Privacy - The new API endpoint would allow clients to fetch avatars
from an upstream server without revealing the IP address to an
untrusted server, like current client implementations require.

Security - Implementations may suffer from bugs like not enforcing
memory limits on requests as well as using insecure connections to
connect to the upstream libravatar providers. Therefore using single
upstream server that runs well-configured HTTPS as well as providing
well-implemented resource restrictions can reduce the risk of attacks
for clients.

Compliance - It allows to keep the restrictions on clients tight by
reducing the amount of connections a clients has to make, if there is a
local libravatar instance. It should also help to become more GDPR
compliant as GDPR considers IP-addresses personal data. By doing
requests to unexpected third-parties without proxying those, we might
cause compliance issues.

Adoption - For many people it's a burden to implement the libravatar
API. I can't tell why, but it might be a lack of interest, proper
library being available or concerns about external URLS. This proxy
parameter could move the implementation of the actual libravatar
protocol from the client-side to the server side.

---

There were a few considerations going into this proposal. First of all,
the question of how to improve adoption. But also how to keep privacy
for all users up as high as possible, when moving the implementation
towards servers.

One of the key problems I notice in adoption of libravatar is the fact
that while we can run federated avatar services, in most applications I
saw only the centralized CDN version of libravatar is implemented. This
defeats the purpose of having a federated service available. Therefore
this proposal tries to allow getting the usage of an own ivatar server
(or other implmenentation) or even the central CDN, while providing the
avatars that are collected from federation. This should make it more
attractive to run your own libravatar service because more services
will display your avatar.

>From a security and privacy perspective it was important to prevent
data leaks to untrusted parties. Starting with the mail address or
OpenID handle itself. Therefore, to prevent usage in web frontends, the
proxy parameter will throw an error when typical web-browser headers
are set. This will hopefully prevent web developers to expose user
domains to external users, who don't already know the user's email
address or OpenID domain. At the same time improving the situation of
exposing user's IP address and user agent to unintended third parties
to reduce the possible tracking vectors.

---

Here I would really enjoy to get some input from you as well. Maybe
some measures are too harsh, maybe there is a gap in the definition of
this parameter. I would love to hear back from you :)

Maybe it's also an overall stupid idea and you can tell me why ;)

No matter how it turns, I'm looking forward to some feedback.

-- 
Signed
Sheogorath

OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt



Follow ups