Every time people hear what it actually involves is outrage and opposition, at least all the way back to when Intel first announced that they wanted to hardcode identity numbers inside CPUs in 1999. But the corporations involved have been relentless, and have sunk countless billions of dollars steadily forcing it forwards, and building front organizations to obfuscate and whitewash it.

With Windows 11, Microsoft was finally able to FORCE Trusted computing hardware into every new computer. Not just every new Windows computer, but every computer.

Every new Intel PC CPU has built in Trusted Computing enforcement hardware. Every new AMD PC CPU has built in Trusted Computing enforcement hardware. Every new ARM PC CPU has built in Trusted Computing enforcement hardware. The only processor lines that DON'T have it are the microcontrollers.

There are some unlocked smartphones available, but as far as I can determine it's literally impossible to buy a smartphone that doesn't have hardware trusted computing built in.

I specified that enforcing Trusted Computing at the internet access level is still a long term goal, they couldn't get away with it today. However they are well on the way to success. Virtually all new hardware supporting trusted computing, all the front groups rolling out standards and systems, and as it gets incorporated into things everyone is going to increasingly running into situations where they get locked out of stuff if they're not Trusted Computing compliant. Streaming already restricts you to the worst quality if you're not compliant, and it's only going to get worse as pre-Win11 computers fade out and as more things require it.

I'd hardly call exact date of birth "low information content".

And yes this does reveal exact date of birth, regardless of the bullshit obfuscation that it supposedly only reports age range. The server simply tracks the reported result every time the user connects, and on some specific day the result CHANGES to announce their date of birth.

-

This is based on SLSA (Supply-chain Levels for Software Artifacts), brought to you by the same fuckers making Trusted Computing and the TMP (Trusted Platform Module). It's part of the same shitstack to prohibit you from altering your software and to lock you out of your own files, and to send spy reports out over the internet so you can be cut off if you "fail" the Trusted Computing check.

The software can use a TPM's (Trusted Platform Module) Sealing function to encrypt your data such that it's impossible to access your own data if the software is modified. It can then pass control over that data only to software updates that carry a signed security certificate from Broadcom (or any other company using this system).

It is no longer open source, your system no longer works as you can no longer access your Sealed data if you change so much as a single letter of the code. Even recompile unaltered code won't work, unless you magically manage to get your build environment absolutely identical to the company's build environment and get byte-for-byte output. Even that may be impossible with the newer levels of non-deterministic compiler optimizations.

Also, with TMP's Remote Attestation feature can be used to transmit your machine's software configuration over the internet, so that you can be cut off if your system doesn't match Broadcom (or other company's) cryptographically signed certificate.

And then of course there's Network Access Control (NAC) / Trusted Network Connect (TNC). In the long term, the goal is for ISPs to use NAC/TNC to interrogate your computer for Trusted Computing compliance, and deny you any internet access whatsoever if your machine isn't compliant. Software with this sort of "security" certificate would pass inspection, while any attempt to alter the code would be detected as "tampering". You then get "quarantined". What "quarantine" means is that you are denied internet access - with the exception that you do get very restricted access which can only be used to download the approved software to "fix" your computer into Trusted Computing compliance.

It's eh-I you hoser

Google, Microsoft, Apple, Facebook, Amazon, or another one of the big software development companies could easily fork ffmpeg itself, fix the open CVEs, provide their own (likely incompatible) features, and become the new standard - leaving the original developers out in the cold. Google did this with Blink (forked from WebKit, which itself was forked from KHTML). They took a fork of a KDE backed project, put it into what is now the #1 browser in the world, allowed Microsoft, Opera, and others to then use it in their own browsers — and now Google owns the entire narrative and development direction for the engine (in parallel to, and controlled to a lesser extent by Apple which maintains WebKit). The original KHTML developers really couldn’t keep up, and stopped maintaining KHTML back in 2016 (with full deprecation in 2023).

That is the risk for the original developers here. You’re right in that there isn’t really anything out there that can do what ffmpeg does — but if the developers don’t keep up on CVEs then organizations are going to look for new maintainers — and a year or two from now everyone will be using the Google/Microsoft/Apple/Facebook renamed version of ffmpeg instead.

That’s the shitty truth of how these things work. We’ve seen these same actors do it before.

Yaz

Look — I’m a developer. I get it. I’m personally all for having organizations do more to support the OSS they rely on. But the people in the C-suite are more worried about organizational reputation and losing money to lawsuits. If a piece of software they rely on has a known critical CVE that allows for remote code execution and someone breaks in and steals customer data — that software either needs to be fixed, or it needs to be scrapped. Those are the choices. Our customers in the EU are allowed to request SBOMs of everything we use and pass it through their own security validation software — and if they find sev critical CVEs in software we’re using there is going to be hell to pay. And the people in the C-suite can’t abide that level of risk.

Most software development companies (outside some of the biggest ones) don’t really have the kind of expertise in house to supply patches to something as complex as ffmpeg. But a company like Google has the staff with sufficient experience in this area that they could fork the project, fix the issues, and redistribute it as their own solution to the problem — and now Google is driving ffmpeg development. Organizations that need a security-guaranteed version will simply switch to Google’s version, which will likely slowly become incompatible with the original. They’ve done it before — Chrome was Google’s fork of WebKit, huge swaths of users flocked to Chrome, and now Google has over the years made enough changes that their patches often aren’t compatible with WebKit (and, of course, WebKit itself did similar when they forked KHTML).

Now forking like this is great for the community, but it can be tough on individual developers who see their work co-opted and then sidelined by massive corporations. And that’s really why the ffmpeg developers need to be very careful about ignoring CVEs like this. They do so at their own peril, as anyone can fork their code, fix the issues, and slowly make it incompatible with the original. And a big enough organization can ensure they’re fork becomes the new standard, leaving the original developers out in the cold.

Yaz

That, or your project gets sidelined. Which is where the danger lies.

I work for a big multinational software company that uses a lot of Open Source Software. We have a security office that audits all of our products several times a year. If any piece of our stack shows any open CVEs we have a fixed amount of time to fix the issue, with the amount of time varying from a few days (for CRITICAL severity issues) to roughly half a year for the lowest severity issues. A lack of a fix for a published CVE isn’t an excuse for not fixing the issue on our end — the software still has a security flaw in it, and the organization is so incredible security averse (thanks in part to having contacts in the defence industry) that they don’t want to risk expensive lawsuits and the loss of reputation if a vulnerability is exploited.

A lot of bigger organizations now work this way. We’ve all seen what has happened to organizations that have had significantly security breaches, and it’s not pretty. Our customers are big corporations and government entities — and if they even sniff a risk there are going to be problems. So if there is an unpatched exploit, we’re expected to either switch to something comparable, or DIY a solution (either replacing the library in question, or potentially patching it ourselves).

If ffmpeg allows known and published vulnerabilities to languish, the risk here is that organizations that use their code will simply stop using it and will look for other solutions. That’s a tough pill for an Open Source Software developer to swallow, especially when they make it as big and important as ffmpeg. You might wind up in a situation where an entity like Google forks your code and takes ownership, and eventually gets everyone to migrate to using their version instead (like what they did with WebKit to Chrome), leaving you sidelines. Or maybe someone else jumps in with a compatible solution that works well enough for enough users that they switch to that instead.

Now in an ideal world, the Google’s of this world would not only submit a CVE but would also submit a patch. Having been an OSS developer myself I’ve always encouraged my staff if they find a bug in a piece of software we use to file a bug report and ideally a patch if they know how to patch the issue correctly — but I know that is hardly universal within our organization, and probably even less so elsewhere.

TL;DR: a lot of OSS success relies on having lots of users, or at least some big and important users. But you risk losing those if you leave CVE’s open for too long, as company policies may require scrapping software with unfixed CVEs. That loss of users and reputation is dangerous for an OSS project — it’s how projects get supplanted, either by a fork or by a new (and similar) project.

Yaz

We MUST be able to inspect and age verify every AI slop porn image to protect the fictional children!

-

If you read the article carefully, they are talking about lenses THINNER than a hair. I see several of the posts here thinking the width/radius of the lenses is this small, a reasonable mistake given the way this was written. Having a radius that small would severely reduce their light gathering ability, requiring very bright light or very dim images or very long exposure times.

-