Inventing Favicon.ico

https://ruthlessray.wordpress.com/2013/09/02/inventing-favicon-ico/

by electrum • 11 years ago

207 64 11 years ago

ruthlessray.wordpress.com

I would love to read more of these delightful early web stories. Does anyone have a collection of them?

johanbrook• 11 years ago

Not entirely web related, but Andy Hertzfeld has collected lots of early Apple stories on http://www.folklore.org/. Really delightful as well.

mmahemoff• 11 years ago

If you're into podcasts, http://www.internethistorypodcast.com/ is doing a very comprehensive effort speaking to original sources about all things early internet.

Also the Reply All podcast has covered various quirky aspects of internet history http://gimletmedia.com/show/reply-all/.

have_humility• 11 years ago

Lots of Mozilla stuff:

http://www.jwz.org (gruntle, doc, hacks, blog; everything)

http://www.mozillamemory.org

http://www.codersatwork.com

UnoriginalGuy• 11 years ago

Honestly even in retrospect favicon was a positive thing with little to no downsides except maybe a single "wasteful" HTTP/s request.

The <link rel="icon" href="./whatever.ico" /> was a further improvement still on the basic concept a year later.

The only concerns I've heard about favicon is:

- They've grown beyond the original use case (e.g. address bar, tabs, drag to desktop/app tray, etc).

- The icon definition hasn't expanded with its new scope, so specifying low, medium, and high definition formats is left up to server hacks (i.e. providing the right one based on the browser user agent string).

- There's no way of in-lining the icon (e.g. for single page applications, appliances, etc).

- Apple now has their own incompatible favicon "apple-touch-icon" which is just a higher resolution favicon.

- They can be used to trick less technical users into believing a HTTP site is a HTTPS one. For example make the favicon a green padlock. This is mostly a browser issue, and may be resolved by marking all HTTP sites as insecure (which some have proposed).

To be honest all of these could be fixed with some subtle changes to the ref="icon" definition to support a quality modifier, and also being able to point at an in-line graphic object for the favicon.

The last point requires us to mark HTTP as insecure. Instead we treat HTTPS CA signed as "secure" and HTTPS self-signed as "insecure" when the reality is that HTTPS self-signed is more secure than plain old HTTP (yes, I know, you can MITM self-signed, but at least it is encrypted).

TazeTSchnitzel3• 11 years ago

The icon definition hasn't expanded with its new scope, so specifying low, medium, and high definition formats is left up to server hacks

Not really. The Windows icon format .ico did "responsive design" before the term was even coined. It supports multiple sizes and bit depths (remember Windows used to have to support everything from 1-bit to 24-bit colour) stored within a single file.

There's no way of in-lining the icon (e.g. for single page applications, appliances, etc).

Huh? <link rel="shortcut icon"> works with data: URIs just like everything else. For example, my personal site uses one: http://ajf.me/

Source code:

  <link rel="shortcut icon" href="data:image/x-icon;base64,AAABAAEAEBACAAEAAQCwAAAAFgAAACgAAAAQAAAAIAAAAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AP//AAD+fwAA/38AAP9/AADFbwAAuW8AAL1vAADBbwAA/W8AAL1vAADDQwAA/+8AAP9vAAD/8wAA//8AAP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA">

> Apple now has their own incompatible favicon "apple-touch-icon" which is just a higher resolution favicon.

This is mostly true, but I guess they wanted to avoid scaling up 16x16 favicons into a blurry mess on iOS, so made icons specially tailored for the iOS homescreen into their own category.

They can be used to trick less technical users into believing a HTTP site is a HTTPS one. For example make the favicon a green padlock. This is mostly a browser issue, and may be resolved by marking all HTTP sites as insecure (which some have proposed).

This could be solved in future by allowing them only for HTTPS sites :D

zamalek• 11 years ago

This is mostly true, but I guess they wanted to avoid scaling up 16x16 favicons into a blurry mess on iOS, so made icons specially tailored for the iOS homescreen into their own category.

Vista introduced dumping pngs directly into icos[1].

I think Apple went this route to avoid having to download the ico as it contains multiple images and is hence quite a bit larger than the e.g. single 57x57 png you are looking for.

[1] https://msdn.microsoft.com/en-us/library/dn742485.aspx

KMag• 11 years ago

This could be solved in future by allowing them only for HTTPS sites :D

Ooh... this would be a good first step in gradually introducing marking all HTTP connections as insecure, similar to how Chrome is gradually deprecating SHA-1 certificates:

(1) Stop showing favicons for HTTP connections

(2) Start showing a cautionary icon (perhaps a yellow triangle containing an exclamation point) for HTTP sites and self-signed HTTPS sites

(3) Start showing a scarier looking warning for HTTP sites, but leave a cautionary warning for self-signed certs

