
Abusing Your Browser: Infinitely Large Favicons - ejcx
https://ejj.io/abusing-your-browser-favicon/
======
esailija
"I believe in most other countries, that aren't the United States, people pay
their internet usage by bandwidth used." that's... false

~~~
TeMPOraL
Yup. I was under the impression that data transfer limits are a pretty
American thing, and in Europe they're the hallmark of a shady, crap provider
(most commonly a big telco).

~~~
LoSboccacc
also depends on whether it's a mobile plan or not.

~~~
TeMPOraL
Yes, that too of course. I was thinking of residential connections.

------
breakingcups
Bug trackers:

Chrome:
[https://code.google.com/p/chromium/issues/detail?id=500639](https://code.google.com/p/chromium/issues/detail?id=500639)
(reported 2015-06-15, unfixed as of yet)

Firefox:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1174811](https://bugzilla.mozilla.org/show_bug.cgi?id=1174811)
(already fixed on 2015-06-16)

~~~
anon1385
>(already fixed on 2015-06-16)

Not so fast. The SVG version in comment 14 isn't fixed yet it seems.

[https://bugzilla.mozilla.org/show_bug.cgi?id=1174811#c14](https://bugzilla.mozilla.org/show_bug.cgi?id=1174811#c14)

------
zoidb
Here is the thread from the last time this surfaced, I guess not much has
changed since then?
[https://news.ycombinator.com/item?id=9720665](https://news.ycombinator.com/item?id=9720665)

------
zamalek
The deeper concern here is this:

> until the OS crashes

How is it even possible that userspace crashes the OS due to memory
exhaustion?

~~~
viraptor
When you run out of memory something needs to be killed, or swapped. If you
start swapping, you're not responsive anymore (you can generate data faster
than writing it to disk). If you kill something, it may not be the application
which needs to be killed.

Usually systems don't come preconfigured with a hard per-app limit (which is a
bad thing...), or oom score (systemd got this more popular though), so
crashing the OS is still fairly easy.

~~~
ekimekim
My experience is that the OOM killer is generally pretty good at picking the
right process to kill. At least on linux, it also considers whether the
process has child processes, and kills them preferentially. These two aspect
together mean that a linux system should consistently kill the tab loading the
favicon and not, say, x11.

~~~
Piskvorrr
Well, I did see an X11 server killed under unusual circumstances (not :0, but
an Xvfb-for-Xpra; incidentally, this also killed its child, which was the
offending process)

------
stestagg
Op suggests 5mb limit on Favicons. Assuming a 32x32 pixel display size
(retina). That's 1k bytes per pixel!

~~~
Synaesthesia
You can have a long animation on your favicon

~~~
Qwertious
I have to ask: Why do favicons need the ability to be animated? It's like the
ability to autoplay mp3s on a webpage upon loading: There may very well be a
use case for it, but there's a pretty big use-case for it NOT being possible,
which is that it's pretty goddamn stupid.

And since we're _clearly_ not adhering to Unix philosophy on the web, I say
that it being idiotic is a good enough reason to not allow for it.

~~~
TeMPOraL
One thing we need to figure out: how to ban assholes instead of banning
features. In general, things can be either interesting XOR safe, and we're
killing off more and more interesting things[0] on the web just because some
assholes will surely make use of them.

[0] - like e.g. calls for rate-limiting access to phone gyroscopes, or banning
it altogether, in
[https://news.ycombinator.com/item?id=10914666](https://news.ycombinator.com/item?id=10914666).

~~~
stestagg
I agree with you, in principle, BUT there's always a tradeoff to be had. In
this case, I don't really see it.

As a typical user, I never want my favicon to be more than ~1MB. More
interesting effects may be done, but can be done in javascript, for example.

------
Xophmeister

        ...there is no way to tell the size of something you want to
        download until you've downloaded it.
    

A HEAD request should give you the size of the response body, in octets, in
the Content-Length response header. This should (almost) always be present
from a well-behaved web server.

~~~
Lukasa
Only if the file is served as one large chunk. If sent using Transfer-
Encoding: chunked, there is no requirement to provide a Content-Length header,
and a HEAD request may not show one.

The way Go's built in HTTP libraries work is that, if you don't attach a
Content-Length header yourself, you will automatically send a chunk-encoded
response. That's exactly what the OP's server does, and as a result there is
no Content-Length to look for.

User-Agents need to defend against this by setting an appropriate upper-limit
on the size of the object they want to receive.

Note that there's another obvious way to try to consume bandwidth: host a
"file download" that actually just sends a chunk-encoded random byte sequence
until the connection closes.

~~~
Grue3
A favicon should probably never be chunked in the first place.

~~~
Lukasa
Why?

~~~
stestagg
The body for the majority of favicons should fit into a single tcp packet.
Adding the overhead of chunking is completely pointless.

Partial icon streams have no use to the client, and given the server should
almost certainly have the entire icon in ram, streaming has no use for the
server.

~~~
jrockway
> The body for the majority of favicons should fit into a single tcp packet.

That all depends on the type of internet connection. Sure, it's a great idea
for the first world where you get 1Gbps symmetrical for $70 a month. But not
everyone has that good of a connection, and packets can be dropped like crazy,
dramatically decreasing the size of the window.

~~~
Decade
Still not a hot idea. The IP packet size is ultimately limited by the Ethernet
frame size, which is 1500 bytes practically everywhere. The article says, “A
ton of favicon were bigger than 50k,” so it would take over 30 flawlessly
delivered fragments to create this hypothetical “single” TCP segment. Any
congestion anywhere between you and the server, and the segment does not
succeed.

Though, I suspect stestagg meant IP packet. Less than 1.5 kB is just too small
for most icons. The ubiquitous 32×32 Wordpress icon is just about small
enough, and still sharp enough for Retina, but Amazon’s more detailed favicon
is 2.8 kB, Y-Combinator’s icon is 6.5 kB, Apple’s 2-toned logo is 9.1 kB, and
Microsoft’s 4 colored squares are an astonishing 17.1 kB.

On the other hand, like everything else outdated about it, Slashdot’s icon is
a mere 668 bytes.

~~~
J_Darnley
How the hell big are these icons? 16x16 pixels uncompressed RGB is 768 bytes
(1024 if you're using padding or alpha).

I have just opened the page info for this reply page and am astonished to see
a 256x256 image for the favicon. Who's utterly retarded idea was that?

I guess that answers my first question. "Idiotically large" is the answer.

~~~
Piskvorrr
Guess whose. (Starts with A, ends with -pple. Actually, that's not true either
- .ICO has historically supported 256x256x16b for decades: there just wasn't
anyone _making_ them.)

Of course, there's nothing intrinsically _bad_ about high-resolution favicons
- esp. given the current ultra-high-res displays. The size difference is only
most marked in this specific use-case.

------
excitom
This is a classic example of a DOS attack, the kind of thing 4chan'ers take
delight in unleashing on unsuspecting visitors to a web page. Why do it? For
the simple joy of screwing with people.

------
sleepychu
I was so suspicious when this page didn't have a favicon... (it's safe)

