libravatar-fans team mailing list archive

[Christian Weiske <cweiske@xxxxxxxxxx>]

Hello Sheogorath,



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

I had such a requirement years ago: A libravatar proxy server
that one could use as a drop-in replacement for gravatar.
I ditched that idea because there was no way to determine the upstream
avatar server from the default hash.

You solve that by adding the "p" parameter (I'd call it "d" for
"domain").

You write
> When the parameter is specified, the libravatar server is supposed to
> do a regular libravatar domain lookup

I would not like to see this requirement on "normal" avatar servers
that work fine with a completely static configuration.
This should only be a recommended parameter for avatar image proxy
servers.


I agree with all the points in "why".


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

My original demand was that the avatar proxy server should be
usable by directly linking images from it. But domain exposure is
indeed a problem, and thus would make it unusable for public sites
unfortunately.

But the only other solution to the exposure problem is encrypting the
domain in a way that only the server can decrypt, which would mean that
the server could also get the full email address.

----

Your solution would mean that server-side code would need to do the
request to the avatar proxy, and that the images would go through 2
intermediates until they reach the browser user:

[browser user] --> [application] --> [avatar proxy] --> [example.com]

1. browser requests application web site
2. application returns website with an avatar image URL pointing to the
   application itself.
3. browser renders page and fetches appication avatar image url
4. application fetches image from avatar proxy
5. application sends image back to browser


To cut out the application for image delivery, the avatar proxy could
return a "Location" redirect with the final cached image:

1. application sends avatar request with "d" parameter to proxy
2. proxy responds with "HTTP redirect" response and a Location header
   URL that points to the image at the proxy itself
3. Application sends the proxy image url to browser
4. Browser fetches image from proxy

This is something that would be more performant than the application
tunneling that I understand is needed by your idea.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-=≡ Geeking around in the name of science since 1982 ≡=-