Don't hotlink userinfo images

[zaluzianskya]

Title:
Don't hotlink userinfo images

Area:
external linking

Summary:
So you know that nifty trick you can do where you type <user name=example site=examplesite.com> and the username that shows up will be styled for examplesite.com, with the link going to example.examplesite.com and with examplesite.com's profile userhead coming up? Well, when you do that, the userheads are all hotlinked.

Description:
Except for Livejournal's, anyway. I tested this with all of the example journal sites I could think of, and for all of the ones that I tried, the profile images were hotlinked from that site's server, instead of being stored locally like LJ's is at http://s.dreamwidth.org/img/external/lj-userinfo.gif

Check the image sources for these images and you will see:

announcements
news
news (this userhead is the same as LJ's, but being pulled from Journalfen's server)
new_shit

So... basically my suggestion is to store them all locally. (As a side benefit, this would allow users to customize how different sites' userheads show up in their styles!)

Poll #4508 Don't hotlink userinfo images

Open to: Registered Users, detailed results viewable to: All, participants: 50

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
15 (30.0%)

Should be implemented with changes. (please comment)
4 (8.0%)

Shouldn't be implemented.
13 (26.0%)

(I have no opinion)
18 (36.0%)

(Other: please comment)
0 (0.0%)

Comments

[exor674]

I was gonna say no, but I'm saying instead:

Sorta no, but if caching wouldn't add too much load on our end, cache, otherwise lets just hotlink -- hopefully they're at most 1k.

Having our own copy means potentially copyright issues ( "this is our userhead, why is it hosted on your site?!?!?!?" ), we'd have to keep up with icons changing for the site ( Yeah, changing can be bad too but then we'd have people going "uh, why is DW using <old icon> for AO3, they changed that MONTHS ago" ), etc...

[kyrielle]

+1 - pulling it into the cache and refreshing on a reasonable basis (not sure what that would be) seems like the best approach unless it presents significant problems to do. Mostly for the "doesn't die when the remote site is down" aspect.

Of course, that would create a lag (of, at a maximum, whatever length of time was a 'reasonable basis') between changes to a remote site's user icons and the update appearing on Dreamwidth.