further improvement ideas for the API

[Christoph Anton Mitterer]

Hi.

This is again all about the API (http://wiki.libravatar.org/api/), which, AFAIKU, is kind of the standard definition of the "avatars" service (btw: great that you've registered it at IANA).

1) IMHO it could eventually become problematic, that the access URL doesn't contain the digest type, i.e. it's just
http://cdn.libravatar.org/avatar/40f8d096a3777232204cb3f796c577b7?s=100
and not
http://cdn.libravatar.org/avatar/md5:40f8d096a3777232204cb3f796c577b7?s=100
or e.g.
http://cdn.libravatar.org/avatar/40f8d096a3777232204cb3f796c577b7?md=MD5&s=100
or something like that.

Even though it seems unlikely right now, one might in some future distant want to change the hash algo, probably less because of security per se, but rather as MD5/SHA256 might no longer be widespread...
And the size of the hash alone is not enough to tell the type... future ones will also use the "common lengths".

2) The API should specify, that DNS SRV resolution MUST be performed (first!!).
I see the point why you handle http://cdn.libravatar.org/avatar/ special, but I would make this purely optional - for the sake of an open and independant standard.

3) The standard says nothing about whether both, MD5 and SHA256 must be in place on the server, or whether (and in which order) clients would need to try.

4) I would add that client's are allowed to directly access the "real" filenames i.e. "<email address hidden>?s=xxx

5) It should be specified, that HTTP content negotiation is "allowed" to be used...
e.g. http://cdn.libravatar.org/avatar/40f8d096a3777232204cb3f796c577b7?md=MD5&s=100
could lead to either a PNG, JPEG or SVG file, depending on what the client preferred.

6) I would add a "servers SHOULD provide the images at least as PNG files",... to have a common subset

7) the s= parameter should be clarified as follows:
A client can express a "wish" that he wan'ts a file sized xxx...
If the server has it,... he should return it,... if not, he should return the next larger version.
so far this is nothing new.. but:
It's mandartory for the client (library/etc.) to resize the image to desired size, if it doesn't have that already.
Cause the users of the libraries, need to be sure that the size is what they wished (or otherwise their layout might get broken).

8) I'd further add a note, that the current size limit might be changed later on.

9) IMHO it's a deficiency that only square images are supported.

All this would be nice in an RFC ;-)

Cheers,
Chris.

btw: Allowing vectorised images, of course adds the problematic, that the s= parameter is kinda useless... so one would have to think about this.

[François Marier (fmarier)]

> This is again all about the API (http://wiki.libravatar.org/api/), which, AFAIKU, is kind of the standard
> definition of the "avatars" service

Tha'ts indeed the main place, though we have started a spec outline here:

  https://libravatar.etherpad.catalyst.net.nz/draft-spec

after a discussion on the mailing list.

> 1) IMHO it could eventually become problematic, that the access URL doesn't contain the digest type

Good point. Let's track this in bug #1162617.

> 2) The API should specify, that DNS SRV resolution MUST be performed (first!!).

I've just changed the "should" to a "must" on the API page of the wiki. Did you have anything else in mind in terms of tweaking how this part is phrased?

> 3) The standard says nothing about whether both, MD5 and SHA256 must be in place on the server, or
> whether (and in which order) clients would need to try.

I've just added this to the draft spec.

> 4) I would add that client's are allowed to directly access the "real" filenames i.e. "<email address hidden>?s=xxx

I don't understand what you mean by that.

> 5) It should be specified, that HTTP content negotiation is "allowed" to be used...

Good point. I've added it to a new "Image formats" section of the draft spec.

> 6) I would add a "servers SHOULD provide the images at least as PNG files",... to have a common subset

Are you sure that's necessary? The alternative would be to leave it up to the server to negotiate the right format with the client.

> 7) the s= parameter should be clarified as follows
> 8) I'd further add a note, that the current size limit might be changed later on.

Most of these were clarified on the mailing list and are already in the draft spec, but I've added your point about non-browser clients needing to resize the image themselves.

> 9) IMHO it's a deficiency that only square images are supported.

The reason why it's like that in Libravatar is for compatibility with Gravatar. I suspect that the reason why Gravatar chose to require square images is to enable sites to specify image width and height. If width != height, then you have no way of setting these attributes automatically in the browser and that can cause a lot of unnecessary reflows.

