Terence Eden. He has a beard and is smiling.
Theme Switcher:

.well-known/avatar

· 31 comments · 400 words · Viewed ~2,159 times

Hot on the heels of a post I wrote 4 years ago, wouldn't it be useful to have a well-known URl for user avatar images?

When I sign up to a web service, I don't want to faff around uploading an image to use as my avatar. I want that service to look at my email address or social-sign-in and automatically pick up my preferred graphic.

Here's how I see it working.

  1. A user signs in to a service with the email address username@example.com
  2. In a similar way to WebFinger, the service makes a request to:
    • example.com/.well-known/avatar?resource=acct:username@example.com
  3. If the request's Accept header has a MIME type of image/*, then the server immediately returns an image.
  4. If the request's Accept header has a MIME type of application/json, then the server can return a WebFinger-style document with "rel":"http://webfinger.net/rel/avatar" and, perhaps, a list of different images, formats, and sizes.

This makes it incredibly simple for people to use the same avatar everywhere.

It also means that if you're designing a service which publicly shows usernames, you can make avatars available without an expensive API call. For example, Twitter could make user's avatars available at: twitter.com/.well-known/avatars?resource=acct:edent

But what about...?

This is a sketch of an idea. I'd like to know if people think it is useful before I take it any further.

I don't think it breaches privacy - a user's image is public on all services anyway.

Users should still be given the option of changing their avatar if they want.

A service shouldn't expose the user's email address - they should proxy the image.

Anything else I should have thought of?

Updates

To stave off some common points raised.

  • No this isn't like Gravatar. That works by being a 3rd party service and using the MD5 of your email address.
  • No this isn't like Libravatar. See above.
  • No this isn't like WebFinger. That only returns JSON.
  • No this isn't like h-card. That requires a server to parse HTML in order to find an image.
  • No this isn't like BIMI. That's expensive and only supports SVG.

Share this post on…

31 thoughts on “.well-known/avatar”

    1. Not really. Gravatar is a 3rd party service which uses an MD5 of your email address. This is designed to be a 1st party service which uses your account's name.

      Reply

  7. @Edent I think the idea is cute, but some human factors might make it a bit risky for some users and (services?):

    • A user may wish to ensure a particular service account cannot be tied to their main online identity. If they sign up to Twitter as @MyUsername and also as @anonymousconfessions with two different email addresses at the same domain, they may be deanonymized if the same unique (or otherwise matchable) image is set on both accounts.

    Reply | Reply to original comment on mastodon.social

  11. @Edent I wonder if giving a well-known url as you sign up is better, then you opt in to using that data rather than anonymous, perhaps even selecting what info you want used, ie perhaps more than just a profile photo.
    I do like that gravatar supports multiple emails though and optional different inages for each, but all under one account. It does expose my email matches another account potentially though, which I may not want to share

    Reply | Reply to original comment on mastodon.social

  12. what about security? when a user uploads a file to your site, you can, and for large-scale platforms, you should have malware detection. using .well-known, users can load bad images on your website.

    Reply

    1. As I said, services should proxy the image. That way they can strip out anything untoward.

      Reply

  13. Ideally something like Libavatar/Gravatar does this piece for you so existing services can just keep working with this new idea implemented.

    Reply

  14. <

    blockquote>"I don't think it breaches privacy"

    <

    blockquote>

    This immediately becomes an issue when someone uses it wrong. It's easy to say services should proxy the image. But some certainly will not and expose email address or other account identifier. Using a secure hash (such as SHA-2) would be a simple change that would improve the privacy greatly.

    Love the idea of using a well known URL for this purpose!

    Reply

  17. I was going to say "but what about the fact that every service has its own size for user icons" and then I re-read this and saw that point 4 says it might, perhaps, have a mode where it returns a list of multiple images/formats/sizes.

    And thinking about that makes me remember LiveJournal, which had the wonderful feature of letting you have multiple icons and the ability to pick one for each post and/or reply; nobody's ever duplicated this and I really miss the layer of meaning it added on top of plain text.

    Reply

    1. Favicons generally only work for a single server. So something like a Mastodon server can't have a favicon for each user.

      With rel=icon, h-cards, and other metadata - you need to download a large chunk of HTML and then parse it. I was going for something simpler.

      Reply

  20. Did you take this any further @edent? With Wordpress (& hence gravatar?) feuding with its own ecosystem it seems prudent to revisit!

    I’m a little cautious about using plain text to lookup the email, as it exposes all your email addresses by inspection of a static site’s code (or if a site that uses this mechanism doesn’t proxy, so exposes your otherwise private signup email).

    Using a hash of the email instead of the email’s local-part to resolve this (à la gravatar) still allows a fairly easy approach to uncovering email addresses (seek hash collisions), but I guess a person could just not use this method if an email address needs to be harder than that to sniff out.

    Reply

  21. @Edent It'd be nice if the query could limit the size of the avatar being returned. If only there were `Accept-Max-Size`, but maybe a query param? I wouldn't want my performance taking a dive if Alice has a 35M avatar that my client starts downloading. If my client had requested with `max_size=3072` I'd rather not see the avatar than degrade performance/pull excess data

    Reply | Reply to original comment on talking.dev

  26. @Edent Thinking about this, while I like content negotiation as a clever hack, I wonder if maybe it isn’t too clever. The nice thing with WKD is that you can deploy it with any normal static HTTP file without any special magic. Maybe the protocol could be dumbed down to simply rely on WKD-style URLs? I’m not sure how to configure my web server (Apache) for your avatar well known URL with negotiation magic.

    Reply | Reply to original comment on fosstodon.org

  27. @blog this is cool! A few notes maybe:

    * Have you considered a more specific mime-type?
    * If the expectation is that images are returned with an Accept header, maybe the JSON format should not include href, because what would the point be of a different absolute URL if you know you can just go to the current one in the first place?
    * Why have have the JSON at all. If a client supports this, they can just set their own Accept: header with an order of preference for image types.

    Reply | Reply to original comment on indieweb.social

What are your reckons?

All comments are moderated and may not be published immediately. Your email address will not be published.

See allowed HTML elements: <a href="" title="">
<abbr title="">
<acronym title="">
<b>
<blockquote cite="">
<br>
<cite>
<code>
<del datetime="">
<em>
<i>
<img src="" alt="" title="" srcset="">
<p>
<pre>
<q cite="">
<s>
<strike>
<strong>

To respond on your own website, write a post which contains a link to this post - then enter the URl of your page here. Learn more about WebMentions.