Live data from Hacker News

You can't trust macOS Privacy and Security settings

eclecticlight.co

101–110 of 175 posts

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

#101
post #94
post #77

So the title should be something more like "macOS apps retain access to folders after access is removed by the user".

Nope. The user is not revoking the access that they granted. They are revoking general access to a folder, but since there is no way to revoke specific access nothing happens.

Its both. They can never revoke access to a folder they opened/selecte in the app UI, and aren't notified that the app has permanent access.

But also, once they've explicitly granted access, and then implicitly granted access to the same folder, disabling explicit access changes nothing.

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

#102

Earlier quoted context omitted.

You “feed” it the document. Same way you select a picture on iOS. It is your deliberate decision and intent to open the document with that application. That is totally different from the application having permission to scan and view anything in for example the downloads folder

When you use iOS's "limited access" permissions to give an app access to some of your photos but not the whole library, the photo picker UI does a pretty good job of letting you easily do three things: 1) Grant access to a photo 2) Identify which photos you've granted access to 3) Revoke previously granted access macOS's concession to give access to whole folders at a time is necessary for real software to work, but…

Sure.

But the proper api call to make is selecting a picture. Not access to the photo library. That is an api design flaw, and simply a bad / obsolete implementation by the app developer.

The complaint of the OP is that he can still open a file which is in the downloads folder. But that’s not what the user is doing.

There’s no reason to give folder access at all. (Except for file sorting apps etc).

The only “reason” would be that it’s more difficult for developers to atomically overwrite a file in the same locations. And quite frankly, they should (and perhaps already do) have api calls for exactly that. I think this is why many apps request access sometimes.

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

#103

There's another "security UI" issue in the latest macOS, that's been there for at least a few versions. I go into "Privacy & Security", "Full Disk Access". A bunch of apps added themselves in there (Anki, Fission, Microsoft Autoupdate, WhatsApp), the toggle is disabled and I've never enabled it. Ok, whatever. But when I go into "Files & Folders", and under those apps I see "Full Disk Access" in gray. Apps that have F…

That is really poorly worded by Apple, because if I understand it correctly, the "Files & Folders" list is just a list of apps that have requested Full Disk Access/FDA (or other locations).

It's really confusing that some of those settings can be toggled on/off, while the Full Disk Access is greyed out and can only be toggled under "Privacy & Security".

To add to the confusion, toggling FDA off just protects a few selected folders that Apple decided are extra sensitive, like:

  Messages                     ~/Library/Messages
  Safari browsing history      ~/Library/Safari
  Cookies                      ~/Library/Cookies
  Identity services            ~/Library/IdentityServices
  Spotlight data               ~/Library/Metadata/CoreSpotlight
  Phone call history           ~/Library/Application Support/CallHistoryDB
  Facetime data                ~/Library/Application Support/Facetime
  TCC database                 ~/Library/Application Support/com.apple.TCC.db
"Normal" files and folders on your disk (including Desktop, Documents, Downloads, network volumes, and removable volumes) can always be accessed (even with FDA permission revoked!) after a simple prompt. [1]

[1] https://support.apple.com/guide/security/controlling-app-acc...

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

#104
post #72

Is this a bug, security vulnerability, or just an oversight? It’s not clear to me. As a precaution would it be a good idea to run that reset command for all apps?

These are considered security UI bugs. They are a subcategory of security bugs, since they result in users lacking control or awareness over permissions. If this were a Chromium bug it would get a CVE.

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

#105
post #65

Earlier quoted context omitted.

Is there a common source/collection of such stories?

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 of the most satisfying moments and lessons of my career.

John was the first game developer I ever worked with. Three weeks after I sent him development hardware (an iMac) he informed me that the PC and Mac versions of Quake III Arena were in “feature parity.” I still recall my shock upon reading that email from him.

John agreed to come to Cupertino and meet with several teams to share his development experiences with them. I picked him up in the lobby of the Fairmont Hotel in downtown San Jose. He stood unassumingly in the lobby, framed in the background by a Christmas Tree.

On day one, we met with several internal teams at Apple. I was accustomed to see 3rd party developers emerge somewhat awed by their meetings with Apple engineers. In John’s case the reaction was reversed. I’ve never seen anyone grok complex systems and architectures so quickly and thoroughly as John. Amusingly, he walked around the Apple campus unrecognized by all but for the occasional, former NeXT employee.

On Day 2, John was to meet with Steve. I never knew whether it was by design or not, but on that day 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. After an hour of waiting for Steve in IL1, he marched into the room, and immediately mistook me for John Carmack, extending his hand to shake mine (we had never met). I locked eyes with Steve Jobs and looked down significantly at the Apple badge on my belt. Without missing a beat, Steve shifted his extended hand to John's.

That’s when Steve noticed the T-shirt and the meeting, as soon as it had begun, took a turn for the worse.

Steve’s jaw muscles visibly tensed and he became stone-faced. Clearly deeply offended by John’s T-shirt, he sat down at the conference table and looked straight ahead, silent.

John kicked off the meeting by saying, “So I’ve been working with MacOS for the past month and here’s what I learned.” His #1 concern (at an extremely high level) concerned OpenGL permissions and security for which he felt Apple needed a better solution than what he’d learned about the day before in meetings with the graphics team, even if it came at a slight cost in performance for 3D games. This was, suffice to say, typical of John in that he was approaching an issue from an objective engineering perspective and arguing for the most technically correct solution rather than pushing for something that might be of benefit to his personal projects.

