Constructing the Word's First JPEG XL MD5 Hash Quine | Hacker News Reader

Constructing the Word's First JPEG XL MD5 Hash Quine

stackchk.fail

131 pointsluispa24 comments

One of my saved HN comments from @Retr0id:

---

    Beware of having too-small fingerprint hashes though, or not checking enough of the digits.

    $ echo -n retr0id_662d970782071aa7a038dce6 | sha256sum
    307e0e71a409d2bf67e76c676d81bd0ff87ee228cd8f991714589d0564e6ea9a  -
    
    $ echo -n retr0id_430d19a6c51814d895666635 | sha256sum
    307e0e71a4098e7fb7d72c86cd041a006181c6d8e29882b581d69d0564e6ea9a  -

---

* https://news.ycombinator.com/item?id=38668893

I later wrote an article explaining how I computed that: https://www.da.vidbuchanan.co.uk/blog/colliding-secure-hashe...

(Doing it the "obvious" way would involve infeasible amounts of storage space)

I'd be interested in seeing even your messy non-working code for that.

I ended up mostly rewriting it: https://github.com/DavidBuchanan314/birthday_party/

This is soo cool! Especially the prediction machine stuff. I had no clue this was possible.

And also at the same time a good reminder for everyone to find a browser that supports JPEG XL. I wonder if that was part of the reason to do this. :)

> And also at the same time a good reminder for everyone to find a browser that supports JPEG XL

That's probably furthest down on my list of features I look for in browser, where the top two are "Not run by a for-profit company living on extracting data from users" and "Can have tabs vertically in sidebar in a tree-based structured format".

Waterfox might be what you’re after?

- Supports JXL out of the box (including support for alpha transparency and animations)

- Vertical tabs with optional tree tabs (hired the original tree style tab developer to implement the feature)

- For profit, but I don’t want your data, collect it or use it to earn a living (telemetry/analytics/experiments disabled at build time and alongside a fair few patches on top to make sure external connections are limited to what’s necessary)

Sidebar, I’m the developer of Waterfox

Firefox (with minor changes + addons) is what I use today, works well for what I care about. Thanks for the recommendation though!

While you're here, last time I came across your website (and it seems like it looks the same currently), I noticed that your browser comparison is not including Firefox, which is what you've forked from (as far as I can tell at least, it isn't made clear by the landing page actually, but the UI and name makes it obvious), which feels like it's a bit misleading almost intentionally.

Not intended to be misleading in a way, but it is on purpose as Mozilla don’t like it when there’s mention of Firefox on the website so I make any references sparingly.

Huh, interesting. Is it that you're avoiding Mozilla from some sort of retribution, preventing you from effectively working on Waterfox in case you anger them? I'm not sure it should matter too much what Mozilla thinks about other browsers comparing themselves to Firefox, it's definitely fair usage as long as you don't try to trick people into believing Mozilla is also building Waterfox / Waterfox is somehow exactly the same as Firefox.

Just adding Firefox in your comparison table really should be fine, and kind of makes me want to ask someone at Mozilla why others would be afraid of doing so.

Also one which doesn't add new image decoder with built-in VM that is rawdogged in C, like Safari.

Chrome and Firefox are making a very reasonable decision to wait for a memory safe decoder.

Chrome's involvement in the past few years has (until very recently) been anything but reasonable.

That said, have any of them subjected WebP or AVIF to the same strict requirements, or should we reserve those only for less complex codecs actually designed with images in mind?

In the era of LLM-generated content, such a high-quality writeup is a breath of fresh air. Well done!

Nobody was this excited about WEBP.

Webp was not as exciting. JpegXL has cool features like 20% improved lossless jpeg recompression and progressive decoding. Not to mention all the cool stuff used in the writeup like implementing a font in the prediction engine.

And best of all, it's not a google product, so it can be trusted.

Actually JPEG XL is based in part on Google's PIK format. The Zurich team from Google Research (which developed PIK and Brotli) is even actively working on JPEG XL to this day.

The reason why Chrome (also a Google product) removed it at first is more likely to be internal politics. Google is a very large corporation after all, with each faction within it having its own priorities and alignments. In the case of Chrome the team there are probably more aligned with the AVIF/AOM team than with Zurich/PIK when it came to the next-gen image format to be pushed (which would explain why Chrome did not have problems with Brotli, because there wasn't a competing Google faction that is developing a replacement for gzip).

Shouldn't that be "World"?

Reply on news.ycombinator.com