This bug just lowers the security level at worst to the one present on a regular desktop OS... for the file metadata.
I wonder how the fix for that one will look like.
Yet another macOS privacy protections bypass
21–30 of 94 posts
Re: Yet another macOS privacy protections bypass
#22This limitation of the macOS sandbox has always driven me nuts. Even with a default deny macOS sandbox profile (much stronger than anything that entitlements or TCC can apply, but pretty close to the restrictions some Chrome/Safari processes will run with) you still get an ENOENT instead of EACCESS when trying to access a path that doesn’t exist. I understand not applying that behavior in default sandbox profiles but for apps that are built to run some processes in extremely aggressive sandboxes like browsers it would be a real benefit.
Re: Yet another macOS privacy protections bypass
#23> 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.
From early on, Android had strict separation of files across apps. I would think users are generally aware and expecting that apps do not have full access to all of their data.
Re: Yet another macOS privacy protections bypass
#24> 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.
On unix systems that still use a 1970s permissions model, this is true, but it's been fixed on mobile devices for ages, and macOS desktops for over a year (this bug notwithstanding).
Ransomware (enabled by bitcoin payments to anonymous recipients) really changed the game on desktop in the last few years. Apple stepped up, but there's crickets on the matter in Windows- and Linux-land, aside from the people who have been containerizing their desktop apps[1].
[1]: https://github.com/jessfraz/dockerfiles/blob/master/chrome/s...
Re: Yet another macOS privacy protections bypass
#25Okay, this is a serious issue and I want this to be taken seriously by Apple.
What can I, as a reader, do? Is there someone to forward this to? Is there a person in Apple to email? Or are we hoping for a tweet storm to stir the water?
Re: Yet another macOS privacy protections bypass
#26Okay, this is a serious issue and I want this to be taken seriously by Apple. What can I, as a reader, do? Is there someone to forward this to? Is there a person in Apple to email? Or are we hoping for a tweet storm to stir the water?
"vote with your wallet" would say some purists.
Re: Yet another macOS privacy protections bypass
#27Earlier 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.
> 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.
Re: Yet another macOS privacy protections bypass
#28Okay, this is a serious issue and I want this to be taken seriously by Apple. What can I, as a reader, do? Is there someone to forward this to? Is there a person in Apple to email? Or are we hoping for a tweet storm to stir the water?
Upvote this and take to Twitter.
Re: Yet another macOS privacy protections bypass
#29Earlier quoted context omitted.
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…
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?
Re: Yet another macOS privacy protections bypass
#30Okay, this is a serious issue and I want this to be taken seriously by Apple. What can I, as a reader, do? Is there someone to forward this to? Is there a person in Apple to email? Or are we hoping for a tweet storm to stir the water?
[deleted]