There is another - and more simplified - version of Google favicons service:

http://s2.googleusercontent.com/s2/favicons?domain_url=

You can also pass a full URL to domain_url parameter, e.g.:

http://s2.googleusercontent.com/s2/favicons?domain_url=http%...

So no need to find the host name, just be sure to encode the URL

It also works with HTTPS connection.

This seems like it would make malicious links easier to seem legitimate. If I see the Google favicon, I might assume it was Google without even checking the URL.

Like on HN when the subdomain isn't given of a site that uses public subdomains. Not sure if this is still true but UGC from Google subdomain pages used to just come up as "google.com" next to the submission.

That's possible today with just <img> <a>, so I'm not sure how this script makes that particular vector easier. It's just cool.

I think the point mrspandex was making is not "this being possible is bad..." but "if this becomes the accepted way to handle web links" is bad. It's not dangerous that this method exists, it would be dangerous if the average user came to experience and accept it as the "standard" for web links. All it takes is users to assume "my address bar which I can rely on is icon + address, therefore icon + address on a web page is safe too!".

Ehhh... I can see the argument, but it seems to me to be precisely on par with that you can put arbitrary text inside a <a> tag. Which means a link which looks like http://www.amazon.com might not actually go there. Some people confuse this, some don't, but many have been 'trained' by spam to check the address on mouse-over.

At least modern browsers don't let the page to cloak the address by setting window.status anymore. IIRC that was quite popular in 1990s.

Fair. I agree with that.

If the page is a spam site, sure. But imagine someone posts a comment with a domain similar to google.com and the Google favicon. It's a legitimate vector.

I don't know how much of an issue this is in practice, but if the Google favicon service only requires the hostname then it will sometimes get the icon wrong. Any individual page can specify its own icon via a link element in the page header. (This is essential when multiple sites share the same host.) Is there any reasonable way to deal with that?

Wouldn't work in an HTTPS site I assume (due to browser warnings over insecure resources...)?

FWIW, the google service mentioned in the article works via https as well. [https://www.google.com/s2/u/0/favicons?domain=css-tricks.com]

I think the best way to handle this would be to remove the scheme from the background url. So it would look like `background: "url(//www.google.com/s2...")`. This would accommodate both schemes.

I'm sure you could run one of these APIs server-side and avoid the warning (which would not work with CSS, but it would be a work-around).

It looks like this service (mentioned in the post) also supports https, although it is a little slow.

http://getfavicon.appspot.com/

Good find. After my previous comment, I've been dwelling on this more, and I think that some kind of server-side retrieving/caching program for these favicons would both speed up the services significantly and allow https. Favicons don't change too often, and most of the use cases I can think of for this (e.g. blogs) would only require a static image. Of course, the caching would provide the major speed increase by avoiding an API call rather than optimizing delivery of the image.

Or a simple JQuery Plugin I developed: https://github.com/dreur/JQuery-Showfavicons-Plugin

It adds the possibility to say which hostnames are internal and external.

I really like the message next to the comment box on this site, makes you think twice about what you are going to say.