Serve icons from i.dreamwidth.org subdomain

[azurelunatic]

Title:
Serve icons from i.dreamwidth.org subdomain

Area:
icons, security, making things make sense

Summary:
Start serving icons from i.dreamwidth.org (or another reserved subdomain) instead of www.dreamwidth.org/userpic/.

Description:
"Userpic" is being phased out, and "icon" is being adopted (though it will probably take years for some of us to get used to it).

felicity_ in IRC pointed out that there are security reasons to prefer images being served from their own subdomain.

Dreamwidth has thoughtfully reserved single-letter subdomains, and in any case 'icons' is a community in active use, and 'icon' is a community as well (albeit private and unused by its creator). 'i' is a shorter subdomain in any case.

On the face of it it seems like making the change and going forward with it is probably a very good thing.

It would disrupt legacy links that people have made in the past to their icons (though service is in beta, luggage may shift during flight) unless backwards compatibility is put in. I don't know whether the security implications of user images served off the main domain applies if there's a redirect from the main domain to a subdomain.

Poll #5520 Serve icons from i.dreamwidth.org subdomain

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
20 (38.5%)

Should be implemented with changes. (please comment)
3 (5.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
28 (53.8%)

(Other: please comment)
1 (1.9%)

Comments

[pseudomonas]

Can you give a synopsis of the security concerns?

[matgb]

Seconded, I have no opinion and honestly don't care. Removing 'userpics' from the URL makes a lot of sense, but not if it's a PITA.

A part of me thinks they should be served from each journal subdomain anyway, my content afterall, so matgb.dreamwidth.org/icons/ICONIDSTRING would work for me.

[faithofone]

I too would be interested in learning why this is a security concern.

[daweaver]

Disclaimer: I am not staff, not support, nothing but a customer.

Security through obscurity never did anyone any good, and I find it a trifle worrying that Dreamwidth is not being tremendously transparent on this matter.

As best I understand it, the security concern involves cookies. Fetching data from a /userpics/ directory requires the domain cookie to be transmitted for each picture, increasing the risk of it being compromised. Fetching data from a specific iconography subdomain would only jeopardise the cookie for that icon subdomain. As these are freely-available pictures, cookies can quite reasonably be done away with.

It is likely that this approach could also offer marginal speed gains; these alone may not outweigh the cost of migration. Re-writing the source code to abolish cookies entirely may be an unreasonably large task for this suggestion.

Again, the above is what I think is the most likely security concern. This summary may be completely and utterly inaccurate.

[azurelunatic]

I possibly could have a month ago. On this one, I was being the designated "hey, you, write this up for dw_suggestions person in IRC. I cannot recall whether the specific concern we were talking about at the time was cookie-related as daweaver mentions, or the thing that I don't fully understand involving weird shit in IE.

[foxfirefey]

There is actually a bug for this already that's a bit more hidden than usual bugs due to the security concerns.

[azurelunatic]

Aha, excellent.

[andrewducker]

I guess that one of the advantages of moving them to their own subdomain is that you could then use a CDN to distribute them rather than having them served by your own servers.

[cesy]

I would really appreciate if the old links don't break.

[msilverstar]

this.

[marahmarie]

This, partly, and "security concerns" also inspired my "implement with changes". I don't know exactly what the security concerns are, either, only that there might be ways in through the pics themselves, possibly - or maybe not - ... and just out of curiosity, if s.dreamwidth.org is not serving icons (which I thought it was) then what exactly is it serving? It's by far the slowest loading sub-domain on Dreamwidth (to the point that I'm tempted to block it on days I'm on a slow connection just to load pages more quickly).