Horrible horrible horrible set up!

Firstly, they're preventing browser caching of the images, which means they get reloaded at every single page load. These are the headers I'm getting:

  HTTP/1.x 200 OK
  Cache-Control: private, max-age=0
  Date: Sun, 13 Dec 2009 11:09:59 GMT
  Expires: -1
  Content-Type: text/html; charset=UTF-8
  Server: gws
  Content-Length: 0
  X-XSS-Protection: 0

Note the lack of E-Tags too.

Also, why hotlink from another domain that will need another DNS lookup? Add enough of those and you'll slow down the page load significantly.

Finally, this doesn't seem to be a CDN so it's unlikely users around the world will actually see fast download times from this single server.

Thanks for the comments.

I'm not seeing the same headers as you on the images. Were you talking about the HTML pages?

    wget -S http://www.stdicon.com/pdf
    --2009-12-14 02:31:48--  http://www.stdicon.com/pdf
    Resolving www.stdicon.com... 74.125.53.121
    Connecting to www.stdicon.com|74.125.53.121|:80... connected.
    HTTP request sent, awaiting response...
      HTTP/1.0 200 OK
      Content-Type: image/png
      Expires: Mon, 21 Dec 2009 10:31:48 GMT
      Cache-Control: max-age=604800
      Date: Mon, 14 Dec 2009 10:31:48 GMT
      Server: Google Frontend
      Content-Length: 11999
      X-XSS-Protection: 0
      Connection: Keep-Alive
    Length: 11999 (12K) [image/png]

Good point on the E-Tag. that will help in the 1 week expiry. I'll add that.

And it is using Googles app-engine as a CDN. Is there better free CDN that you would prefer? You can always use coral cache if you like: http://www.stdicon.com.nyud.net/pdf

I don't think the DNS problem is really a problem but you are welcome to proxy from your own static image domain if you are concerned.

I got the headers by right-clicking on some image links and seeing what I got. Can't reproduce it right now. Apologies if there was a brain freeze moment.

I've been thinking about how to best do this over the weekend and the approach I cam up with is this: Use Cloudfront (Amazon's CDN) and use custom CNAMES for S3 buckets. An S3 bucket would be an image library (say tango.stdicon.com) and so the subdirectories of this Cloudfront subdomain would be the images sizes (tango.stdicon.com/48/foo).

This sets up a nice CDN with proper headers and a scalable way to add more libraries (just add subdomains).

This also has the "very advanced use-case" advantage: website owners can CNAME to the same library subdomain multiple times (say assets1.mysite.com assets2.mysite.com and assets3.mysite.com) and let the browser download images in parallel. See these two refs:

1. http://www.stevesouders.com/blog/2008/03/20/roundup-on-paral...

2. http://www.websiteoptimization.com/speed/tweak/parallel/

Would love to talk more if you're interested. Email address "encoded" in my profile page.

Both good points. We're on it.

They should include the Fam Fam Fam Silk Icon set, still the best and most complete icon set out there.

http://www.famfamfam.com/lab/icons/silk/

Fugue is far larger (http://www.pinvoke.com/) and is aesthetically much more pleasant.

Much more? They look about the same to me. But thanks for the link.

Yes, those two have saturated the web and they are the #1 reason why the "Top N Free Icons" blog articles are written.

My suggestion is to use something else free but a bit more obscure, until you have enough money to get a custom look and feel for your brand.

I looked at those, and they don't map very well to mime types. To actions and nouns they are great, but not very good for file types.

If you can give me a nice mapping of mimetype -> FFF icons I'd love to put them on stdicon.

Yeah, that was one of the original sets I wanted it to support, but I think they were missing some important ones.

Nice application, unfortunately the icon sets IMHO need to be expanded! I also got reservations about hotlinking. Why not download? It will make your pages faster. Even better download and turn them into CSS sprites.

Or the remote lib could return sprite coordinates and dimensions, and serve one composite graphic.

Gravatar is used all over the place and is almost always hotlinked. Download if you want and you know the set of types you need icons for. Otherwise, it's just easier to blindly hotlink.

Gravatar has avators for all its users, which could potentially include everyone online. File types icons are much more limited.

The rank of the first set is in the multi-hundred millions, while the later can be ~50. There is enough room in my /var/www/pub/images for 50 x ~40kB. (my entire disk storage, 300GB, can only hold avatars for 63M people.)

If the user has visited someone else's site, they may have the hotlinked image cached and thus your page will load faster for them.

As pierrfar has shown, they disable any caching, so even if you use the same icon on several pages of your site the browser will have to re-download it every single time. Now all they need is to to log the client IP and client agent string and they have a fairly accurate global clickstreams for all users over all sites that use this service (not to mention what they could do with a cookie).

I'm sure there's no ill intent here, but I don't think it's a good practice to hotlink.

If those running stdicon were so inclined (or if they were hacked), they could easily initiate a massive XSS attack.

With <img> tags? Is that possible?

Yes. http://ha.ckers.org/xss.html

You're building the URL yourself though, e.g http://www.stdicon.com/mp3?size=16.

If you're not escaping, maybe a user could upload a file named "evilfile.<script>alert('evil')</script>", but I'm not sure how stdicon.com could initiate an attack from their end.

Now that I actually try it, I think you're right.

I had assumed that the browser would load the external JavaScript, parse it and execute the code. I understood that the code in the page (the src built by the coder) was not going to be compromised. I should have realized that the browser would treat data loaded through an img src tag differently than it would data loaded through a script src tag.

Some versions of IE can be fooled into executing JavaScript contained in an image file, but the image has to be loaded on its own (in an iframe or a new window), so it wouldn't apply to my original comment. (http://www.splitbrain.org/blog/2007-02/12-internet_explorer_...)

This site does still seem like it could lead to security issues.

Couldn't they return a 302 redirect header to a private resource?

  HTTP/1.1 302 Found
  Location: http://www.yoursite.com/blog/entries/delete/123

Yes, but so could anyplace you hotlink images from. gravitar, imgur, youtube preview...

... but use wisely. excessive visual clutter helps no one.