Let's go a step further and just iterate through them on the client. I plan on having this phone well past the heat death of the universe, so this is guaranteed to finish on my hardware.
function* uuidIterator() {
const bytes = new Uint8Array(16);
while (true) {
yield formatUUID(bytes);
let carry = 1;
for (let i = 15; i >= 0 && carry; i--) {
const sum = bytes[i] + carry;
bytes[i] = sum & 0xff;
carry = sum > 0xff ? 1 : 0;
}
if (carry) return;
}
}
function formatUUID(b) {
const hex = [...b].map(x => x.toString(16).padStart(2, "0"));
return (
hex.slice(0, 4).join("") + "-" +
hex.slice(4, 6).join("") + "-" +
hex.slice(6, 8).join("") + "-" +
hex.slice(8, 10).join("") + "-" +
hex.slice(10, 16).join("")
);
}
16 bytes is a lot. 4 bytes are within reach, we can scan all of them quickly, but even 8 bytes are already too much.
Kolmogorov said that computers do not help with naturally hard tasks; they raise a limit compared to what we can fo manually, but above that limit the task stays as hard is it was.
No. Firefox always randomizes the extension ID used for URLs to web accessible resources on each restart [1]. Apparently, manifest v3 extensions on Chromium can now opt into similar behavior [2].
That's a different form of defense. The original claim in this thread was that LinkedIn's fingerprinting implementation was making cross-site requests to Chrome Web Store, and that they were reading back the response of those requests.
Firefox isn't susceptible to that, because that's not how Firefox and addons.mozilla.org work. Chrome, as it turns out, isn't susceptible to it, either, because that's also not how Chrome and the Chrome Web Store work. (And that's not what LinkedIn's fingerprinting technique does.)
(Those randomized IDs for content-accessible resources, however, do explain why the technique that LinkedIn actually uses is is a non-starter for Firefox.)
An additional improvement added in manifest v3 in both Chromium and Firefox is that extensions can choose to expose web accessible resources to only certain websites. Previously, exposing a web accessible resource always made that resource accessible to all websites.
Notably Notepad++ was recently shipping unsigned/self-signed updates, apparently overlapping with the time of this incident, see releases 8.8.2-8.8.6: https://notepad-plus-plus.org/news/
The lack of signing and/or checking the signature when updating is the real issue here. But the write up blames the attack on the hosting server. That doesn't bode well for future security.
You don't even need a certificate to prevent update tampering like this. The updates could have shipped with an ECDSA signature and this wouldn't have happened. It's also free and doable in an afternoon.
Notepad++ is Windows-based and could use the Windows store instead of the built in updater. Microsoft charges a one time fee. It would pass SmartScreen checks. His website has a bunch of ads integrated which I assume are there to help pay for hosting.
Mr. Ho already has hosting charges and he uses GitHub. For those who use GitHub, he could continue his GnuPG method for signing. Additionally, GitHub integrates with Sigstore. Windows wouldn’t trust his signature but at least there would be better traceability. Version 8.8.7 labeled “authenticity guaranteed” is a step in that direction.
The real “issue” here was his outside hosting platform for updates from my reading of the article.
Even that won't last forever. Notably, Edge is only guaranteeing updates until October 2028 [1], coinciding with the end of Windows 10's 3-year ESU period. Previously, Chromium ended support for Windows 7 at the end of its ESU period (which was also the end of support for Windows 8.1) [2]. However, Firefox continues to support Windows 7/8.1 by providing security updates for an older ESR version of Firefox 115; they appear to be re-evaluating whether to continue support every 6 months, currently set to end in March 2026.