(4) Start showing a cautionary icon for connections not using perfect forward secrecy

With Ed25519, Curve25519 and ChaCha20, the computational overhead for perfect forward secrecy has come down significantly.

Now if only we had a good standard for in-browser support of one or more password-authenticated key-agreement (PAKE)[1] algorithms for password input fields so that websites never held passwords. (This could be done via adding an extra attribute to the password input tag, so older browsers would submit the password, and newer browsers would perform PAKE verification.)

Hey, a guy can dream.

[1] https://en.wikipedia.org/wiki/Password-authenticated_key_agr...

talideon2• 11 years ago

The downside of .ico files is that the format doesn't support compression, so those files can get quite big.

RexRollman• 11 years ago

Personally, I have never seen a need for them. I believe they are a waste of bandwidth.

derekp7• 11 years ago

I don't understand -- are you saying you see pictographic icons useless in general, or only when they appear in a list of bookmarks? Quite a few people are quicker to recognize something from a picture than they are from a written description, which is why icons were invented in the first place.

Remember, that favicon is an icon for the list of favorites (IE's term for bookmarks) -- that was the original use of them, although if you are referring to having the icon next to the URL in the URL bar, that I can agree with -- that can be mostly pointless. Although some tabbed browsers make good use of them, by having them in the tabs themselves. Makes it real easy to see which tab belongs to which website.

MaulingMonkey• 11 years ago

I have a couple links in my bookmarks bar that I've reduced to just the icon. I'd rather waste bandwidth than screen real estate :)

SmellyGeekBoy• 11 years ago

I find them incredibly handy even in this day and age, when I have multiple tabs open. The favicon is a great way to identify which tab belongs to which site at-a-glance.

Edit: Chrome. I read further down that Safari is no longer showing them in the tab bar.

byuu6• 11 years ago

It's positively galling how happy he is about such a terrible decision.

How many billions (trillions?) of wasted favicon.ico requests have been made because they didn't bother to engineer this the right way and make it a <link> tag in the document? And pushing the Windows-specific icon format was just icing on the cake. And now Apple's doing it too with two more of their own requests.

I wish we could send him the bill for all the wasted power, all the wasted developer time (even ten seconds per developer for all 100 million+ sites out there adds up to quite a lot.) Then see how glad he was he checked this misfeature in.

EDIT: I don't care if you downvote, but if you do so, please tell me why I am wrong. I'd genuinely love to hear why you think this was a good idea.

TazeTSchnitzel3• 11 years ago

"It's positively galling how happy the inventors of robots.txt were about such a terrible decision.

How many billions (trillions?) of wasted robots.txt requests have been made because they didn't bother to engineer this the right way and make it a <link> tag in the document?

wareya2• 11 years ago

Robots.txt is different. Without it, bots have no way of knowing whether to get any other data from the site. You would need "bots allowed" information in the HTTP handshake itself to prevent bots from accidentally hitting pages they shouldn't. This can already be Very Bad.

byuu6• 11 years ago

Oooooh I see now, you took what I said and changed one of the words. Totally missed that before wareya's comment.

robots.txt and favicon.ico share nothing in common. Browsers do not automatically request robots.txt every time you load a site. If you count a bot as one visitor, they make up maybe 0.01% of your traffic. It's also an explicit request, the bot actually wants that file. Users don't actually explicitly ask for favicon.ico, their browsers do it for them when they type in pagename.html. It's also not part of the page like the icon is. favicon.ico is like having javascript.js and style.css in your root directory auto-scanned as well.

Unlike favicon.ico, you couldn't just slap a line in your HTML here instead, it would already be too late for crawling. If we tried to put this into the headers for a bot's HEAD request, then people with only file drop access to hosting wouldn't be able to change the robot settings.

That said, I'm always open to considering better ways of doing things. Maybe we could have web servers optionally parse robots.txt locally, and bots could get the information from a special OPTIONS / HEAD request instead.

enraged_camel3• 11 years ago

Hindsight is 20/20 my friend. Go easy on the guy.

byuu6• 11 years ago

That's what bothers me. He's happy about it in 2013 (this article's two years old.) He has hindsight now and still thinks it was a good idea to request resources on a web server without being asked. No consideration at all to the cumulative effects of such an action =(

And apparently a lot of people here agree with him. Scary :/

kitcar• 11 years ago

Although I can't stop the requests from being sent, a standard line I add into all my nginx confs to at least minimize my logfiles:

location = /favicon.ico { access_log off; log_not_found off; }

byuu6• 11 years ago

Unfortunately, even by disabling the logging, browsers like Chrome will keep wasting your server's resources asking for it if you return a 404. I know it's not going to overwhelm anyone's servers alone, but if you ever get a massive traffic surge that starts causing some visitor requests to fail, you'll probably enjoy having one less socket request per visitor.

I add <link rel="icon" href="data:;base64,iVBORw0KGgo="> into my HTML head section. I don't recall offhand if it stops the initial request in all browsers, but it does at least prevent repeated requests.

Most people would just tell you to drop a blank favicon.ico if you really don't want a site icon (and I don't), but I'm not going to clutter up my root directory with junk (this, two Apple icon files, and whatever else people decide to do in the future.)

