Perfect example of a (part of a) security vulnerability being fixed in a commit that doesn't immediately seem security related and would never be back ported to a ~~stable~~stale distro

The code which parses the binary MaxMind database after decompression is well guarded as of 2024 but used to look different, potentially providing more attack surface. There is also an interesting commit where a contributor makes adjustments to the gzip::decompress() function which hints at a stack overflow, as the destination buffer was changed from static allocation on the stack to dynamic allocation on the heap, though it was not exploitable due to checks before it is written to

Winamp published their code as "open source". Problem is...

1. It wasn't open source, it was proprietary but you can see the source code.
2. Their custom license didn't even allow forks, which is against GitHub TOS
3. The codebase apparently contains proprietary code from third parties that they don't have the right to relicense.
4. The codebase apparently contains GPL code from third parties that they probably didn't have the right to make proprietary in the first place

I don't think it's quite as simple as someone just forking it. Realistically, a browser is an extremely complex piece of software that requires a lot of organizational effort to maintain, deal with security issues, etc. Pretty much every other piece of software on a similar scale I can think of (the kernel, KDE, Blender, Libreoffice) has some sort of organization behind it with at least some amount of officially paid work. All the major forks of Firefox or chromium follow quite closely to upstream for this reason (which is also why I'm skeptical of Brave's ability to maintain manifest v2 long term, despite their probably genuine best efforts to do so).

I do wish that Firefox were developed and funded by an organization specifically dedicated to developing it. This could of course happen if Mozilla dies. But that's going to require someone starting it, which is not at all a small or cheap task.

I could also see a future where Oracle or IBM buys it 😂🤡

This one is already in the default uBlock filters - Badware risks

I also strongly suggest adding https://big.oisd.nl/ as a filter list. It's a large and well maintained domain blocklist (sourced from combining lots of other blocklists) that usually adds lots of these sorts of domains quickly and has very few false positives.

If you want to take it even further, check out the Pro list and Thread Intelligence Feeds list here https://github.com/hagezi/dns-blocklists

These can all be added to a pihole too if you use one.

This is why ublock origin is an essential security tool.

Zip uses very bad encryption that is vulnerable to a known plaintext attack. Do not ever use PKZIP encryption for any purpose https://github.com/kimci86/bkcrack

Not at all surprised, motherboard firmware from most vendors has always been a steaming pile of shit code, often not even built to spec.

The issue is whether the data is collected by a known third party tracker domain which would be blocked by an adblocker

Friends don't let friends not use ublock origin

Ogg Opus for all lossy audio compression (mp3 needs to die)

7z or tar.zst for general purpose compression (zip and rar need to die)

Any post mentioning Wayland or btrfs is guaranteed to have at least 60 comments

For a company that claims to be desperate to cut costs they sure do have a lot of money for frivolous lawsuits...