Live data from Hacker News

I Stored a Website in a Favicon

timwehrle.de

81–90 of 120 posts

Re: I Stored a Website in a Favicon

#83

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

Which bit? The short sentences?

Not just the length but the structure, the way the headlines are phrased, the use of "honestly", the "not X but Y", many things cumulatively, not one particular thing in itself. If you work a lot with LLM writing, you notice. Same way you recognize the writing style of famous authors. It's never one particular thing but many.

Re: I Stored a Website in a Favicon

#85
> 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.

Not really, can’t you just pad with 0 bytes and stop reading when you encounter one that’s not part of the current Unicode codepoint?

Re: I Stored a Website in a Favicon

#88

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 p…

Codes within codes. Wheels within wheels.

Re: I Stored a Website in a Favicon

#90
post #13
post #7

Instead of going via pixels, why not use a SVG favicon and directly store markup inside it and extract it? Use this favicon.svg: hello HN! use this in your to use a svg favicon: finally, use this in your to extract it and add it to your document body: fetch(favicon.href).then(r => r.text()).then(t => document.body.innerHTML += t.match(/ /)[0]);

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 :)

If you wanted to play around and do something a little more challenging (though you'd be bulking up the javascript) then one thing you could do is play with a bespoke html compression. You could store the tags in 4 bits `0001` first bit, tag open or close, and the remaining 3 bits indicate which tag is being used (div/p/b/h1/etc). With at least one of the values like `0111` indicating text is following and another tag like `1111` indicating that an unsupported tag follows.

If you extend it out to 8 bits you can pretty nearly store all the html tags (it'd give you 256 tags to play with).

Post reply on HN