News for hackers. Stuff that matters.
Re:Firefox 66 to block automatically playing audible video a... by jefftk on Monday February 04, 2019 @01:40PM (#19079242)
The browser doesn't know the image is a GIF (content-type header) until after it starts getting bytes back. At that point the only way (pre HTTP/2) to stop the bytes is to close the connection, but this is terrible for performance because you lose keepalive and need to open a new connection.

If this was common, sites could also serve GIFs with an the content-type of a different image. Since browsers content-sniff between image formats, if the GIF was served as image/png then it wouldn't be until the image finished downloading that the browser would learn it was a GIF.

Re:Firefox 66 to block automatically playing audible video a... by codetrotter on Monday February 04, 2019 @03:48PM (#19080477)
> if the GIF was served as image/png then it wouldn't be until the image finished downloading that the browser would learn it was a GIF

GIF has a header at the start of the file identifying it as such. It starts with one of two six byte long sequences identifying the version of the format that is being used.

0x47 0x49 0x46 0x38 0x37 0x61 ("GIF87a")

0x47 0x49 0x46 0x38 0x39 0x61 ("GIF89a")

So as long as the file isn't served with additional compression obscuringly applied on top (gzip etc) you will have an indicator that the file might be a GIF after downloading just the six first bytes of it.

Of course you could be unlucky and try to download a file that is not a gif but which happened to start with either of those two sequences of bytes.

But you could:

- Stop downloading it if the URL was loaded via <img>, and place something like an image of the word GIF with a cross over it in the img tag.

- If it was loaded outside of <img>, let the user know that it was blocked as suspected GIF but allow them to override.

At least as a first step toward some kind of anti-GIF thing.