I Stored a Website in a Favicon

Instead of going via pixels, why not use a SVG favicon and directly store markup inside it and extract it?

Use this favicon.svg:

    <svg xmlns="http://www.w3.org/2000/svg">
    <circle cx="50%" cy="50%" r="50%" fill="orange"/>
    <p>hello HN!</p>
    </svg>

use this in your <head> to use a svg favicon:

    <link id="favicon" rel="icon" href="favicon.svg" type="image/svg+xml">

finally, use this in your <body> to extract it and add it to your document body:

    <script>
    fetch(favicon.href).then(r => r.text()).then(t => document.body.innerHTML += t.match(/<p[\s\S]*p>/)[0]);
    </script>

> You still need a tiny bootstrap loader to decode the image.

Nope, you can do it all in a single file with an html/png polyglot (and nowadays you can get better compression ratios with newer formats like webp).

https://web.archive.org/web/20120801001616/http://daeken.com...

You can use the favicon cache as storage too, by redirecting users across domains. It's been proposed as a potential fingerprinting risk[0], and if a browser naively reuses the cache for incognito mode, it could be used to track users across browser profiles.

[0]: https://www.schneier.com/blog/archives/2021/02/browser-track...

Is this timing coincidence? I just submitted 1h (30 mins before this) ago a website I just made about storing your stock porfolio in a URL + favicon!

https://news.ycombinator.com/item?id=48606396

PNG has comment chunks tEXt, zTXt, and iTXt. You can have a completely normal image whose file is stuffed with as much content as you want. That is less fun, I suppose.

I found the agressively staccato, clearly LLM-generated content extremely difficult to read.

Oh, I am so aligned with this mentality:

    A monitor is storage.

    A keyboard is storage.

Forum posts are storage. Markov-approved tweaks in an edit, over time, certainly enough for quite a lot of storage. Dual-use storage to boot, since .. you know .. sometimes the comments are socially interesting.

Best thing is, nobody really knows if their chicken casserole recipe isn't just a handle to a carefully constructed GUID pointing across to .. lets say, for humor .. a thousand different forum postings ...

I do have to wonder if the author is familiar with PoC||GTFO, for this is certainly a technique one will find deep within the depths of the Alchemist Owls' holy tomes...

Cool! Here is a GH repo demonstrating unbounded favicons I made 11 years ago - it crashes some browsers - wanna guess how long it took each one to fix it :D https://github.com/benjamingr/favicon-bug

Fun Fact: You can use any inline SVG for a favicon and keep it right in the HTML document.

This also allows you to use an emoji directly as a favicon, like so:

  <link
    rel="icon"
    type="image/svg+xml"
    href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>(your emoji here)</text></svg>"
  />

(HN isn't showing the emoji)

Have an index.html that's also (byte-to-byte equal) served as favicon.ico. If that page "works" and the favicon doesn't show garbage, it is a website stored in a favicon (by my standards).

AI generated garbage. Blocked

How long before someone ports DOOM into a favicon? ^_^

(For the technical gurus here, would that even be possible?)

I'd imagine the (aggressive) caching of the favicon by browsers makes it a challenge, but you could generate the favicon dynamically, then have JS extract the sequentially. Basically streaming arbitraily large content to a webpage via favicons. Via blocks of 239 bytes.

It may be a fun, novel way to proxy webpages that are otherwise blocked. Though, i guess, the service rendering the favicons can just as easily be blocked then.

also https://pong-in-a-favicon.franzai.com/ for further favicon (mis)use

Hmm this is cool but what are the practical use cases?

It didn’t load first time round on my browser (Brave) without disabling its prevent tracking feature…

Painful read.

Related interesting project: https://github.com/EtherDream/web2img

The browser already asks for the favicon on every page. Might as well put it to work.

Love it. Did you see the old effort to store the page in the url? https://github.com/jstrieb/urlpages

Wait 'til the author discovers that you can use ping (ICMP) to transfer data, too! :)

A neat improvement would be to make the decoder into a bookmarklet. This would avoid the overhead of serving the script. Of course you would rely on the user having the bookmarklet installed, but when you serve HTML you also rely on the user having a web browser installed.

Bravo Maestro! Wonderful performance! =)

Pretty cool tbh!!! Would have loved seeing the decoder code!!!

It's also pretty interesting to think how an attacker could exploit images on his behalf. Never thought that would be a way!!!

Thanks!

Honestly it didn't interest me, but I do remember from back in the days full websites rendered by a browser from... Empty files. https://mathiasbynens.be/notes/css-without-html

I would have used a minimal service worker to unpack the web data and present it as if it were just a normal page being loaded.

I personally won't do things this way, but this is really cool and I could see the applications already.

Very cool. I wonder is it possible to make a simple game with also leveraging the webassembly?

Fascinating concept! Thanks for sharing this!

very cool and interesting after reading just the title I wrongly assumed this would be about svg

Is it cake? Game for devs.

Would have been more fun if the blogpost was rendered from the favicon.

Surprised that a minimal "website" only requires a small image = few pixels = few bytes to store it? Um, ok.

You can literally just use the file itself as the favicon. There is no need to over complicate it.

cp index.html favicon.png

Is this timing coincidence? I just submitted 1h (30 mins before this) ago a website I just made about storing your stock porfolio in a URL + favicon!

https://news.ycombinator.com/item?id=48606396

Fun Fact: You can use any inline SVG for a favicon and keep it right in the HTML document.

This also allows you to use an emoji directly as a favicon, like so:

  <link
    rel="icon"
    type="image/svg+xml"
    href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>(your emoji here)</text></svg>"
  />

(HN isn't showing the emoji)

It may be a fun, novel way to proxy webpages that are otherwise blocked. Though, i guess, the service rendering the favicons can just as easily be blocked then.

Love it. Did you see the old effort to store the page in the url? https://github.com/jstrieb/urlpages

I would have used a minimal service worker to unpack the web data and present it as if it were just a normal page being loaded.

Honestly it didn't interest me, but I do remember from back in the days full websites rendered by a browser from... Empty files. https://mathiasbynens.be/notes/css-without-html

Fascinating concept! Thanks for sharing this!

very cool and interesting after reading just the title I wrongly assumed this would be about svg

Is it cake? Game for devs.

Would have been more fun if the blogpost was rendered from the favicon.

Surprised that a minimal "website" only requires a small image = few pixels = few bytes to store it? Um, ok.

Instead of going via pixels, why not use a SVG favicon and directly store markup inside it and extract it?

Use this favicon.svg:

    <svg xmlns="http://www.w3.org/2000/svg">
    <circle cx="50%" cy="50%" r="50%" fill="orange"/>
    <p>hello HN!</p>
    </svg>

use this in your <head> to use a svg favicon:

    <link id="favicon" rel="icon" href="favicon.svg" type="image/svg+xml">

finally, use this in your <body> to extract it and add it to your document body:

    <script>
    fetch(favicon.href).then(r => r.text()).then(t => document.body.innerHTML += t.match(/<p[\s\S]*p>/)[0]);
    </script>

Hey, yeah, I wrote the article. This (of course) would be more practical. Thanks for pointing it out. I wanted the payload to "live" in actual pixel data rather than hidden text inside an XML file. That’s why I went this way :)

An SVG can embed raster images: base64 encoded bytes.

So you could layer this experiment: favicon is svg, that contains encoded raster, whose bytes are encoded html.

At the very least it would make a mindboggling CTF step.

[0]: https://www.schneier.com/blog/archives/2021/02/browser-track...

Wasn't this fixed or mostly fixed?

PNG has comment chunks tEXt, zTXt, and iTXt. You can have a completely normal image whose file is stuffed with as much content as you want. That is less fun, I suppose.

Yes, that would also work, thanks for pointing it out

I found the agressively staccato, clearly LLM-generated content extremely difficult to read.

for the first time in a while on HN, i disagree with the characterisation as AI-generated. at most it was drafted with an LLM, but the final output is pretty human to me.

they used the wrong it’s/its, made But. its own one-word sentence, didn’t capitalise HTML, and used “okayy” in parenthesis. all of this isn’t to criticise the writer - i enjoyed it more seeing these little imperfections that make up a blog post

It’s the new internet. So, so annoying.

Which bit? The short sentences?

Yeah, but it's kinda weird. The typical LLM headers and bullet points are there, but it's like someone took an axe to the rest of the spew. I too would rather read someone's original bad writing than their bad editing of AI writing, but it's kinda interesting how this all shakes out.