> All this would be nice in an RFC ;-)

I agree :) If you want to help (or lead that effort), feel free to join the mailing list:

  https://launchpad.net/~libravatar-fans

Cheers,
Francois

[Christoph Anton Mitterer (calestyo)]

Hi François.

On Mon, 2013-04-01 at 00:18 +0000, François Marier wrote:
> https://libravatar.etherpad.catalyst.net.nz/draft-spec
I see.

> > 2) The API should specify, that DNS SRV resolution MUST be performed
> (first!!).
> I've just changed the "should" to a "must" on the API page of the wiki.
That's not yet part of draft-spec, is it?

> Did you have anything else in mind in terms of tweaking how this part is
> phrased?
Well no,.. not really... important IMHO is:
that it MUST query the DNS SRV RRs first... and only if neither(!) an
avatars nor avatars-sec entry (i.e. none of the two) it should be
allowed to query "well known" providers.

The thing with the "well known" providers (like
http://cdn.libravatar.org) is of course that,... that it makes the whole
(r)avatars idea less like a neutral internet standard.
So from a standardisation point of view, it would be best if there is no
special handling of "well known" providers at all,... and those would
only queried if specified as an DNS RR by the domain.
On the other hand I see of course, that this would exclude many users
(at least all those, not owning their domain, like gmail, etc.).

Question also arises,... could one add the possibility to have other
such well known providers... and how could one standardise that?

> > 4) I would add that client's are allowed to directly access the "real"
> filenames i.e. "<email address hidden>?s=xxx
>
> I don't understand what you mean by that.
as far as I understood the idea was the following:
1) you have a mail e.g. <email address hidden>
2) you look up the avatars[-sec] DNS RRs from example.com
3) you contact the server specified there for
http://whatever.org/avatar/<hashOf(<email address hidden>)>?...

Right?

I see no reason why one shouldn't explicitly allow to access the
non-hashed file, e.g.
http://<email address hidden>?...

May save some hashing cycles... and especially when https is used,.. no
privacy issue should arise.

btw: you think it could ever become a problem that we assume
the /avatar/ path on the server... and wouldn't it be better to
use /avatars/ (with s) as the service name is?

> > 6) I would add a "servers SHOULD provide the images at least as PNG
> files",... to have a common subset
>
> Are you sure that's necessary? The alternative would be to leave it up
> to the server to negotiate the right format with the client.
Well I only said we should use "SHOULD" not "MUST".
In other standards (e.g. OpenPGP) it turned out to be helpful having a
common base set of algos that is expected to just be supported by anyone
conforming.
Of course negotiation works,... but that doesn't prevent a server or
client to choose to support only awkward formats like .pcx or .bmp.

A SHOULD in an RFC like standard is a good way to tell implementors...
do this or you'll run into problems

> > 7) the s= parameter should be clarified as follows
> > 8) I'd further add a note, that the current size limit might be changed later on.
>
> Most of these were clarified on the mailing list and are already in the
> draft spec, but I've added your point about non-browser clients needing
> to resize the image themselves.
I think that also applies to browsers... a...

[François Marier (fmarier)]

> > I've just changed the "should" to a "must" on the API page of the wiki.
>That's not yet part of draft-spec, is it?

I've just added a note to the draft-spec too. Good catch.

> Question also arises,... could one add the possibility to have other
> such well known providers... and how could one standardise that?

That's an excellent question. I haven't personally seen a good pattern for a distributed system with a centralized fallback that's not unique. Perhaps you have examples of ones I've missed?

> I see no reason why one shouldn't explicitly allow to access the
> non-hashed file, e.g.
> http://<email address hidden>?...
>
> May save some hashing cycles... and especially when https is used,.. no
> privacy issue should arise.

If you're looking at a list of people who posted a comment on someone's blog and are able to see all of their email addresses, then I would say that's a privacy leak.

> btw: you think it could ever become a problem that we assume
> the /avatar/ path on the server... and wouldn't it be better to
> use /avatars/ (with s) as the service name is?

We went with /avatar/ to match the path that Gravatar uses. It's not a great reason, but at the same time, I can't really think of a use case where it might be a big problem...

[François Marier (fmarier)]

I think all of the suggestions included in here are now part of the draft spec and/or API page so I'll close this bug.

Please feel free to suggest more improvements though if you see anything else we're doing wrong.