It depends on how much logic and/or arithmetic you can get away with encoding into the type system. We abuse the heck out of it to restrict things like register & field access, state-machine transitions, and also track resource allocation/consumption. That said, it's incredibly painful to develop anything that way, and it also doesn't ultimately prevent a different problem of the "model" you've written down in the types being wrong. So, it's not a panacea, and it's incredibly difficult, but it can winnow down the surface area of potential problems and bugs... or at least move them to compile-time.
> Rust is where it is going for cryptocurrencies that need to have very secure smart-contracts
There is an implication here that Rust will help make smart contracts "secure", but AFAIK the vulnerabilities in smart contracts have been in their logic, not in their memory/type safety or whathaveyou.
This is standard practice. Most SaaS IT departments negotiate big rebates in exchange for long term commitments, and those who don't are leaving money on the table. I've seen datacenter deals over 10 years that looked far worse.
Anyone who has managed a product security program will tell you that's it's impossible for small groups to keep up with the complexity and attack surface of products like android.
From a consumer perspective, going with A and trusting the company is by far the safest option.
Meh. Given the option of a secure but adversarial OS and less secure but open one, I will always pick the latter. Then at least there is a fighting chance my data stays mine.
You're missing the other 'halves' of the problem. Insecurity is a business and it's not profitable for companies like NSO to make their "solutions" compatible with non-mainstream devices.
Sorry to be a pedantic but: Two People created CopperheadOS, one of them now works on GrapheneOS. The security mitigations developed for those were incorporated upstream into Android, decreasing the attack surface.
> Two People created CopperheadOS, one of them now works on GrapheneOS.
No, that's not true. GrapheneOS is the continuation of the project by the original development team. There aren't any developers who stuck with Copperhead. The project was created 1 year before Copperhead existed as a company.
> The security mitigations developed for those were incorporated upstream into Android, decreasing the attack surface.
https://grapheneos.org/features is a list of the current features differentiating it from AOSP. It doesn't list the many things we've gotten into upstream projects, since they aren't differences anymore.
See grapheneos.org/history/copperheados and verify it for yourself using Github graphs and other resources.
A better description would be "One person handled development of the project and other person CEO'd the sponsor company. The CEO attempted to hijack the project and the developer eventually resumed the project under the name GrapheneOS."
I can appreciate that but option A actors are now in full dictator mode with respect to how they are willing to breach privacy and monetize their users.
APK is an antiquated format that originates from Java Jar over two decades ago. It's basically a zip file with some internal structure for signing a manifest of hashes. Google already had to bastardize the APK format to move the signature to ZIP metadata, but there were still tons of problems around key rotation and distribution of large APKs.
This is a natural evolution of the format. It's good for the ecosystem. Whatever guarantees were supposedly provided by having developer (poorly) store their own signing keys are better handled by Google's own infrastructure.
