Yet another macOS privacy protections bypass
lapcatsoftware.com
Yet another macOS privacy protections bypass
1–10 of 94 posts
Re: Yet another macOS privacy protections bypass
#2I 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.
Re: Yet another macOS privacy protections bypass
#3Is this also the case when replacing the stock ls binary with the one from GNU coreutils?
Re: Yet another macOS privacy protections bypass
#4I 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.
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.
Re: Yet another macOS privacy protections bypass
#5I 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.
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.
Re: Yet another macOS privacy protections bypass
#6I 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.
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.
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.
Re: Yet another macOS privacy protections bypass
#7Earlier quoted context omitted.
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.
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.
This is explicitly untrue.
Re: Yet another macOS privacy protections bypass
#8> I chose the example of ~/Library/Safari/LocalStorage because Safari names the files in this directory according to the web sites that you visit! Also note that the output of long format ls -l contains the last modification date of the files. Thus, one possible privacy violation from this technique is to learn the user's web browsing history.
Its a pretty serious issue if any random app can read your browsing history. Even more so that Apple hasnt fixed it more than one year after the author reported it.
Re: Yet another macOS privacy protections bypass
#9I 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.
Re: Yet another macOS privacy protections bypass
#10> I chose the example of ~/Library/Safari/LocalStorage because Safari names the files in this directory according to the web sites that you visit! Also note that the output of long format ls -l contains the last modification date of the files. Thus, one possible privacy violation from this technique is to learn the user's web browsing history. Its a pretty serious issue if any random app can read your browsing histor…
If that is a serious issue, it says a lot about how goalposts have moved the last decades. We haven't been able to expect anything less than every program being able to read all your files.