I can't tell from your post if you are surprised by this or just pointing it out for others who would prefer to avoid this sort of tracking, but just to be clear, this is by design:

https://blog.mozilla.org/security/2021/01/26/supercookie-pro...

The creator of supercookie.me made it sound like all versions of FireFox were vulnerable.

It may have been their intention, after reading the bugzilla report they made[1].

> I also think that it would have been appropriate to notify about the ulterior motive behind this defect report at the latest when the paper got published. This underhanded approach of reporting a defect just leaves a bad taste, really. The behavior may be an actual defect in the classical sense, but I'm just wondering what would have happened, had this been addressed "in time" by the developers. It would seem that the researchers would then have triumphantly proclaimed that all major browsers are prone to their newly found attack. Must be somewhat disappointing that it didn't get fixed "in time" to make it into the paper that way

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1618257

Honestly, this is a big deal here. A "security researcher" attempted to _introduce new vulnerabilities_ into a major open source project just so that they could report these vulnerabilities later.

How scammy can research get?

There’s a perfectly plausible charitable interpretation offered by the reporters in comment 10.

They say that they filed this bug before they had devised their attack on the favicon cache; and so they reasonably asked, “why isn’t Firefox caching it like everyone else and as we believe everyone should?”—because as :mossop explains in comment 13, the spec suggests it should be cached, by remaining silent on the point.

Then, they developed the attack, and reported it to the affected browsers, which excluded Firefox. Certainly it was not great to leave it open without adding a comment saying “hey, don’t go ahead with fixing this yet, we developed a fingerprinting attack if it does get cached”, but it’s easy to understand this being overlooked. Also, as the reporters of the issue, they would receive any progress on the issue by email, so if you assume good faith, then they would have pumped the brakes if someone had actually gone ahead with implementing the initially-requested caching.

It’s possible that there was bad faith, but I find the good faith explanation entirely plausible—that there was a minor error of judgement only.

This is perhaps related to the topic of an article that was posted here a few weeks ago, which was about CVE databases adopting some sort of charter because of a trend to use CVE reporting as a way to stuff one's resume.

People have to do cray things to get noticed now. For better or worse, get used to it.

Lol, this is downright wild.

Please note that I've nothing to do with the authors of this paper[1]! ~jonas

[1] https://www.cs.uic.edu/~polakis/papers/solomos-ndss21.pdf

To clarify, falsifying results was never my intention: During my work I tested Firefox (v 84.0) and everything worked fine under Windows & OSX.

Due to your feedback I've updated the table in the GitRepo and the website and added that the current FF version (v 85.0) is no longer vulnerable! ~jonas

Same on Firefox on linux. I got a fingerprint on one tab, and when that finished, I opened a new tab and ran the demo again - which gave me a new fingerprint ID.

Running privacy badger and ublock origin

Firefox blocks supercookies by default. It's not your addons.

That's it, I'm running Privacy Badger as well!!!

You don't even need to come back with incognito mode. At least for me, just pressing the "try again" button gives me a different ID. (Firefox 85, windows)

Same on Safari in iOS (latest version as of this date).

Same with Samsung Internet on Android