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

I would appreciate these disclosures a lot more if the author didn’t always include a flippant dismissal of security architecture improvements in macOS. Yes, it’s harder to write software with sandboxing and other modern security techniques, but that doesn’t mean we should go back to how things were.



It's not flippant, read through the author's history: https://lapcatsoftware.com/articles/index.html

This is a serious stance of his, with a lot of serious data and arguments to back it up, from a serious engineer who has written an impressive list of Mac software both for Apple and for Apple's customers.


You did use the word serious enough to make it compelling. But the author’s biography doesn’t mean that his comment wasn’t flippant.

He’s proved that an well-behaved, codesigned app can list file metadata about files in restricted directories. He hasn’t proven the sandbox compromised.

You claim he has so much serious evidence, link us there. Don’t just string adjectives together.

I have great respect for Jeff, but he is one of the more outspoken complainant Apple devs. At least he has a better basis for his commentary than DHH.


A well behaved, codesigned app being able to list metadata about files in restricted directories is a sandbox compromise. In what viewpoint is it not?


As pointed out by the most voted top level comment it's a kernel issue.


That doesn't mean it's not an issue.

I would like Apple to not roll out BS prompts that make my life more difficult until those prompts are actually capable of protecting some of the most sensitive data on my machine.


A kernel issue where it fails to adequately enforce the sandbox?


whatever man. you had a good go at me the other day. you're right I'm wrong, and HN is no longer the place for me


Did I? The only other interaction I had with you recently that I can find is a discussion about Apple's security policies, which seemed fairly reasonable to me.


The biggest issue with the author is that he complains both about the controlling/locked down nature of Apple’s platforms and about any bugs that show up in that system.

I.e. His goal is to criticize Apple no matter what they do, because he dislikes the fact that they are no longer producing the kind of open system he prefers.


I think the angle he has is “Apple should remove these protections because they can’t implement them correctly”.


Yeah, which doesn’t seem reasonable, especially when mixed in with a bunch of assumptions about ill intent.

There are an enormous number of protections and a small number of issues, which do eventually get fixed, and of course the threats are undeniable.

However you are right that Apple is notoriously had at communicating about bugs.


At least in this case, the lack of reaction from Apple shows that his accusations are not baseless. Don't blame it on the messenger.


My thoughts exactly. If this was just an overlooked bug, which was reported to Apple and which Apple then fixed, that would be the system working as intended.

In reality, a very simple bug was reported more than a year ago, and Apple apparently hasn't cared enough to fix it. The only way I can interpret that is to conclude Apple doesn't really care about the integrity of their sandbox.

IMO, this more than justifies the author's accusation of "security theater". My browsing history is among the most sensitive data on my machine—certainly more private than anything in my Documents folder, which Apple felt the need to protect in a highly-disruptive way. I agree that it can be worth trading some degree of usability for privacy and security, but only if those privacy benefits are real. If they're not, then we're left in the worst of both worlds.

It's really quite damning.


> 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.


These security features are only nominally about protecting the user. Apple implements them to protect their services and platforms from competition and sells them via the privacy argument.

Does it happen to improve the security situation? Yes, for many people it does. Is it worth the cost? That's debatable, especially because of Apple's apparent apathy (and occasional hostility) towards the community.


> These security features are only nominally about protecting the user. Apple implements them to protect their services and platforms from competition and sells them via the privacy argument.

Stallman[1] and others[2] have talked about just this issue for over a decade now.

[1] https://www.gnu.org/philosophy/can-you-trust.en.html

[2] https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html


This is explicitly untrue.


Haven't you ever thought that the flippant attitude is exactly why you are able to learn of this now (and not 10 years later/if at all)? If everyone was "policy abiding" folks who will give a megacorp the benefit of the doubt, these won't be disclosed for years.

The flippant attitude is exactly why and how you are reading of all these vulnerabilities now.

Knowledge of the issue (but enduring "flippancy") or not knowing it at all? You pick.

What I'm really saying is that this "flippancy" is the agency that's making someone write a blog post, sign their name to it, put it out there with code samples, etc. You dismissing "flippancy" is insulting the agency of this. Without that emotion, that idea where they thought Apple wasn't treating them well, that is the source where people find the energy to publish, to publicise.

Every single word takes strength to write. In this case, the flippancy was the driving force and it shows clearly.

Why would you dismiss that energy?

And no, it's not the author's job to "shield" you from the wrath of their flippancy. I take it and I thank "flippancy" for disclosing this issue.


We shouldn’t put the burden on the bug finder to be “nice” and persistent about doing Apple’s job for them. We should put the burden on Apple - the first trillion dollar company - to take bug reports seriously. Given that iOS and macOS have pretty novice security vulnerabilities (allowing apps to view Safari browsing history, allowing iOS apps to detect if a device is jailbroken), why is it up to the bug finder to be nice about it?


Then you should probably stop reading security disclosures. Security researchers tend not to be terribly considerate of egos.

> but that doesn’t mean we should go back

I don't think you understand the author's stance.




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

Search: