Because the Linux Foundation says so. I would guess it’s because most of the relevant tech started as cloud products or services and got generalised, such as Kubernetes (the big one in CNCF).

The naming wasn’t up to Bazzite or uBlue to decide, that’s for sure, and the term “cloud native” has won the mindshare of developers.

The irony hits hard when you’re logging into an on-prem Kubernetes cluster in your company’s wholly owned data centre. At that point, “cloud” isn’t even someone else’s computer (as the FSF would say).

From what I’ve heard at work and from others, MS uses version queries to stall tickets because they constantly release updates that they can point to and say “you need to update before we can help”.

No, Play Integrity intentionally checks if it’s a Google-approved key. Android itself has an API to check verified boot and gives info on the signing key - most devs just want to know verified boot is working.

I feel Play Integrity has a short life ahead of if competition authorities realise how exactly it works. “Anti-competitive” is the first thing policy-minded folks think when I explain the API to them.

For GrapheneOS, it’s primarily that it’s re-lockable. That’s why other unlockable phones aren’t supported.

The GrapheneOS install process sets new OS signing keys so you can lock the phone again and get full verified boot. However, most manufacturers haven’t implemented this feature.

I think it might be confusion between inspecting plaintext metadata like SNI vs actually inspecting encrypted contents (e.g. HTTPS content, headers, etc.).