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.
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>[0]: https://www.schneier.com/blog/archives/2021/02/browser-track...
It's also pretty interesting to think how an attacker could exploit images on his behalf. Never thought that would be a way!!!
Thanks!
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.
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
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
Related interesting project: https://github.com/EtherDream/web2img
cp index.html favicon.png
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...
(For the technical gurus here, would that even be possible?)
It didn’t load first time round on my browser (Brave) without disabling its prevent tracking feature…
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...
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.
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.
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.
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.
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:
The smallest square that works is 9x9 pixels.
That's only 81 pixels.
The final stats looked like this:
Somehow a whole little website (okayy, html with some styling) fits inside an image that's smaller than the usual favicon.
Storing data is only half the problem. The other half is getting it back.
Browsers already have everything needed for this.
Once I have the pixel data, I simply reverse the process.
At that point I have the original HTML again.
The browser read a website out of its own favicon.
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.
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…
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
Wallet password.
New ecosystem for the kids.
That's two, at least.