> `tar` up an entire WordPress install, save it as `favicon.ico` and then easily pull the files from the server.

assuming I have access to the server to create the tar and save it, what's the difference between downloading the archive as favicon.ico or any other name?

If you don't have control over the logging (for a number of reasons) you can disguise your xf in the access logs. I'd be willing to bet that a lot of logging config files for access logs even ignore favicon.ico.

You could also hide it as any kind of regular static resource. I still don't understand how it's any worse than, say, hiding a massive image in a webpage. Bogus websites are going to be bogus no matter what, I can understand browser devs not wanting to guess arbitrary limitations for some resources when an hostile attacker will have plenty of other opportunities to achieve the same thing.

What would be the point of adding a limitation to the favicon size really? Protecting users from websites where the webmaster is silly enough to put a 1GB favicon by mistake? Doesn't seem common enough to warrant the extra code IMHO.

>What would be the point of adding a limitation to the favicon size really?

Uh, yea, the browser shouldn't become unresponsive, break, or behave in such unexpected ways. Not having a limit is just sloppy. Understandable how it'd be overlooked, but sloppy none-the-less.

That's reasonable, but won't you get the same result in a million other ways?

I agree that preventing the browser to become unresponsive when loading bogus/malicious pages is a worthy objective but I don't see why the favicon needs to be singled out as a "bug".

These kinds of deny of service attacks against browsers have been known since, like, forever and they're basically impossible to completely prevent given the surface of attack and the complexity of modern web pages.

Whatever that website is, has an issue, since that backup.tar may contain their database credentials.

The favicon thing is just an annoying browser crashing bug. You could call that an "exploit" but up until fairly recently you were able to crash many browsers by generating too many message boxes (e.g. alert()) asynchronously.

So while, yes, it would be nice to fix it I don't really see it as being a high priority or one which will be actively exploited (since there is no "payoff" to either prankers or bad guys to this exploit).

Eating users' bandwidth has its uses as well as filling up a network with communication. This works with JavaScript disabled too but yeah I agree it's not a huge priority.

I know for a fact that eating mobile bandwidth would be a huge priority for some (as far as getting it fixed). For example; I live in Canada and my mobile plan is only for 8gb. If I go over I have to pay a premium, and it is not a cheap premium. I don't think unlimited bandwidth on mobile is popular (at least here, I suspect other places cough India cough) as well.

Even if you cap favicon size you don't solve the issue you're discussing at all.

A bad actor web-site can just move from favicon to an image, script file, or just return an indefinite series of HTML characters with no end.

The only way for the issue you want solved to be solved is for mobile browsers to add a "max page size" option, that will stop downloading content after it hits the cap.

In general this favicon bug is neither here nor there with the issue you're concerned about. Nobody needs this to waste your bandwidth.

The only reason this is noteworthy is that it is a little embarrassing for the browser vendors and it causes the browsers (Firefox and Chrome) to crash.