samspenc• 11 years ago

Isn't the best solution to the problem this: browsers turn off automatic checks for /favicon.ico and only load the favicon if it exists in the HTML in the form of the official spec?

byuu6• 11 years ago

Yes, that would be the perfect solution to this problem. No sarcasm. Unfortunately, I don't see it happening. Probably millions of sites now that don't have the <link> tags, and you'd have a torrent of complaints as a browser vendor if you tried this.

aembleton• 11 years ago

Sort of related - on a previous HN discussion that moved onto favicons, someone suggested a website they created for helping to create them. That is http://realfavicongenerator.net/

I've found it very useful. Select a picture and all sorts of different formats of favicons are created.

jongalloway2• 11 years ago

I'd like to see SVG favicons become a standard so we don't need to keep packing favicon files full of different sized bitmaps. Apparently Firefox supports it: http://caniuse.com/#feat=link-icon-svg

freshyill• 11 years ago

The sooner we get away from the asinine practice of using a Windows format for this, the better.

It looks like all the current browsers support .png favicons, so we can at least cut out .ico at some point in the near future. .svg sure would be even better though. Someday, hopefully.

evan_• 11 years ago

One reason why this isn't the perfect solution it may sound like is that often different size icons have slightly different designs.

Near the end of this post:

http://www.hicksdesign.co.uk/journal/branding-firefox

Compare the 128x128 and 48x48 icons, and then compare the 48x48 and 16x16. As you go from 128 to 48 much of the detail in the fox's fur goes away, and as you go from 48 to 16 it becomes a simple gradient and the detail on the planet disappears as well.

If they simple resized a vector image, the 16px would be a muddy mess.

(There are probably much better examples somewhere, but this is just the one I've used in the past- apparently, for the last 10+ years...)

swift2• 11 years ago

SVG images support media queries, which handles this use case pretty well. See here:

http://blog.cloudfour.com/media-queries-in-svg-images/

swift2• 11 years ago

It's still extremely buggy in Firefox, I'm afraid. See here:

https://bugzilla.mozilla.org/show_bug.cgi?id=366324

emehrkay• 11 years ago

I love these stories. Is there a general software site with shorts like this (kinda like http://www.folklore.org)?

This was pretty good writing too. I was able to easily imagine what it would be like working at 10pm for Microsoft in the 90s. I begin to wonder if the characters knew if they were shaping the internet. Id like to read something about the first iPhone's Safari team. I bet they had to jump through major hoops to build that browser.

jabo3• 11 years ago

I wonder how many people working on ground-breaking stuff today are doing so unbeknownst to them, without realizing that they are shaping the field that they are working in.

jicea• 11 years ago

If you're into podcasts, you should check this episode of Debug http://www.imore.com/debug-11-don-melton-and-safari : it's Don Melton's interview, former Engineering Director of Internet Technologies at Apple, talking about open-sourcing Mozilla, building Nautilus, creating WebKit and the Safari browser.

This one is also good, again with Don Melton, http://www.imore.com/debug-111-don-melton-blink-servo-and-mo... about Servo and Blink.

szatkus• 11 years ago

http://blogs.msdn.com/b/oldnewthing/

yuhong• 11 years ago

A security flaw in IE5 support for this feature:

http://web.cip.com.br/flaviovs/sec/favicon/index.html

http://technet.microsoft.com/en-us/security/bulletin/MS99-01...

jabo3• 11 years ago

On a related note, anyone know why Safari has done away with favicons next to tab titles? Safari is pretty unusable as an everyday browser for me without them.

reubenmorais• 11 years ago

Most browsers have de-emphasized favicons in their UIs due to phishing, by moving them as far from the address bar as possible or through other measures, like Safari which only shows it when the address bar is focused.

People used padlock favicons to trick users into thinking they're browsing a secure website.

jabo3• 11 years ago

Hmm, looks like Safari does display the favicon right next to the address bar: http://i.imgur.com/Gj0Wu8h.png

So someone could theoretically use a green padlock icon as the favicon and still trick users.

My gripe is that with favicons missing in the tab bar, it's pretty hard to quickly navigate to the tab I want: http://i.imgur.com/yhStBMj.png

couchand• 11 years ago

It's hard to imagine using a modern browser without favicons on the tabs. What are the folks behind Safari thinking?

lucianmarin• 11 years ago

It’s easier on the eyes. You don’t to squint at a 16x16 images to get to the right tab. Once you get used to it, you won’t want to go back to Firefox or Chrome. I use Safari 8 daily and it’s simply amazing, fast and reliable.

snambi• 11 years ago

Wow! This is an awesome story!

WorldWideWayne• 11 years ago

I put a favicon.ico on one of my first sites and I was pleasantly surprised to find that the request for the favicon was only made when someone bookmarked the site allowing me to track the number of people who did so. Of course that is no longer the case, but it was nice while it lasted.

johnchristopher• 11 years ago

In the early 2000s mozillazine and others were covered with posts asking how to display and update a favicon reliably. Browsers seemed to randomly display and update it and your post explain some things I saw back then.

dheera• 11 years ago

You can still look for (the absence of) a referer while filtering out bots and crawlers. It's not perfect, but few people type in URLs manually, no if you're getting repeated requests from a human user with no referer, it's highly likely it was bookmarked.

khoatv• 11 years ago

Love the story! Honestly I often stare at the loading icon until the favourite icon is fully loaded.

bsimpson• 11 years ago

you just had to put a file named favicon.ico at the root of your IIS Server, and you were good to go!

That sentence says a lot about MS's view of the world in the 90s. "Just put an image in a Microsoft-proprietary format in a Microsoft-named location on your Microsoft web server to see this neat little feature in your Microsoft browser."

laserbutt• 11 years ago

I read this post a while back but somehow it won’t burn out. So I’ll throw a little more gas on and add some history.

In 1997 I’d wake up each morning after maybe 5 or 6 hours of sleep, shower and get dressed, wake up my 4 year old daughter, feed her and dress her, and then take her to daycare. Then I’d go to work and one of the first things I’d do is read through the late night checkins. I was Bharat’s manager. Ray’s story is legit.

Bharat had checked in a feature late one night, without a code review, and hoodwinked a junior PM into okaying the “spec”, which I found out later was not much more than a scribble on his whiteboard. First I dropped by the the PM’s manager’s office (who now heads up code.org, and who apparently chewed out the PM after I left him) and then I went to chew out Bharat. That’s just the way it worked - I knew I’d be getting a call (we had phones back then, on our desks) from my manager. Of course Bharat wasn’t there - it was like 930 in the morning.

Eventually I did chase down Bharat later that day. I was unhappy because a) I hated the implementation - it should have been a link-rel or something similar that didn’t invoke an extra http request, b) I knew based on the way he’d leveraged the IE cache to store the .ico file that if the user ever manually flushed the cache the file would get deleted but the cache index would not get nuked -ie. he checked it in with a difficult to fix bug c) the code hadn’t been reviewed (which was stupid, rare, a potential firing offense, but most importantly could get you assaulted by the thugs who lurked in building 26). It was never a problem that he hoodwinked the junior PM - just funny.