Pretty cool tbh!!! Would have loved seeing the decoder code!!!

It's also pretty interesting to think how an attacker could exploit images on his behalf. Never thought that would be a way!!!

Thanks!

Very cool. I wonder is it possible to make a simple game with also leveraging the webassembly?

An SVG can embed raster images: base64 encoded bytes.

So you could layer this experiment: favicon is svg, that contains encoded raster, whose bytes are encoded html.

At the very least it would make a mindboggling CTF step.

Wasn't this fixed or mostly fixed?

Yes, that would also work, thanks for pointing it out

for the first time in a while on HN, i disagree with the characterisation as AI-generated. at most it was drafted with an LLM, but the final output is pretty human to me.

It’s the new internet. So, so annoying.

Which bit? The short sentences?

I guess the decoder is more than the 208 bytes that this page uses..

But maybe you can misuse this and store a session ID / cookie in a favicon (give everyone a unique one) and survive some cookie cleanup and evade privacy restrictions?

Maybe you can still make it that the favicon looks like an image a little to not raise suspicion?

Favicons seem to be cached across private browsing sessions. Oh no

Yes, probably. I guess, you’d need a bigger favicon since the minimal Rust WASM binary is around 20KB+ (?)

The ico file format allows multiple resolution icons, so a lot of data

I wish people would include their prompts.

I guess the decoder is more than the 208 bytes that this page uses..

But maybe you can misuse this and store a session ID / cookie in a favicon (give everyone a unique one) and survive some cookie cleanup and evade privacy restrictions?

Maybe you can still make it that the favicon looks like an image a little to not raise suspicion?

Favicons seem to be cached across private browsing sessions. Oh no

I wish people would include their prompts.

Yes, probably. I guess, you’d need a bigger favicon since the minimal Rust WASM binary is around 20KB+ (?)

You might find my tinkering useful: https://strich.io/blog/posts/embedding-webassembly-in-qrcode... A QR code isn’t much different from a favicon I guess. :)

The ico file format allows multiple resolution icons, so a lot of data

Good point, I might add a section in the article where I list alternative approaches. Thanks

You might find my tinkering useful: https://strich.io/blog/posts/embedding-webassembly-in-qrcode... A QR code isn’t much different from a favicon I guess. :)

Have an index.html that's also (byte-to-byte equal) served as favicon.ico. If that page "works" and the favicon doesn't show garbage, it is a website stored in a favicon (by my standards).

Painful read.

Related interesting project: https://github.com/EtherDream/web2img

Cool! Here is a GH repo demonstrating unbounded favicons I made 11 years ago - it crashes some browsers - wanna guess how long it took each one to fix it :D https://github.com/benjamingr/favicon-bug

I personally won't do things this way, but this is really cool and I could see the applications already.

AI generated garbage. Blocked

The browser already asks for the favicon on every page. Might as well put it to work.

Wait 'til the author discovers that you can use ping (ICMP) to transfer data, too! :)

Bravo Maestro! Wonderful performance! =)

You can literally just use the file itself as the favicon. There is no need to over complicate it.

cp index.html favicon.png

> You still need a tiny bootstrap loader to decode the image.

Nope, you can do it all in a single file with an html/png polyglot (and nowadays you can get better compression ratios with newer formats like webp).

https://web.archive.org/web/20120801001616/http://daeken.com...

You can even make the file compatible with ZIP (and PDF) on top of that, see https://github.com/gildas-lormeau/Polyglot-HTML-ZIP-PNG/raw/... (and https://github.com/gildas-lormeau/Polyglot-HTML-ZIP-PNG)

How long before someone ports DOOM into a favicon? ^_^

(For the technical gurus here, would that even be possible?)

You can already play it in a favicon [0].

But as favicons can be svgs, and let you store foreign objects... You could store the whole thing in the favicon, but might also need a line of JS to extract it.

[0] https://vidferris.github.io/FaviconDoom/

Hmm this is cool but what are the practical use cases?

It didn’t load first time round on my browser (Brave) without disabling its prevent tracking feature…

Practical use cases for stashing data in places people least expect it?

Wallet password.

New ecosystem for the kids.

That's two, at least.

Oh, I am so aligned with this mentality:

    A monitor is storage.

    A keyboard is storage.

I do have to wonder if the author is familiar with PoC||GTFO, for this is certainly a technique one will find deep within the depths of the Alchemist Owls' holy tomes...

