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).

> 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

> 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...

> 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

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

Yes they do. You can put PNG encoded images into an ICO format container.

Only as of Windows Vista, and how well supported are ICO-wrapped-PNGs in browsers?

Does it matter much given HTTP compression?

Please put four spaces in front of that very long unbroken line.

? it's a data uri with a base64 encoded icon file

http://en.wikipedia.org/wiki/Base64 http://en.wikipedia.org/wiki/Data_URI_scheme

Down voted for breaking the site. Not that it helps...

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

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.

> 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.

Somebody should have told the team responsible for the Windows 7 start menu, where the items in the right-hand column have no icons until you're already pointing at them (and pause a moment) at which point they pointlessly draw attention away with a giant icon in a different place on the screen.

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.

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 :)

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.

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.

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.

> 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."

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

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...)

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

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

And circle is complete: infinitely scalable icons defined for specific resolutions!

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

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

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.

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.

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.

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.

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

That's not the current version of Safari. The current version 8.x.y does not show favicons.

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

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.

Nice try, ghost of Steve Jobs.

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.

"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?

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."

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.

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.

> You would need "bots allowed" information in the HTTP handshake itself to prevent bots from accidentally hitting pages they shouldn't.

Humans could also hit such pages. If your GET requests change state, there's no helping you.

The whole point of robots.txt is that there are pages which people may hit that bots can't. What are you on?

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?

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.

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

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 :/

You are misinterpreting it. He says:

"But now I look back & realize that we did the right thing. Seriously, how risky was this feature?"

By "the right thing" he's referring to checking in a relatively minor and risk-free feature late at night without going through the corporate bureaucracy at Microsoft.

Besides, I think you're making a big deal out of it. It's supposed to be an entertaining story about how favicon.ico came into existence, not a deep analysis of whether it was the correct way to implement it.

I wrote a big long thing, and made a mountain out of a molehill, but here's the condensed version :

Even though this article is just intended to be a cute quip about the origins of something we all take for granted, if I were a person who was negatively affected due to the author skipping 'corporate bureaucracy at Microsoft'( perhaps a victim of this kind of bug[1] ), i'd probably find the authors "how risky was this feature?" statement to be pretty irritating.

Is there any way to know that such a bug would have been included had they followed procedure? Of course not. But, we do know that those procedures and processes exist for that very reason : to ship a higher quality product

[1]: https://technet.microsoft.com/library/security/ms99-018

>>But, we do know that those procedures and processes exist for that very reason : to ship a higher quality product

Not always. It is possible for procedures and processes to exist simply because someone somewhere is trying to justify receiving a paycheck. This is especially true for large bureaucracies.

And sometimes, procedures and processes exist because the organization simply does not realize that they are outdated and unnecessary. "This is how we have always done it" is a common saying in large organizations that have been around for a long time.

Bottom line: don't put much faith in procedures and processes. Question everything.

But it wasn't the right thing. That bureaucracy would have saved the world billions upon billions of useless HTTP GET requests that just return 404s. It was relatively minor to him only because he only thought about it on a small scale. But when you're talking about the web, you have to take the full scale into account.

And no, it's not really a crisis-level issue. The modern web is full of hundreds of little annoyances, it's pretty much the nature of the game. But I felt it was on-topic all the same.

But yeah, complaining about it here certainly isn't going to change anything; and I'll agree that the story behind it was interesting to hear even if I despise the result of it.

> But it wasn't the right thing

Given what they knew at the time it was the right thing to do. That was the point.

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; }

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.)

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

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/.

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

Lots of Mozilla stuff:

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

http://www.mozillamemory.org

http://www.codersatwork.com

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 ;-)

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.

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

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...

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.

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”…

It's mere coincidence I saw your comment when I did. I'm not "pounding F5", but I did edit my comment above a few times, which also causes a page re-render.

Fair enough then, sorry. But why did you quote me again in my corrected post? :/ I'm not going to delete it, don't worry. I don't really care about comment scoring, I mean what I say and stand by my words.

(but I guess it's nice that your quote is keeping what I said in black text, eh? :P)

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

Wow! This is an awesome story!

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.

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.

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.