In the end, we agreed he’d get the code reviewed ASAP and he’d fix the bug. The code review happened within the hour (Bharat’s code was fine, but years later it was found that the lower level code it called resulted in ms99-018). The second didn’t - the bug entered and then later got pushed to the next release by one of the PMs. Then Bharat left, and I left, and others… and the bug lingered for years. I’d send whiny emails every couple months about it to the folks still working on IE and… fixing the bug got pushed the next couple releases. I can’t remember when it was finally fixed, but someone forwarded me the checkin mail when it did… I wish I’d kept it.

At any time that week that Bharat checked in the feature I could have sent an email and the checkin would have been backed out. I did hate the implementation… but I liked the feature. It had nothing to do with somehow “screwing Netscape”. It was just a nice, simple, cool feature - easy for web-devs to take advantage of, nice for users.

So the bureaucracy broke down that day, and the result was a popular, inefficient, buggy feature. The right call? Ray says it was. For me it was one of thousands of calls that we all have to make in a career, most right, some wrong, and some will be debated forever. I guess this is the latter. Move on.

Maybe UnoriginalGuy can get his ideas in some standard and implemented in Chrome or Safari. Or he could just check some code in late one night when nobody's around to stop him - I'm sure Ray will okay the spec ;-)

xorcist• 11 years ago

Needless to say, you were absolutely right about it too. There are obvious security implications (what if someone puts the image of a padlock there? do we really need another image file format?) but also oddities like making the web root responsible for icons throughout the web tree (as shared hosts was common at the time). Even a junior dev should have seen those coming.

whoopdedo• 11 years ago

IIRC, the HTTPS padlock in those days was displayed on the status bar, not the address bar.

sedatk• 11 years ago

Such a small yet significant achievement, and it only was realized by jumping over the corporate bureaucracy. It makes you think a about how much innovation has been lost in the gears.

Eric_WVGG• 11 years ago

The filename “favicon.ico” continues to drive me crazy. I always hated Microsoft’s insinuation that bookmarked or saved web pages were somehow analogous to “favorites”…

Inventing Favicon.ico

Related Stories