Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You can't trust macOS Privacy and Security settings

eclecticlight.co

Post reply on HN
Print view View original

111–120 of 175 posts

Re: You can't trust macOS Privacy and Security settings

#111

Post by josephcsible »

jasonjei wrote: post #7

The problem with Mac’s sandbox system is that it’s giving me some PTSD of Windows UAC. It’s inventing a solution to a problem that might exist in small doses, but instead gives users permission fatigue. I personally think the traditional *nix model has served us quite well, and elective sandboxing using containers (à la Docker and so on) is quite good. The Mac sandbox model is probably ok for most normal users, but f…

> I personally think the traditional *nix model has served us quite well

It has the https://xkcd.com/1200/ problem on almost all end-user setups.

Re: You can't trust macOS Privacy and Security settings

#112

Post by cjcole »

lobf wrote: post #105
epistasis wrote: post #68

Earlier quoted context omitted.

I'm sure there are some great ones, but it was 5-10 years ago when I last read one, and it was fantastic. It's nearly impossible to do a web search for it right now, probably because of Google's bias towards recency. I know it's been linked on Hacker News many times, so maybe somebody else has better info here. Even if you're not an Apple fan, these sorts of stories are kind of great for learning about product develo…

You just reminded me of one of my favorite Jobs / Carmack stories: I had the privilege of working with John Carmack as a technology evangelist at Apple when he ported Quake III Arena to Rhapsody, Apple’s internal name for the OpenStep/Mach kernel based MacOS X. I enjoyed John's reminiscence about working with Steve and Apple and thought I would share a few of my own memories from that time which provided me with some…

"John wore a T-shirt that featured a smiley face with a bullet hole in the forehead from which trickled a few drops of blood"

Sounds like a Watchmen Comedian logo t-shirt. It could be construed as a bold choice but was probably just what was on the top of his t-shirt stack that day.

Re: You can't trust macOS Privacy and Security settings

#113

Post by kccqzy »

relaxing wrote: post #29
Angostura wrote: post #12

I think I’m probably being dumb, but the gotcha here seems to be - ‘if I give an application permission to access a folder, it has access to the files in that folder’ - which is what I would expect??

It’s really poorly written. After reading it all I still can’t figure out what’s the mechanism by which revoked permissions are hanging around, which is what would actually be interesting here.

It is poorly written. I have suspicion that the author is talking about the persistent file permission mechanism known as Security-Scoped Bookmarks, but the article makes it hard to understand what exactly is being discussed. It reads like a raw bug report without any analysis done.

And specifically they could show some code snippet to reveal what exactly the Insent app was doing. Was it calling startAccessingSecurityScopedResource of the NSURL class?

Re: You can't trust macOS Privacy and Security settings

#114

Post by kccqzy »

lapcat wrote: post #100
ezfe wrote: post #95

Earlier quoted context omitted.

Doesn’t seem like a bug to me - it’s just a poor UI. Two different security systems both working properly but only one has a UI to show the protections.

Why would you think it's "working properly"? The app somehow gained a permanent permission that I didn't give and that I can't remove no matter what I do. That's not working properly in any sense.

It’s working properly in the sense that the Apple-provided file picker UI is designed to give permanent file permission access to an app. But the user thinks that access is temporary. It’s a mismatch between the user’s mental model and what’s actually happening.

Re: You can't trust macOS Privacy and Security settings

#115

Post by what »

tpmoney wrote: post #51
mh8h wrote: post #35

Earlier quoted context omitted.

That's not what's happening here. Forget about the first 5 steps. If you install the app and start from step 6, the behaviour will be the same. If the user chooses the Documents folder in the browse window in an app, the app can use the contents of the Documents folder without the need for that permission in the Settings page. The Privacy settings applies only to access to the Documents folder without the user intera…

I think the issue here though is that the permission for access remains even after you're not using the open/save dialog and that's not obvious (or controllable from the UI) after the fact. I think it's reasonable to expect that an application gets access to a file you access through open/save, but the fact that the access to the directory and all the items in that directory persists after that isn't necessarily expe…

Isn’t it exactly the same on iOS? If you select a folder, the app gets a security scoped URL for the folder and can read/write the entire tree. The app can also then create a bookmark to persist the security scoped url and use it whenever in the future.

Re: You can't trust macOS Privacy and Security settings

#116

Post by nottorp »

Actually there is another way to reset the permission besides running tcutil reset.

Simply go to Security and Privacy and turn the permission on then back off :)

What happens here is the UI displaying the permission state is buggy, but the permission actually works. It's just hard to see its state.

Buggy UI, modern Apple...

By the way there is another problem with that UI. The checkbox is blue when on and grey when off... but only when the window has focus. When the window is not focused it's grey in both cases. Different greys but still greys. And if you don't spend all day looking at checkboxes in Mac OS, you may forget if left or right is on.

And this is on Sequoia not .

Edit: I wonder if a reboot would also make security and privacy read the status properly. But it would ruin my uptime, so I'll let someone who has an OS update to install check :)

Edit 2: And I just noticed. I have a TB drive hanging off my Mac Mini and my games are on it. So there's a bunch of games in security and privacy (mostly crossover entries, but also for example euro truck simulator which is native) because they requested access to "removable volumes". No shit, they're installed on said removable volume.

Re: You can't trust macOS Privacy and Security settings

#117

Post by KaiMagnus »

lobf wrote: post #105
epistasis wrote: post #68

Earlier quoted context omitted.

I'm sure there are some great ones, but it was 5-10 years ago when I last read one, and it was fantastic. It's nearly impossible to do a web search for it right now, probably because of Google's bias towards recency. I know it's been linked on Hacker News many times, so maybe somebody else has better info here. Even if you're not an Apple fan, these sorts of stories are kind of great for learning about product develo…

You just reminded me of one of my favorite Jobs / Carmack stories: I had the privilege of working with John Carmack as a technology evangelist at Apple when he ported Quake III Arena to Rhapsody, Apple’s internal name for the OpenStep/Mach kernel based MacOS X. I enjoyed John's reminiscence about working with Steve and Apple and thought I would share a few of my own memories from that time which provided me with some…

Very cool story. Now I’m wondering if this event happened sometime during this section from one of Carmack‘s own posts:

> I was brought in to talk about the needs of games in general, but I made it my mission to get Apple to adopt OpenGL as their 3D graphics API. I had a lot of arguments with Steve.

https://old.reddit.com/r/Games/comments/8l9qw2/john_carmack_...

Re: You can't trust macOS Privacy and Security settings

#118

Post by MetaWhirledPeas »

lobf wrote: post #105
epistasis wrote: post #68

Earlier quoted context omitted.

I'm sure there are some great ones, but it was 5-10 years ago when I last read one, and it was fantastic. It's nearly impossible to do a web search for it right now, probably because of Google's bias towards recency. I know it's been linked on Hacker News many times, so maybe somebody else has better info here. Even if you're not an Apple fan, these sorts of stories are kind of great for learning about product develo…

You just reminded me of one of my favorite Jobs / Carmack stories: I had the privilege of working with John Carmack as a technology evangelist at Apple when he ported Quake III Arena to Rhapsody, Apple’s internal name for the OpenStep/Mach kernel based MacOS X. I enjoyed John's reminiscence about working with Steve and Apple and thought I would share a few of my own memories from that time which provided me with some…

I've lamented some of the decisions Apple has made over the years, one of them being to treat games and people who play them as second-class citizens. Marathon was a very good game but the main reason it was successful is because it was an oasis in the middle of a gaming desert.

Re: You can't trust macOS Privacy and Security settings

#119

Post by lapcat »

kccqzy wrote: post #114
lapcat wrote: post #100

Earlier quoted context omitted.

Why would you think it's "working properly"? The app somehow gained a permanent permission that I didn't give and that I can't remove no matter what I do. That's not working properly in any sense.

It’s working properly in the sense that the Apple-provided file picker UI is designed to give permanent file permission access to an app. But the user thinks that access is temporary. It’s a mismatch between the user’s mental model and what’s actually happening.

> It’s working properly in the sense that the Apple-provided file picker UI is designed to give permanent file permission access to an app.

In the case of sandboxed apps, this is not true. The open panel provides temporary access, and a sandboxed app needs to create a security-scoped bookmark to retain persistent access across launches.

For non-sandboxed apps, it's usually not an issue, because non-sandboxed apps have access to most of the file system by default. The weirdness occurs only for certain files and folders that are restricted by TCC, such as Desktop and Documents. But for non-restricted folders, nothing needs to be done. Observe that if you use the Open from folder... command from Insent on a non-restricted folder, then no com.apple.macl is set on the folder. No special permanent access is granted, because none is required. The only time the system automatically grants permanent access is with TCC-restricted files and folders, so we can't pretend that this is a "normal" thing.

In general, non-sandboxed apps don't even need the open panel for file access. They can just read whatever file they want... except for the TCC-restricted files. The purpose of the open panel in a non-sandboxed app is just to provide a file picker UI to the user.

Re: You can't trust macOS Privacy and Security settings

#120

Post by saagarjha »

jeremyjh wrote: post #96
mh8h wrote: post #46

Earlier quoted context omitted.

You don't need that permission if the user gives their implicit consent by selecting the Documents directory in the browse window. That's why most apps don't even show up in the Privacy Settings at all. Most apps don't need that, because they don't try to access that directory on their own. They only do it when the user selects the directory. I guess the improvement can be to show the implicit consent in the privacy…

I don't think any long-term implicit consent is acceptable. I would not expect that after opening one document in a folder without being shown any permission prompt, that permissions have been permanently altered. I would never even go look to see if it was "implicitly permitted". Without a prompt or notice, I would expect only that the app has access to the file or directory I chose until the app is closed/quit.

How would the app be able to reopen the file then?
Post reply on HN