3 ms·
> This is never acceptable as it undermines the entire security architecture. Private APIs for security reasons? Sure. For this? Garbage. There is not a singl
by FireBeyond 2y ago
> This is never acceptable as it undermines the entire security architecture.
Private APIs for security reasons? Sure.
For this? Garbage. There is not a single cogent reason that a color temperature API is a security gate. Or if you think there is, what is it?
- miki123211 2y agoIn Apple nomenclature, a private API is an API that your app is technically allowed to call, but that is subject to change at any moment and has 0 documentation and no backwards compatibility guarantees. If Apps were allowed to rely on those, they could just stop working across minor version upgrades or on new devices. Those APIs are only there because they're needed by some higher-level system library that your app is actually allowed to use. Sure, you could have all libraries be simple shims, all calls be interprocess, and all security be guaranteed by process boundaries, but that would kill performance. If you only accept signed code and have W^X protections that apps aren't allowed to disable, this way is simpler, faster and just as secure.
- saagarjha 2y agoNo, all security-sensitive API surface requires being on the other side of a process boundary (and checks on who is allowed to talk to it). “Signed code” is not a thing given that you can just ship an app that can do anything and have its behavior change at runtime (that’s what an interpreter is!)