.well-known/avatar | Hacker News Reader

.well-known/avatar

shkspr.mobi

43 pointsllimllib39 comments

> - No this isn't like WebFinger. That only returns JSON.

Couldn't it be done with WebFinger though?

  {
    "links" : [
       {
         "rel" : "http://webfinger.shkspr.mobi/rel/avatar",
         "href" : "https://cdn.ojford.com/images/avatar.png"
       }
     ],
    // ...
  }

Was going to comment this. Definitely should just be done with webfinger instead of creating a new .well-known.

This seems like a boon to credential stuffing attacks. Given a list of passwords and email addresses, having a well known, email keyed URL would allow an attacker to quickly find if any of the emails have an account on the service, before going through the better secured and more time consuming login page.

That's a reasonable point. I wonder if returning a default avatar rather than a 404 would be a reasonable deterrent?

Wouldn't they just check for the default avatar then?

Twitter used to have a series of different coloured "Egg" avatars for new users.

But, yes, this might be useful in enumeration attacks - but so is something like WebFinger.

Good points to consider. Thanks!

I'm not sure why this would need to be its own well-known url instead of just a WebFinger resource, considering it's nearly identical to WebFinger already. Would just have to always return a link to an image instead the image itself (or a base64 blob of image data in a property, I guess) regardless of image/* being in the Accept header.

My thinking was that it is one less HTTP request. Rather than call the WebFinger, process it, then call the avatar - this is a one-and-done request for the image itself.

That's true. It doesn't really simplify the server implementation, because you still need to basically re-implement WebFinger for clients that don't accept image/*, but it makes it possible to implement a really simple client that just makes a simple GET for an image resource and either gets it or doesn't, without needing to implement any client logic for WebFinger. I don't think there's really any performance benefit to "one less HTTP request" since you still only even get that case if the client accepts a direct image AND the image is served directly in response to the well known query (instead of serving a redirect to a file store or something where the image really lives), but it might be nice if WebFinger had a method of providing "shortcuts" to resources so this was possible without implementing a new WebFinger-like protocol on a new well-known url.

I might just be getting curmudgeonly in middle age, but I don't like this. I want it to be harder for services to share information about me. My address and phone number are also "public" but that doesn't mean I want every site to keep a copy of them.

The nice thing about this is that it is optional. I am not the Internet Police; I can't force you to adopt this.

But, take for example your Keybase URl https://keybase.io/kej - why can't all the services that you've linked to from it pull in your avatar from there as well as your public key?

You could use this in style, and return this image: https://www.safetysign.com/products/9050/get-off-my-lawn-sig...

Google+ was a boon for finding people by their phone number. So is to this day, to some extent, facebook. Add a number to your contacts and the social network will helpfully fill in the blanks.

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

"Faff around" meaning, like, probably four or so clicks?

Four more than I want!

It's the same argument for social sign in. Most people can't be bothered with the faff of typing in an email address and password, then clicking on their email to verify, then adding their name.

So they click "Sign in with Facebook / Twitter / GitHub".

I am a bit surprised the proposal doesn't suggest using a hash (such as SHA-2) rather than directly passing the email address.

You'd have to also specify a normalization procedure to make sure that email addresses are provided in the same format each time.

For anyone who thinks that may be a hand wave, there isn't a standard way to normalize email addresses. If you're building to the spec, then the local part can be processed case-sensitively, so Django lowercases the part after @ only. Others strip out stuff like gmail's +tags and really get into the weeds of how different email providers process emails.

https://pypi.org/project/email-normalize/

https://stackoverflow.com/questions/9807909/are-email-addres...

In my mind, the "Right Thing to Do" would be to follow the precident established by OpenPGP's `.well-known` email-hashing in Web Key Directory (not the prefix of course, and barring technical arguments justifying deviation, which may be considered on merit).

> https://example.org/.well-known/openpgpkey/hu/XXXX

> SHA-1 hashed and z-Base-32 encoded [to distinguish it from a fingerprint]

> The local part is always lower-cased before the encoding. [...] A common example for case-insensitivity are visiting cards which capitalize the canonical lowercase mail address for easier reading.

https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept

They're aware of it, at least. They mention this is how Gravatar works.

That's a reasonable point. I was just modelling on how WebFinger works. A sufficiently secure hash might be sensible.

One idea to consider. Make it easier to implement by changing the query syntax.

Instead of a query parameter, which always requires a script to process:

example.com/.well-known/avatar?resource=acct:username@example.com

Make the requested email address part of the path:

example.com/.well-known/avatar/username@example.com

People can put images into their HTTP server directory named as email addresses. This makes it easier to implement for vanity domains. No server-side code necessary. It still allows someone to build a dynamic script that handles the "/.well-known/avatar/" path.

The dynamic aspect seems weird to be for a well-known. Are there other well-knows that are similarly dynamic?

Yeah I'm not sure that the content negotiation would work very well if you're using a plain webserver or storage service to serve static content.

It seems pretty based on WebFinger, which is such an example.

openid-configuration is semi dynamic, the certificate can change

Go register it with IANA Well-Known URIs. I don't think IANA demands you have it all figured out to do so! Good idea! https://www.iana.org/assignments/well-known-uris/well-known-...

That's a good idea - thanks!

It just occurred to me that Gravatar data is owned by the same folks who decided on selling Tumblr data for AI training: https://www.theverge.com/2024/2/27/24084884/tumblr-midjourne... …

While I don't know enough about the nuances to weigh in on this specific proposal, decentralized solutions are going to become increasingly important!

I like this idea, but would want my email provider (Fastmail, in this case) to offer configuring and serving the well known info. If I move providers, this config should be exportable as part of the bundle to migrate.

Gravatar was interesting to proof of concept the idea, but it should not be a centralized service, it should be a protocol or protocol extension. Conversely, I am unsure if a directory service specifically for this is needed (versus leaning on existing open and established systems), but I could be wrong.

gravatar is already quite creepy - it's not uncommon for random websites to show a gravatar icon, in public, for a user, without prompting, thus exposing your real identity without permission purely because you didn't use a throwaway email address.

WebFinger sounds like it's a cyber proctology exam.

Honestly, I like it. I'll happily build this into Known.

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

lol. who needs privacy or the ability to have disconnected identities online? right?

terrible idea.

So, the nice thing is, this is optional. If you want to sign in with Twitter for everything - go ahead! If you want to create a new cloaked email for everything - you still can.

Just like you advertise your website on your GitHub and your HN profile, I want to make it easy to show my photo on sites that I choose to use. What's wrong with that?

this isn't just letting people use their twitter pic everywhere, it's allowing twitter (and whoever else) to query their email server for an image to represent the user.

services shouldn't leak user email addresses or that those users use that service.

users shouldn't have to juggle different email addresses to maintain distinct identities on different services.

with gravitar, the user is opting into losing pseudonymity, seeing as it's pretty trivial to take lists of email addresses you want to hunt down, md5 them, and then check them against places that user gravitar comments to identify comments are made by someone specific )

with this suggestion, every user on every email server that supports it, which would likely include all the common large ones if the author had their way, would fall afoul of constant identity leakage across every service they use.

an adversary need only crawl different services and hash the user avatars, spam email servers with requests for addresses dropped in leaks or otherwise available publicly, and match them up to remove privacy from the internet

I don't understand how this opt-in email tied service which you or your email provider has to implement is in any way preventing you from having disconnected identities online.

If you own a domain and your disconnected identities are all tied to the same domain (or email address) then you have exactly the same issue.

this leaks the identity through the services. you can't normally get an email address or verify who someone on twitter or whatever is unless the user specifically chooses to share it.

you could use this to query the email server, and to crawl various services to match up identities across them.

most users do not own their own domains, and this would have to be implemented on the major free email providers to be useful, offering up every user on them for casual identification via any service that displays their image

But ... the email provider can't force you to give them a picture of you. I mean... unless they force you to give them _a picture_ and then do verification to check that it's you. Which is never going to happen.

Reply on news.ycombinator.com