Steve listened and abruptly said, “That’s not what we’re doing!” Then he looked at the three Apple employees in the room and asked, “Is it?” I confirmed that what John was raising as a concern came from a meeting with the graphics architecture team the day before. Without batting an eye, Steve stood up, tramped over to a Polycom phone and dialed from apparent memory the phone number of the engineering director whose admin informed Steve that he was at an offsite in Palo Alto. Steve hung up, sat down, and about 30 seconds later the phone rang with the engineering director on the line.

Steve said, “I’m here with a graphics developer. I want you to tell him everything we’re doing in MacOS X from a graphics architecture perspective.” Then he put his elbows on the table and adopted a prayer-like hand pose, listening to and weighing the arguments from his trusted director of engineering and from the game guy with the bloody smiley-face T-shirt. And what happened next was one of the most impressive things I’ve ever witnessed about Steve or any Silicon Valley exec. Early on in the discussion, the Apple engineer realized that “graphics engineer” in the room was John Carmack. And he realized that he was going to need to defend his technical decision, on the merits, in front of Steve. After extended back and forth, the Apple engineer said, “John, what you’re arguing for is the ideal …”

He never made it to the next word because Steve suddenly stood bolt upright, slamming both palms onto the desk and shouting, “NO!!!!”

“NO!!! What John is saying is NOT the ideal. What John is saying is what we have to do!!! Why are we doing this? Why are we going to all this trouble to build this ship when you’re putting a TORPEDO IN ITS HULL?!!!!”

All of this was said with the utmost conviction and at extremely high volume. To his credit, John, seated directly next to a yelling Steve Jobs, didn’t even flinch.

What was so impressive to me in that meeting was not the drama so much as it was that Steve Jobs made a decision on the merits to side with John on a technical issue rather than his longstanding and trusted graphics engineer. He overcame his original distaste for the T-shirt and made the right call. Most CEOs would have dismissed John’s comments or paid them lip service. Steve listened to both sides and made a call that would have long lasting implications for MacOS.

As a comical aftermath to the story, John next told Steve point blank that the iMac mouse “sucked.” Steve sighed and explained that “iMac was for first-time computer buyers and every study showed that if you put more than one button on the mouse, the users ended up staring at the mouse.” John sat expressionless for 2 seconds, then moved on to another topic without comment.

After the meeting ended, I walked John to the Apple store on campus (this was before there were actual Apple stores) and asked him on the way what he thought of Steve’s response to the mouse comment. John replied, “I wanted to ask him what would happen if you put more than one key on a keyboard. But I didn’t.”

Good call, John

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

#106
post #45
post #39

Earlier quoted context omitted.

This reminds me of the early days of MacOS where "repair permissions" was the magic fix to everything, or so it was rumored.

Whoa you are bringing back some memories. And it absolutely was a magic fix. I stand by it.

I remember verifying it really DID fix some problems (just not all) and it was so easy to do you might as well always do it.

(You could see permissions errors in the logs that would go away after running it, which often didn't really fix anything but could make it faster since it didn't have to error out.)

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

#107

Earlier quoted context omitted.

When you use iOS's "limited access" permissions to give an app access to some of your photos but not the whole library, the photo picker UI does a pretty good job of letting you easily do three things: 1) Grant access to a photo 2) Identify which photos you've granted access to 3) Revoke previously granted access macOS's concession to give access to whole folders at a time is necessary for real software to work, but…

Sure. But the proper api call to make is selecting a picture. Not access to the photo library. That is an api design flaw, and simply a bad / obsolete implementation by the app developer. The complaint of the OP is that he can still open a file which is in the downloads folder. But that’s not what the user is doing. There’s no reason to give folder access at all. (Except for file sorting apps etc). The only “reason”…

I'm trying to think of a scenario where a users hits Open and picks a directory but does not want the software to have access to the contents of that directory. If you don't want it to access a folder, then don't open a folder in it.

This behavior gets used all the time in things like opening a folder in your IDE so it can access the whole project.

The OS does allow file pickers that can only pick files and not directories (set canChooseDirectories = false), and if an app has no legitimate reason to need a directory they should do that, but the fact that you can grant permissions isn't the problem. What they need to fix is that you're granting permanent permissions with no indication that you've done it and no way to remove them.

To anyone at Apple reading this - please do not draw the conclusion "permissions to access a previously opened file or folder should expire after 24 hours" there are already more than enough permission prompts.

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

#108
post #72

Is this a bug, security vulnerability, or just an oversight? It’s not clear to me. As a precaution would it be a good idea to run that reset command for all apps?

It’s Apple’s performative “security” (showing popups and asking the user for all sorts of permissions) overlapping with some pragmatic choices about how files and folders work. For me the gap is in Settings & Privacy - 1) it should be clear that the app has been given permission and 2) it should be harder to give permission once you’ve explicitly disabled it. 3) (nice to have) Apple should get rid of permissions that make you restart the app because it’s 2026 lol.

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

#109
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…

Someone at Apple should watch some of their old ads. https://www.youtube.com/watch?v=8CwoluNRSSc

The best part is that this kind of popups have been introduced with OS X Lion in 2011, which only came 4 years after Vista.

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

#110

Eye-opening findings. After reading the article I revoked every folder permission and tested: Insent still reads Documents even when the UI shows "None". This is a serious trust failure; transparency is supposed to be the whole point of those preference panes.

Don’t applications running under your user account have access to your user’s home folder by default?

The entire point of macOS's TCC was supposed to be to make that not the case anymore.
Post reply on HN