Codes within codes. Wheels within wheels.

also https://pong-in-a-favicon.franzai.com/ for further favicon (mis)use

You can already play it in a favicon [0].

But as favicons can be svgs, and let you store foreign objects... You could store the whole thing in the favicon, but might also need a line of JS to extract it.

[0] https://vidferris.github.io/FaviconDoom/

A while ago I wrote about storing two bytes inside my mouse's DPI register. It wasn't useful. It wasn't practical. But it did something unfortunate to my brain. Once you've successfully hidden data somewhere it doesn't belong, you start looking at everything as potential storage.

A monitor is storage.

A keyboard is storage.

A BIOS splash screen is (maybe) storage.

A favicon is storage.

And yes, here we are.

Every website has a favicon. It's that little icon in your browser tab. Usually you upload it once and then never think about it again. But. A favicon is just an image. An image is just pixels. And pixels are just bytes.

So of course I wondered if I could store something inside one.

The idea

My first thought was steganography.

Steganography is basically about hiding data in an image without making it obvious. You take a perfect normal photograph and modify a few bits so it secretly contains a message.

The favicon itself (at least in my demo) doesn't need to look like an icon. It could become pure storage.

Every pixel has red, green and blue values. That's three bytes. If I wanted to store text, I could just take the UTF-8 bytes of the text and write them directly into the RGB channels.

The browser doesn't care what those bytes represent. To the browser they're colors. To me in this case they're HTML.

Building a favicon website

I started with a tiny HTML payload:

<h1>Website in a Favicon</h1> 
<p>
	Everything you're reading right now was decoded from favicon pixels.
</p>

The process is pretty straightforward.

First I convert the HTML into bytes using TextEncoder.

Then I prepend four bytes containing the payload length.

The length header is important because the image itself may contain unused pixels at the end. If there's no length value, there's no way to know where the real payload stops.

Then I just start filling pixels: the first byte becomes the red channel of the first pixel, the second becomes the green, the third becomes blue, and then the next pixel, and the next, and the next, until the whole HTML document exists as colored pixels. The result looks like visual noise.

Very small

What surprised me most wasn't that it worked, to be honest. It was how small the resulting image was.

The payload ended up being 208 bytes.

Adding the 4-byte header brings the total to 212 bytes.

Since every pixel stores three bytes, I needed:

212 bytes total
71 pixels
A square image large enough to contain them

The smallest square that works is 9x9 pixels.

That's only 81 pixels.

The final stats looked like this:

Payload: 208 bytes
Image size: 9x9 pixels
Capacity: 239 bytes
Used: 87%

Somehow a whole little website (okayy, html with some styling) fits inside an image that's smaller than the usual favicon.

Reading the website back out

Storing data is only half the problem. The other half is getting it back.

Browsers already have everything needed for this.

The favicon gets loaded as image.
The image gets drawn onto a canvas.
The canvas API lets JavaScript read every pixel.

Once I have the pixel data, I simply reverse the process.

Read the RGB values.
Reconstruct the byte array.
Read the first four bytes to determine the payload length.
Extract the payload.
Decode the UTF-8 text.

At that point I have the original HTML again.

The browser read a website out of its own favicon.

The important catch

The favicon doesn't actually contain the whole website itself.

It contains the content of a website.

You still need a tiny bootstrap loader to decode the image.

Without the JavaScript the favicon is just a PNG (which contains your website content).

For showing this scenario the site includes a "Render Website" button. It reads the favicon, decodes the HTML, and replaces the page with the reconstructed content.

Is this useful?

No, of course not.

The amount of data you can store is tiny. The page needs JavaScript to bootstrap itself. There are dozens of better ways to distribute a small HTML document.

But at the end its about testing the boundaries, right?

A favicon feels like a very specific thing. It's supposed to be an icon.

But at the end it can just be a PNG.

And a PNG file is basically just bytes.

And this is probably the smallest website I've built…

Alternative approaches

Store markup directly in SVG favicon and read it on page load.
Use PNG comment chunks like tEXt, zTXt and iTXt.
Use the ico file format since it allows multiple icons with different resolutions.

Here is the link to the site: https://www.timwehrle.de/labs/favicon-site/

And if you want to see how it works: https://github.com/timwehrle/favicon