Hacker News new | past | comments | ask | show | jobs | submit login

> The only way I can interpret that is to conclude Apple doesn't really care about the integrity of their sandbox.

There are many other ways to interpret it. Here is one completely made-up example that I created just now for this reply:

"Apple can't lock this down further without breaking open() calls in the majority of existing applications; therefore, they made a pragmatic choice to allow this issue to exist until their long-term roadmap plan to remove direct disk access to protected folders ships in a future macOS update; while declining to share their decision with the reporter, as is completely normal for Apple."

If you define "security theater" as "any practice that would not stand up to a human attacker", then all security is guaranteed by definition to be security theater, since all security protections will be found to have weaknesses, compromises, and design decisions that could be theoretically exploited. That definition is clearly non-viable in reality, and so all security decisions — even Apple's — will have unpalatable outcomes that do not invalidate the relevance of security.




> while declining to share their decision with the reporter, as is completely normal for Apple

This is completely normal for Apple, but that doesn’t make it OK for them to treat security fixes like product launches where they can choose an arbitrary timeline and keep the reporter hanging forever.


Sure but it also doesn’t justify innuendo about Apple not caring about privacy.

You know as well as I do that this stuff is complicated.


Yeah, it probably is; maybe it requires substantial changes in the kernel or something. The issue is that Apple never communicates this, they just sit on bugs until they fix them. This is a really poor experience for people reporting issues.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: