The OEM kernel is available in the repo too, though requires that the kernel in the ISO works enough for your hardware to get to that point. More info about that OEM kernel is available at https://wiki.ubuntu.com/Kernel/OEMKernel, and worth looking into when you have really new hardware and running slightly older OS releases.
It would only stop pirates for a whopping 24 hours at best. If there is a will, there is a way to bypass video DRM. It has to be decrypted at some point to appear on a display, and that's the place where it's possible to bypass any DRM without much issue. HDCP is useless [1][2][3], and unless Roku is failing to implement it right, my basic HDMI splitter from Micro Center is more than enough to strip it and feed info HDMI signal into a raspberry pi for ambient light effects. And in order for people to actually use ATSC 3.0 encrypted streams with an overwhelming majority of TVs on the market in use, folks will have to have some form of HDMI box that does the decryption anyway...
Cheap HDMI splitters often have the HDCP circuit only on the incoming side and send decrypted signal out of the receiving end.
You can easily bypass any HDCP signal with $25 worth of stuff off Amazon and record it to your local PC with FOSS like OBS or even the built-in camera softwares.
All this does is make people have to spend more money to get less service. It disproportionately negatively affects the poor for no social good.
The problem is the CVE score do work in most cases. A lot of organizations still prioritize updates based on their CVE score, and don't bother with updating unless it meets a certain threshold. If it doesn't meet that threshold, then they wait until their monthly patching cycle, or don't even bother updating ever at all.
Until that culture is fixed/adjusted, having a scoring mechanism that is easy enough for manager/executive type people to easily understand risk without any technical knowledge is important. Way easier to argue for an emergency patch/downtime that could cost money when there is a big scary 9 associated with it. And so if the scoring is off and not accurately representing risk, let's work to improve those scores, rather than getting rid of them.
Plus, there is a reason environmental scores exist in the CVSS mechanizm, as it allows for folks to adjust the CVE number to better fit their environment and specifications. I'd personally rather see more CVEs appear and be tracked quickly for easier referencing and discussing, with a slightly adjusted formula to better reflect severity.
> The problem is the CVE score do work in most cases. A lot of organizations still prioritize updates based on their CVE score, and don't bother with updating unless it meets a certain threshold. If it doesn't meet that threshold, then they wait until their monthly patching cycle, or don't even bother updating ever at all.
That doesn't mean it works; that could just mean organizations either a) don't understand the actual severity of their own vulnerabilities, and prioritize fixes based on an incorrect metric; or b) recognize that the CVE score is garbage, but don't want to appear to their users as ignoring or de-prioritizing supposedly-severe issues.
They do not work in most cases. They provide psychological comfort to enterprise IT teams, but so would a literal Ouija board, as long as you hid it from the people using them. Obviously, the "environmental score" component of a CVSS is an admission that the whole system is intellectually bankrupt.
I'd be interested if you could find a serious vulnerability researcher (say, anyone who has given a Black Hat talk or submitted a Usenix WOOT paper) who'd be willing to defend CVSS. My perception as an (erstwhile) practitioner is that CVSS is sort of an industrywide joke.
The nature of the url being "projectobs" instead of "obsproject" is concerning, and while there appears to be no download links hosted on the site, just redirects to GitHub's downloads, this looks concerningly like one of those SEO spam pages. Further research shows that it likely isn't the case at the moment, just a means to slap ads onto the official wiki docs: https://github.com/obsproject/obs-studio/issues/2565. Still concerning none-the-less.
There is still a large amount of friction in keeping a game though. These types of DRMs can cause the game to be unplayable years later. Like when Alder Lake came out and a bunch of games with Denuvo DRM broke [1]. Because of all of this recent attention on it, I wouldn't be shocked if it resulted in less sales and higher rates of emulation. Probably not enough to cause a dent in sales to disincentive addition of DRM though sadly.
Cloudflare also outlines the following reason in the linked blog post:
> "The reason this matters so much is that the maximum size of an unsigned UDP packet is typically 512 octets. DNSSEC requires support for at least 1220 octets long messages over UDP, but above that limit, the client may need to upgrade to DNS over TCP. A good practice is to keep enough headroom in order to keep response sizes below fragmentation threshold during zone signing key rollover periods."
