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??
layer8 1 days ago [-]
Yes, you need to read more carefully. In particular:
“8. Confirm that Documents access for Insent is still disabled in Files & Folders.
“9. Whatever you do now, the app retains full access to Documents, no matter what is shown or set in Files & Folders.”
[…]
“Access restrictions shown in Privacy & Security settings, specifically those to protected locations in Files & Folders, aren’t an accurate or trustworthy reflection of those that are actually applied. It’s possible for an app to have unrestricted access to one or more protected folders while its listing in Files & Folders shows it being blocked from access, or for it to have no entry at all in that list.”
mh8h 1 days ago [-]
"6. Click on Open from folder and select your Documents folder there. Confirm that works as expected and displays the name and contents of one of the text files in Documents."
It's because in step 6 the user explicitly selected the Documents folder.
The app can access the Documents folder because the user chose that directory in the native file browse dialog during the same run of the app. IMO that's a reasonable trade-off.
layer8 1 days ago [-]
The problem is that this given permission doesn’t show in Files & Folders, and after turning it on and off there it still persists. The only way to revoke it is using some CLI command and restart the computer.
mh8h 1 days ago [-]
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 interaction.
tpmoney 1 days ago [-]
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 expected. Especially given that the near equivalent workflow on iOS doesn't behave like this and that's what a lot of users would probably expect. On iOS an app can ask for access to your photos, which you can allow, or limit to specific photos or deny. If you allow access to specific photos and then the photo selector appears, even if you chose an album, the app will only get and retain access to the specific individual photos you gave it access to. It can not read the contents or even the names of any of the other photos in your library.
It seems pretty reasonable to expect that if the "Documents" folder permission is turned off for an app on macOS and you have given the application access to a specific document inside your documents folder, that the application would not also get (and retain) access to read from all the other folders and files within your documents folder.
I agree that this is the default behavior of most desktop OSes (including macOS), but it's also something that seems reasonable for Apple to change given how important sandboxing is to them in general, and how important it is in the broader context of always connected computers with multitudes of arbitrarily networked applications running.
what 1 days ago [-]
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.
ted_dunning 1 days ago [-]
That URL should expire after a relatively short time.
msephton 18 hours ago [-]
Expiration depends on how the app has implemented the request for access. Granting access creates a security-scoped bookmark. The app can store it and use it the next time access is required which will bypass the prompt and the bookmark will remain valid in perpetuity (or until tcc reset), or the app can not store it and request permission every launch.
This rules out entire classes of app and would make using a computer a miserable experience.
For example let's say you want to make an app that every day writes a backup to a particular location e.g. 1Password can do a daily backup of your encrypted passwords to a backup location.
Or, let's say you want to make a GUI around a command line program that stores its config as a dotfile.
Without a way to save access to file system locations persistently, apps would be forced to constantly shove open panels in your face all the time.
jagged-chisel 22 hours ago [-]
“Should” meaning “I believe it currently does expire after a short time”?
Or “should” meaning “Apple should change this to expire after a short time”?
what 21 hours ago [-]
It doesn’t expire, you can even move the file and you can update the bookmark to follow the move.
There are legitimate reasons to give an app persistent access to a file or directory. Maybe you want it to write to a particular directory in your iCloud storage or whatever so it syncs without having to select the directory every time. A note taking app for example.
what 21 hours ago [-]
No, it shouldn’t. There are real reasons to give persistent access to a particular directory. Maybe you want your note taking app to put all notes in a directory for iCloud/dropbox/google drive/some other sync service.
Nevermark 14 hours ago [-]
I am baffled that anyone thinks implication-of-action ambiguity and hidden security states without obvious controls, are acceptable security practices.
crdrost 1 days ago [-]
> That's not what's happening here.
No, it is, the comment you're replying to is correct in what it said to you.
> The Privacy settings applies only to access to the Documents folder without the user interaction.
Yes, BUT, the user interaction is irrevocable. There are two user interactions here, one is "please access Documents this one time" and the second is "please don't let this app access Documents again."
Of course, if the stakes were higher you wouldn't even think to defend this behavior. Like if you were dealing with a nuclear weapon launcher and there was a big panel saying "TARGETING SYSTEMS: 0 targets (Permission Lock sandbox excluding 450 potential targets needing approval)" and then you poked around and found out "uh... why can I still go into the interface and target Milan and the big glowy 'launch missiles' light then starts lighting up and presumably I can launch a nuclear strike on Milan?!" and someone says, "oh yeah, that's because back when we were demoing it, the general had us punch in a random city to show what the targeting UI looked like, and we randomly chose Milan... it's okay, to fix it someone just needs to go and manually remove the warhead and put in a different one and then we'll restart the system and it'll forget all its targeting data for the old warhead" -- that'd strike you as unsustainable.
But this is very low-stakes for us so it seems less outrageous, but fundamentally it is a solid buggy behavior, "The UI makes it sound like there is only one system at play here, but there are actually two and the other system can override a specific revocation that's placed at the level the UI controls." Even if there are going to be two systems, you expect that their security controls will both be followed, or that the second one will know enough to be able to say "I say no, but I am being overruled" in its status panel.
layer8 1 days ago [-]
The point is that (a) it’s misleading that the app has access to the folder while the settings claim that it doesn’t, and (b) there is no reasonable way for the user to revoke the implicitly given permission.
mh8h 1 days ago [-]
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 settings page as well, and have a way to revoke it.
jakeydus 1 days ago [-]
Yeah, it's less of a "GOTCHA!" and more of a weird use case that Apple engineers probably didn't think through all the way. Doesn't seem like a difficult fix at all.
If the app opens a window and prompts the user to select a directory to save a file or load a file, should that access be recorded in the privacy settings page? I'd argue that maybe there should be a verbose version of the privacy settings page, where if you _really_ want to you can see every dir that every app has ever accessed, but the vast majority of users don't care.[0]
I'm less caffeinated this morning though so maybe I misread the whole argument.
[0] edit: And whether the app still has access to that dir. Which maybe that was the point of the article. I am just skeptical generally of these kinds of exposés because while they're generally pretty fair, they'll inevitably get picked up by the geniuses on r/pcmasterrace who will spin it into "Apple Privacy and Security Settings Let Terrorists Invade Your Family Photos"
crossroadsguy 19 hours ago [-]
> Doesn't seem like a difficult fix at all.
Tell that to Apple engineering team who hasn’t been able to fix iCloud tab syncs after all this decade or so. Among hundreds of bugs that Apple users just live with, some even defend. Something tells me things in Apple’s OS architecture is so messily intertwined and too many things hardcoded that even competent software engineers at Apple will start having nightmares at the thought of touching them. Perils of a completely closed ecosystem (and don’t mean closed source).
jeremyjh 1 days ago [-]
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.
ted_dunning 1 days ago [-]
Why should the permission even persist that long? You might leave that app running for the next two years.
Shouldn't a temporary access be temporary? Possibly scoped by time? Possibly scoped to a single access?
jeremyjh 1 days ago [-]
Because the app may generate more than one descriptor for it or perform more than one read or write operation in the normal course of usage. If I open a document, and come back to it 6 hours later and click the save button, I would expect it to save the document.
saagarjha 1 days ago [-]
How would the app be able to reopen the file then?
jeremyjh 1 days ago [-]
It would ask for permission.
saagarjha 24 hours ago [-]
Every time you relaunch the app?
jeremyjh 23 hours ago [-]
It depends on the app whether that would make sense. If it is document centric, then yes. The user should explicitly open every time. If it doesn't make sense for the user to open it every time, it should ask for permanent permission and that should be recorded in system settings where it can be removed.
saagarjha 20 hours ago [-]
This seems like it would not work well with state restoration
jeremyjh 19 hours ago [-]
What would not work? Give a specific example. The app has access to its own state data regardless. If it needs permanent access to one of my folders where I maintain my data, all it has to do is ask once.
saagarjha 12 hours ago [-]
Yes, but then you quit the app. How is it going to read that folder again?
jeremyjh 9 hours ago [-]
It simply reads it. That is the whole point of explicit permission.
traderj0e 1 days ago [-]
The real problem with this isn't so much that it doesn't show the implicit consent. That would be nice but not a big deal. It's that it shows explicit non-consent that is getting ignored.
8. Confirm that Documents access for Insent is still disabled in Files & Folders.
ksidjwicjwjd 4 hours ago [-]
Eeeeeh not quite. It depends on the app. Take Adobe’s apps, for instance, you may revoke access to documents but they will still create a bunch of cache and setting files in there whether you want it or not, there simply is no way to revoke these permissions—and these are not files created by the user in any conceivable way.
1 days ago [-]
traderj0e 1 days ago [-]
Other comment seems accurate
jbverschoor 1 days ago [-]
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
wlesieutre 1 days ago [-]
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 they haven't done a good job of items 2 and 3.
jbverschoor 1 days ago [-]
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.
wlesieutre 1 days ago [-]
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.
simoncion 22 hours ago [-]
> 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.
Firstly: If that user has explicitly disallowed access to a particular directory in a system-wide filesystem access control dialog, the intent to prevent access to that directory seems completely clear. In cases like this, it seems fine to me to have a "Grant read/write/list permissions to this directory? [Once] [Forever]" dialog that this access attempt causes to pop up.
Secondly: Directories with XY3 or XY1 permissions are not unheard of. If you want programs to be able to access a directory but not be able to list its contents, that's what you'd do. Perhaps you don't want people to be casually able to read the metadata on files in that directory. I have a vague, distant, and extremely unreliable memory that tells me that this was a technique used by some *nix mail or print spooling software way back when, but... "extremely unreliable memory".
This configuration would probably cause most GUI file pickers to shit their pants, but there's absolutely nothing that says that you need to have either 'r' or 'w' privs to a directory for a GUI file picker to actually function. Nearly every one of them that I've used contains a text box that you can use to punch in path components and filenames.
Liquid_Fire 1 days ago [-]
> during the same run of the app
Is this part true? The article's fix involves running a command and rebooting the computer. If restarting the app was sufficient, surely you wouldn't need the command/reboot?
mh8h 1 days ago [-]
I guess not. Looks like if you choose the Documents directory once, you give your implicit permission to the app until you choose another restricted directory.
mixmastamyk 1 days ago [-]
Screen time is swiss cheese as well, not surprised.
lynx97 1 days ago [-]
This is so typical for Apple software "quality". While a truly love some of the features Apple has put into my pocket, I am noticing since years that at least iOS is the first commercially sold platform where I sometimes have to press a boolean toggle twice to have it take effect. They seem to have a lot of bugs around UI synchronisation.
yAak 1 days ago [-]
The gotcha is “I gave it permission, then revoked permission in the UI, but it still has permission.”
swiftcoder 1 days ago [-]
That's not quite it either. It's more along the lines of "I revoked access via one mechanism, then granted it via a different mechanism, and the setting UI for the first mechanism doesn't reflect the second action".
There's no privilege escalation here, but there is a misleading privacy settings UI, which offers no obvious way to audit/revoke permissions in the second case
lloeki 1 days ago [-]
I think the issue is more like:
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism.
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission survives the action context that triggered the file picker (e.g "pick a folder to do action A" also magically imbues similarly gated actions B C D and Z with access to that folder, possibly non-interactively even).
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission propagates to an action gated by the first mechanism, a first mechanism for which "Yes" means yes but "No" means "Maybe, depending on past unrelated actions that triggered an unrelated permission mechanism"
dmdeller 1 days ago [-]
Good analysis.
This is a result of trying to retrofit a series of tighter security measures on top of a system that was not originally designed for them, in a way that is both understandable to users but also doesn't break back-compat with APIs (and therefore a lot of existing third-party apps that are seldom updated) too badly. I'm not saying Apple did a perfect job here, but it's a hard problem.
Yes, the problem could probably be "solved" by adding more UI, but "more UI" is not always a good solution. The more UI that exists, the less likely the user is to successfully navigate it. On the other hand, adding additional complexity to an existing UI is also fraught with potential for new bugs and edge cases. Again, not defending the status quo, but I can see how it might have ended up like this.
This is worth spending more time on trying to improve, and perhaps it is reasonable to expect better from an almost-$4tn company. But at the same time, a potential solution is far from easy or obvious, and there is a risk of making things worse if not done with an extreme level of thought and consideration.
(Alternate pessimistic take: A large number of users don't care or read anything, they just click "allow" on anything that gets in their way. A smaller set of users are terrified and disgusted by repeated invasions of the privacy and click "deny" on everything. None of these implementations are doing any good for either group. The allow/deny design pattern is badly broken and in need of rethinking.)
wtallis 1 days ago [-]
Not quite. The steps are revoking permission in the UI (which works as expected), then implicitly granting permission in a way that the UI does not reflect but quietly persists.
_blk 16 hours ago [-]
So basically the opposite of Windows NTFS and SMB access. Windows is tricky but this is just bad.
DrammBA 1 days ago [-]
TFA intro (emphasis mine):
> In this Friday’s magic demonstration, I’m going to show how what you see in Privacy & Security settings can be misleading, when it tells you that an app doesn’t have access to a protected folder, but it really does.
altairprime 1 days ago [-]
One might expect macOS to recognize “you selected a folder that’s already got a UI associated with it” and to wire this up on the backend through the UI rather than creating a simple path exception that leaves the UI nonfunctional. I would have just filed a feedback report about it; but, the outrage-framing of that is, in historical context for this particular site, normal. They have posted extensively about Gatekeeper and TCC issues and seem to encounter them rather more reliably than others do, and released various tools (including today’s!) to support debugging, so certainly I empathize!
relaxing 1 days ago [-]
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.
kccqzy 1 days ago [-]
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?
nativeit 1 days ago [-]
My impression is that the revoked permissions do not persist. Rather, an interactive window running under the user’s name has implied access to the user’s home folders, regardless of what’s been set under “Files & Folders” (which still applies for background/non-interactive processes).
I could absolutely be missing something here, but the title would be accurate in saying, “MacOS ACLs aren’t terribly intuitive”. But I think the behavior they’re documenting is intended behavior.
minitech 2 hours ago [-]
> Rather, an interactive window running under the user’s name has implied access to the user’s home folders, regardless of what’s been set under “Files & Folders” (which still applies for background/non-interactive processes).
No, that’s not true at all. Granting permission using the folder picker is required.
xp84 1 days ago [-]
I’m glad I don’t even rely on this dumb system in the first place. I just run programs that don’t do shady shit. Wish I could disable these idiotic prompts entirely and go back to how it was before.
“Word” would like to access the files in your “Documents” folder
“Terminal” would like to access the files in your “Downloads” folder.
Yes, because I am telling them to access the files.
john_strinlai 1 days ago [-]
>I just run programs that don’t do shady shit.
you hand-audit every update for every program you run? can you share your workflow to do this?
otherwise, i am not sure how you can possibly guarantee that the programs you are running "dont do shady shit" (or, "wont do shady shit" in the future). there have been several compromises of non-shady programs and libraries in recent memory.
ted_dunning 1 days ago [-]
Wow... that would be great.
All that remains is an algorithm to reliably determine which programs do "shady shit". How is it that you determine that Microsoft updates have not been tampered?
(insincere) apologies for the snarky tone. You are making light of a very hard problem and default deny until confirmed by the user isn't a bad first approximation.
absolutedev 1 days ago [-]
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.
nativeit 1 days ago [-]
Don’t applications running under your user account have access to your user’s home folder by default?
josephcsible 1 days ago [-]
The entire point of macOS's TCC was supposed to be to make that not the case anymore.
iAMkenough 1 days ago [-]
No. You get prompted something like “Application wants access to your Documents folder” and “Application wants access to your Downloads folder” on first attempt of each folder.
ksidjwicjwjd 4 hours ago [-]
Not always though. Adobe’s apps seem to be able to do whatever fuck they want whenever they want. I want so badly to stop them from creating a bunch of bullshit files in my Documents folder but there simply is no way to do it.
ted_dunning 1 days ago [-]
The article seems to be saying that is true unless you implicitly and somewhat invisibly grant access via the file picker.
eviks 1 days ago [-]
That's the beauty of using a GUI-first operating system!
> only way you can protect your Documents folder from access by Insent is to run the following command in Terminal: tccutil reset All co.eclecticlight.Insent then restart your Mac
epistasis 1 days ago [-]
Jobs is turning in his grave. There are lots of stories of this conflict at NeXT and Mac OS X where there's a quick fix but not via GUI, which was one of the many things that incensed him.
eviks 1 days ago [-]
Is there a common source/collection of such stories?
epistasis 1 days ago [-]
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 development and companies in general, I think. jwz's stories of Netscape are also phenomenal. (Just don't click on any HN links that go to jwz.org, or you'll have to clear cookies to see any content there in the future. He's not a fan of the exploitation that startups frequently do to their employees and views HN as a primary channel of promoting that exploitation.)
lobf 1 days ago [-]
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
KaiMagnus 1 days ago [-]
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.
"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.
MetaWhirledPeas 1 days ago [-]
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.
achairapart 1 days ago [-]
I remember when this story (first?) came up on hn, there's a long thread here[0]
This is every OS. Unless you're telling me linux users have never had to open terminal to change something? Or windows users never need to use powershell when installing the OS in order to create a local non-cloud account
themafia 20 hours ago [-]
Then there's the OS/400 approach: Build TUIs that allow the user to set arguments and then just run command the line tools on submit. It was a really nice blend of two approaches and made things like man pages somewhat superflous.
wutwutwat 4 hours ago [-]
> That's the beauty of using a GUI-first operating system!
What non-gui first OS are you running? DOS?
sillyfluke 1 days ago [-]
Speaking of GUI weirdness, I've seen a couple of relatively newer macbooks do this thing where the laptop is shutdown with wifi disabled, but after login on startup the wifi icon displays the wifi scanning mode as if the wifi is enabled and looking for networks before reverting to the wifi disabled display icon.
Is this a GUI bug or is the wifi disabled setting overrided for a split second on startup? I haven't looked into it, but the latter would be extremely concerning.
eep_social 24 hours ago [-]
based on my experience, I suspect the latter
similar, user-hostile behaviors I have found include:
- wifi network passwords are persisted through a system wipe and reinstall in recovery mode
- a phone home is required by an activation step during installation
- bluetooth is always re-enabled after an upgrade
ksidjwicjwjd 4 hours ago [-]
> bluetooth is always re-enabled after an upgrade
Not user-hostile in the least. This is to ensure that the Mac can find Magic input devices.
jms703 1 days ago [-]
So the title should be something more like "macOS apps retain access to folders after access is removed by the user".
ezfe 1 days ago [-]
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.
jeremyjh 1 days ago [-]
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.
broheimz 12 hours ago [-]
I tested my own device (following this article), and found mac-native apps seem to respond well to the toggling in privacy and security settings, while 3rd party apps do not.
Pretty scary considering the blast radius of Electron apps: huge attack surface (Chromium + Node.js), require permissive entitlements to function (e.g., disable-library-validation, allow-unsigned-executable-memory), JS code is often unencrypted/easy to modify, easy inheritance to all the TCC permissions the user granted to the app.
Popular Electron Apps: Claude Desktop app, Spotify, Slack, Discord, Microsoft Teams, VS Code, Notion, LM Studio...
jasonjei 1 days ago [-]
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 for power users is infuriating at times. Multiple restarts of Mac and various processes (and when you realize not enough scopes have been granted, another subsequent restart). I think Mac forcing all users into its sandbox system has been one of my least favorite impacts since upgrading macOS, leading to the enshittification of macOS.
The craziest thing is background processes started by Terminal/iTerm (such as tmux) can inherit Terminal or iTerm’s elevated status even when Terminal or iTerm are no longer running, dead, or killed. So you’ll have a bunch of elevated processes without the elevated parent or grandparent process running—it makes me feel the whole permissions scheme is more performative than actually useful.
al_borland 1 days ago [-]
Someone at Apple should watch some of their old ads.
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.
iamcalledrob 1 days ago [-]
Plus, Apple exempt their own apps from a bunch of these permissions (because it would be an unacceptable user experience for their customers)
cosmic_cheese 1 days ago [-]
I think the bigger issue is that way too many devs still live in the extremely dated paradigm of “anything has access to everything all the time”, even though this model has repeatedly proven itself unworkable (particularly for anybody using proprietary software, which is notorious for sticking its fingers in places it has no business touching).
The way macOS handles permissions with user prompts might be the wrong UX, but giving every program carte blanche by default is definitely not the answer either.
It’s dangerous, particularly for those of us who are developing and publishing software that’s used by many thousands of people — we’re juicy targets and every time we disable protections in the name of convenience and carelessly run random third party software with unfettered access we’re playing with fire. I find myself consistently stunned by the flippant attitude SWEs take towards securing their systems. Our confidence that we’re too smart to fall victim is entirely misplaced.
jjtech 1 days ago [-]
Note that this isn't "Mac's sandbox system", it's TCC. That's an important distinction to make, because apps that have opted into the proper App Sandbox can't do this... they don't even have the ability to display a prompt for direct access to Documents/.
With the App Sandbox, sandbox extensions are issues whenever you open a file using the file picker. They only last until the app is restarted.
A caveat is that you can save "Security Scoped bookmarks" (basically a signed base64 blob [1]) and pass that around to preserve access, but that isn't very common.
Yes, TCC is what I meant, but my understanding is TCC is a platform wide sandboxing system?
galad87 1 days ago [-]
TCC is a leaky shoot at limiting non-sandboxed apps permissions. The actual macOS sandbox is a different thing.
I would say that TCC is working as intended, unfortunately, with many obscure behaviors to avoid breaking existing apps.
It's even more unfortunate that a lot of apps that could be easily sandboxed aren't.
traderj0e 1 days ago [-]
I feel the opposite with Mac permissions (or Linux or Windows). Hardly anything asks me, and it seems like everything has access to everything. But same conclusion here, if I don't trust something, I want to explicitly sandbox it.
big_toast 1 days ago [-]
I feel like I can mostly use containers on macOS. Is there a different sense that people are using containers on *nix? Or are you referring to all the macOS specific software footguns?
I would like to be able to run arbitrary code with gradual/granular privilege escalation. (e.g iOS/android with more affordances and escape hatches. macOS is getting there, but it's been a pretty bumpy/potholed road). Right now if I download a random github repo, I'd put it in a docker container and give it ports/volumes/etc.
jasonjei 1 days ago [-]
I was building a lightweight imitation of OpenClaw. Just a Claude.md and iMessage watcher. I had to play around with Privacy a lot to be able to read my iMessages database, and do a lot of iTerm restarting.
big_toast 1 days ago [-]
I remember it being worse a while ago. But most of the time I can drag a binary into Settings->Privacy & Security->Full Disk Access or other things (Accessibility API). Maybe other issues come up.
I feel like it should still be much easier, but the general sandboxing model seems directionally functional. (My understanding is containerization isn't a silver bullet security-wise, still requires fiddling, and would be a resource hog ram-wise if not CPU?)
I wish I could pick a parent folder/file and get a box to control everything (network/disk/folders/peripherals/accessibility).
liquid_thyme 22 hours ago [-]
BTW - UAC is not a security boundary, so UAC-bypass is not the same as privilege escalation, and there is no bounty for it, etc, etc. It's a common misunderstanding, probably in no small part due to Microsoft's own lack of communication around it.
galad87 1 days ago [-]
TCC is a different thing. Sandboxed apps work differently and won't need those TCC dialogs.
shantara 1 days ago [-]
One of the worst cases happens immediately after logging into a fresh Mac, or after upgrading one. You’re instantly hit with a barrage of requests from all the installed apps and their various permissions. It makes for such a terrible initial user experience, it’s utterly baffling someone at Apple has signed it off. They used to poke fun at Windows in their ads, but UAC has never been that terrible in my experience.
josephcsible 1 days ago [-]
> I personally think the traditional *nix model has served us quite well
performative is right. files & folders says blocked. open panel access still works. the pane only knows about one path
streetfighter64 24 hours ago [-]
I don't understand why OSX needs to restart the app to grant it permissions. The most annoying is video chat apps such as Teams and Zoom, having to close everything and reconnect if you want to share the screen or such. Perhaps there's a technical reason but it just feels like a lazy implementation.
But about the unix permissions model, is it really useful? During all my years of using linux on my personal machine, I've always had everything owned by my own user. Setting up specific users for programs would be a pain, and I don't think anybody does that? Servers is a different question, because then you're not actively using the system in the same way, which makes managing user accounts and their permissions on an app-level doable.
For normal users I think what's done on iphones and such works fairly well, and there they actually seem to have implemented it properly so that it doesn't require a restart to grant permissions.
jmount 1 days ago [-]
Very much agree. In fact I don't remember Vista or UAC being as unreliable as the Mac now is.
nottorp 1 days ago [-]
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 <the low contrast update>.
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.
KaiLetov 15 hours ago [-]
So you end up with two parallel permission systems that contradict each other, and the Settings UI only controls one of them. It's not a bug, it's architectural debt that they've decided is cheaper to leave than to fix.
cedws 1 days ago [-]
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?
concinds 1 days ago [-]
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.
saagarjha 1 days ago [-]
No?
ezfe 22 hours ago [-]
This is an oversight in the UI. None of the systems are malfunctioning, it's just that there's no affordance in the UI for the implicit consent flow.
isodev 1 days ago [-]
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.
binaryturtle 1 days ago [-]
I never used the ~/Documents folder. Lots of apps just trashed their stuff in there over the years making that folder entirely unusable for my actual document files. I would have to dig through the mess to find them. So I have to admit that I don't really understand the extra "care" Apple is doing to this particular folder. Same for the ~/Downloads folder: all my actual downloads go to some other disk, since the system disk is so small. Protecting this two folders would be entirely useless here.
IMHO where it really needs to be protected from when iCloud suddenly starts grabbing everything w/o the user's permission to upload it to some random Apple servers.
concinds 1 days ago [-]
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 Full Disk Access toggled on look identical, with "Full Disk Access" in gray. What the hell am I supposed to make of that?
Is it a bug? Do they have full disk access? Is the UI trying to imply that those apps are solely controlled by the FullDisk toggle and are ineligible to request granular permissions for Desktop/Documents? Or that they are eligible, but haven't requested it? Or maybe they did request it, and I granted it, but I don't get to see it? Who knows?
grvbck 1 days ago [-]
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]
What is the arcane Terminal command to undo this access?
zahirbmirza 1 days ago [-]
could the same be said of iOS?
ezfe 22 hours ago [-]
iOS does not allow any access to files outside of the file picker or the apps own folders
dangus 1 days ago [-]
The first thing I wondered after reading this article is whether there might be a scheduled task to run the permission reset similarly to how the author ran it via the command line.
It seems most likely that this is some kind of bug where that command or its underlying actions should be called every time the user unchecks something in the settings panel.
This is what we get when the iPhone’s permission system is grafted on top of a desktop OS that was never designed for it. I think they could have done something that is more Unix-like and yet friendly to the GUI end user.
bombcar 1 days ago [-]
This reminds me of the early days of MacOS where "repair permissions" was the magic fix to everything, or so it was rumored.
dangus 1 days ago [-]
Whoa you are bringing back some memories.
And it absolutely was a magic fix. I stand by it.
bombcar 1 days ago [-]
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.)
steve1977 1 days ago [-]
Safari is snappier now
bombcar 7 hours ago [-]
But the Finder is not.
FTFF
heyaco 1 days ago [-]
is this is why apple pushed an update yestersay?
lapcat 20 hours ago [-]
No.
lapcat 1 days ago [-]
It turns out the issue is a com.apple.macl extended attribute that gets set on the Documents folder and can't be removed, due to SIP.
ezfe 1 days ago [-]
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.
lapcat 1 days ago [-]
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.
kccqzy 1 days ago [-]
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.
lapcat 1 days ago [-]
> 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.
kccqzy 1 days ago [-]
The security-scoped bookmark is exactly why a user should treat all macOS file access permission prompts as permanent. There is also no UI to show to a user whether an app has created a security-scoped bookmark.
And this is for sandboxed apps. You correctly point out that non-sandboxed apps have even more access. So a user’s mental model should be that all open dialogs grant permanent access.
lapcat 22 hours ago [-]
tccutil reset All co.eclecticlight.Insent and reboot isn't actually working for me.
Thus, there's no way to remove access short of disabling SIP and deleting the com.apple.macl xattr.
ezfe 23 hours ago [-]
>I didn't give
This is not true, you do give consent when you pick a folder to open
jijji 1 days ago [-]
linux and unix before it has been a pretty consistent interface for decades, especially since the introduction of X windows in the 1980's..
MORPHOICES 1 days ago [-]
[dead]
cifer_security 1 days ago [-]
[flagged]
TeMPOraL 1 days ago [-]
Another solution would be for people to make up their minds. Maybe it's time to give up entirely on multi-tasking support in the OS, because what's the point if all interoperability is going to be disabled "for security"? Might as well just go back to running one program at a time and close up all those security holes in one go.
misir 1 days ago [-]
Why everything has to be on the server? ok, Where are you going to store your client authentication tokens or decryption keys. A proper file system isolation is a key if you want a proper application sandboxing
xvector 1 days ago [-]
Yet more AI slop on HN
xvector 1 days ago [-]
The post misunderstands how the permission system works.
Giving access to a file via the Open and Save panel is an explicit declaration of consent.
Because the panel is provided by OS itself, the app doesn't get access to the item until the user has selected a folder or file through that panel.
glitchc 1 days ago [-]
No, this is definitely a bug. The Privacy and Security panel is part of Settings, which is definitely part of the OS. Saying the Open and Save panel somehow has priority suggests that the Privacy and Security panel is not looking at the same parameters as the Open and Save panel, ergo a bug.
ezfe 1 days ago [-]
It’s not a bug and that is clear if you don’t use the documents folder as your example. When granting specific access it is not the same system as when granting general Documents folder access.
The UI just doesn’t reflect this.
glitchc 23 hours ago [-]
> The UI just doesn’t reflect this.
That's the bug. Either that or MacOS has two separate/distinct mechanisms for managing permissions, which would be a huge security flaw.
ezfe 23 hours ago [-]
MacOS has two distinct mechanisms. One gates access to Desktop, Documents, etc. for general access. The other grants access through the Open dialog. The open dialog is always superior because it's consent for a specific location.
dogusyilmaz 1 days ago [-]
I guess yes
oceanplexian 1 days ago [-]
Well duh, the purpose of Privacy and Security was never Privacy or security. The purpose is to lock you into Apple's ecosystem and prevent you from installing your own software.
throwaway290 1 days ago [-]
It seems that author basically found a 0day and published it. It's for sure better than selling it on the dark web but maybe it's better first tell it to Apple?
ethanrutherford 1 days ago [-]
Not exactly. It's not a "new" attack vector, any software which was malicious would have already been able to attack when you first gave it permission (a prerequisite for this sticky permission issue). If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app, not just "revoke the permission for the one folder".
It's not a good look for Apple, and it's not great that the permission revocation basically doesn't actually work, but any malware that could have infected the system due to this issue would have also been able to infect the system while the permission was still (intentionally) enabled.
throwaway290 1 days ago [-]
> If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app
There are many apps that themselves are not malicious but they run untrusted code via plugins and stuff. Like VS Code for example.
So you gave it a permission and then revoked it thinking all is fine. tomorrow an extension was hijacked and it now reads your files. cool?
concinds 1 days ago [-]
Apple Security would instantly close it as "don't see the problem here" if you reported it to them. They have a poor reputation around TCC bug reports.
throwaway290 1 days ago [-]
That makes it OK for you to not responsibly disclose a vuln? Cool I guess)
concinds 1 days ago [-]
I have nothing to do with any of this.
But since they don't consider these as vulnerabilities in the first place, then yeah, sure.
bl4kers 19 hours ago [-]
It's very common for large companies to "close" or downplay vulnerabilities. That doesn't exempt researchers from responsible disclosure timelines. There have been plenty of instances where a company reverses course after some back & forth and the looming threat of going public.
throwaway290 15 hours ago [-]
You literally made a statement justifying not responsibly disclosing vuln because apple process sucks
whether it is a vuln is different argument (it's sandbox escape and definitely usable as part of an exploit)
post-it 1 days ago [-]
Not really, just an unintuitive security feature. You still need the user's permission to access that folder, but that permission is then persistent. I consider it a UX bug for sure but not an exploit.
lugoues 1 days ago [-]
I agree, it's a ui/ux problem. It would seem that using the open file dialog should also request access but I'm guessing that was too intrusive and the user action is seen as implicit authorization. Security is one of those things that should aways be explicit though.
throwaway290 15 hours ago [-]
if having to run an arcane terminal program to disable access while GUI is as if access was not granted is "unintuitive security feature" for you, I can't even.
dackdel 1 days ago [-]
can you trust vpn to run well on a mac tho. like mullvad or something good.
MegagramEnjoyer 1 days ago [-]
imo, you can't really ever fully trust a closed-source system, which is why I advocate for linux distros, even though I'm a mac user myself (for now)
VPN should be properly implemented though as you're able to verify network requests on your own and don't necessarily have to trust apple. Best guarantee is to have a VPN at router level that can't be circumvented by anything (+ a trusted router vendor)
post-it 1 days ago [-]
Yeah, they run fine.
AlexandrB 1 days ago [-]
This is a few years old, but at one point Apple was happy to bypass VPN or firewall settings to allow their own apps to communicate[1]. I don't know if this is still true on Tahoe, but I wouldn't be surprised if at least the mechanism still exists. So "they run fine", but they may not do what you expect them to do when it comes to Apple's products/services.
I was considering buying a mini Mac, but there wasn't a way to encrypt it fully with Veracrypt and in the case of Francis Rawls the feds got pass Apples vault encryption. With the recent iPhone notification storage revelation I don't trust Apple at all.
nroize 1 days ago [-]
I couldn’t find any reference to File Vault being cracked in the Rawls case. Source?
Edit: I saw they accessed his Mac but they had his password. File Vault 2 wasn’t bypassed, and afaik has never been cracked.
nullpoint420 1 days ago [-]
Why crack it when you have silicon level backdoors?
I think it is an acceptable quirk for a permission system that has been retrofitted on top of an ecosystem which was not designed with that threat model in mind.
But sure, if I was assigned to make an all-purpose desktop operating system today from scratch, I would likely do this differently, but along with a bunch of other things I think (and the app would have to be implemented differently too).
Rendered at 20:17:41 GMT+0000 (Coordinated Universal Time) with Vercel.
“8. Confirm that Documents access for Insent is still disabled in Files & Folders.
“9. Whatever you do now, the app retains full access to Documents, no matter what is shown or set in Files & Folders.”
[…]
“Access restrictions shown in Privacy & Security settings, specifically those to protected locations in Files & Folders, aren’t an accurate or trustworthy reflection of those that are actually applied. It’s possible for an app to have unrestricted access to one or more protected folders while its listing in Files & Folders shows it being blocked from access, or for it to have no entry at all in that list.”
It's because in step 6 the user explicitly selected the Documents folder.
The app can access the Documents folder because the user chose that directory in the native file browse dialog during the same run of the app. IMO that's a reasonable trade-off.
The Privacy settings applies only to access to the Documents folder without the user interaction.
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 expected. Especially given that the near equivalent workflow on iOS doesn't behave like this and that's what a lot of users would probably expect. On iOS an app can ask for access to your photos, which you can allow, or limit to specific photos or deny. If you allow access to specific photos and then the photo selector appears, even if you chose an album, the app will only get and retain access to the specific individual photos you gave it access to. It can not read the contents or even the names of any of the other photos in your library.
It seems pretty reasonable to expect that if the "Documents" folder permission is turned off for an app on macOS and you have given the application access to a specific document inside your documents folder, that the application would not also get (and retain) access to read from all the other folders and files within your documents folder.
I agree that this is the default behavior of most desktop OSes (including macOS), but it's also something that seems reasonable for Apple to change given how important sandboxing is to them in general, and how important it is in the broader context of always connected computers with multitudes of arbitrarily networked applications running.
IIRC the bookmark is a base64 encoded plist containing bunch of data about the file/folder. A quick search got me this: https://www.mothersruin.com/software/Archaeology/reverse/boo...
For example let's say you want to make an app that every day writes a backup to a particular location e.g. 1Password can do a daily backup of your encrypted passwords to a backup location.
Or, let's say you want to make a GUI around a command line program that stores its config as a dotfile.
Without a way to save access to file system locations persistently, apps would be forced to constantly shove open panels in your face all the time.
Or “should” meaning “Apple should change this to expire after a short time”?
There are legitimate reasons to give an app persistent access to a file or directory. Maybe you want it to write to a particular directory in your iCloud storage or whatever so it syncs without having to select the directory every time. A note taking app for example.
No, it is, the comment you're replying to is correct in what it said to you.
> The Privacy settings applies only to access to the Documents folder without the user interaction.
Yes, BUT, the user interaction is irrevocable. There are two user interactions here, one is "please access Documents this one time" and the second is "please don't let this app access Documents again."
Of course, if the stakes were higher you wouldn't even think to defend this behavior. Like if you were dealing with a nuclear weapon launcher and there was a big panel saying "TARGETING SYSTEMS: 0 targets (Permission Lock sandbox excluding 450 potential targets needing approval)" and then you poked around and found out "uh... why can I still go into the interface and target Milan and the big glowy 'launch missiles' light then starts lighting up and presumably I can launch a nuclear strike on Milan?!" and someone says, "oh yeah, that's because back when we were demoing it, the general had us punch in a random city to show what the targeting UI looked like, and we randomly chose Milan... it's okay, to fix it someone just needs to go and manually remove the warhead and put in a different one and then we'll restart the system and it'll forget all its targeting data for the old warhead" -- that'd strike you as unsustainable.
But this is very low-stakes for us so it seems less outrageous, but fundamentally it is a solid buggy behavior, "The UI makes it sound like there is only one system at play here, but there are actually two and the other system can override a specific revocation that's placed at the level the UI controls." Even if there are going to be two systems, you expect that their security controls will both be followed, or that the second one will know enough to be able to say "I say no, but I am being overruled" in its status panel.
I guess the improvement can be to show the implicit consent in the privacy settings page as well, and have a way to revoke it.
If the app opens a window and prompts the user to select a directory to save a file or load a file, should that access be recorded in the privacy settings page? I'd argue that maybe there should be a verbose version of the privacy settings page, where if you _really_ want to you can see every dir that every app has ever accessed, but the vast majority of users don't care.[0]
I'm less caffeinated this morning though so maybe I misread the whole argument.
[0] edit: And whether the app still has access to that dir. Which maybe that was the point of the article. I am just skeptical generally of these kinds of exposés because while they're generally pretty fair, they'll inevitably get picked up by the geniuses on r/pcmasterrace who will spin it into "Apple Privacy and Security Settings Let Terrorists Invade Your Family Photos"
Tell that to Apple engineering team who hasn’t been able to fix iCloud tab syncs after all this decade or so. Among hundreds of bugs that Apple users just live with, some even defend. Something tells me things in Apple’s OS architecture is so messily intertwined and too many things hardcoded that even competent software engineers at Apple will start having nightmares at the thought of touching them. Perils of a completely closed ecosystem (and don’t mean closed source).
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.
Shouldn't a temporary access be temporary? Possibly scoped by time? Possibly scoped to a single access?
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
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 they haven't done a good job of items 2 and 3.
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.
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.
Firstly: If that user has explicitly disallowed access to a particular directory in a system-wide filesystem access control dialog, the intent to prevent access to that directory seems completely clear. In cases like this, it seems fine to me to have a "Grant read/write/list permissions to this directory? [Once] [Forever]" dialog that this access attempt causes to pop up.
Secondly: Directories with XY3 or XY1 permissions are not unheard of. If you want programs to be able to access a directory but not be able to list its contents, that's what you'd do. Perhaps you don't want people to be casually able to read the metadata on files in that directory. I have a vague, distant, and extremely unreliable memory that tells me that this was a technique used by some *nix mail or print spooling software way back when, but... "extremely unreliable memory".
This configuration would probably cause most GUI file pickers to shit their pants, but there's absolutely nothing that says that you need to have either 'r' or 'w' privs to a directory for a GUI file picker to actually function. Nearly every one of them that I've used contains a text box that you can use to punch in path components and filenames.
Is this part true? The article's fix involves running a command and rebooting the computer. If restarting the app was sufficient, surely you wouldn't need the command/reboot?
There's no privilege escalation here, but there is a misleading privacy settings UI, which offers no obvious way to audit/revoke permissions in the second case
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism.
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission survives the action context that triggered the file picker (e.g "pick a folder to do action A" also magically imbues similarly gated actions B C D and Z with access to that folder, possibly non-interactively even).
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission propagates to an action gated by the first mechanism, a first mechanism for which "Yes" means yes but "No" means "Maybe, depending on past unrelated actions that triggered an unrelated permission mechanism"
This is a result of trying to retrofit a series of tighter security measures on top of a system that was not originally designed for them, in a way that is both understandable to users but also doesn't break back-compat with APIs (and therefore a lot of existing third-party apps that are seldom updated) too badly. I'm not saying Apple did a perfect job here, but it's a hard problem.
Yes, the problem could probably be "solved" by adding more UI, but "more UI" is not always a good solution. The more UI that exists, the less likely the user is to successfully navigate it. On the other hand, adding additional complexity to an existing UI is also fraught with potential for new bugs and edge cases. Again, not defending the status quo, but I can see how it might have ended up like this.
This is worth spending more time on trying to improve, and perhaps it is reasonable to expect better from an almost-$4tn company. But at the same time, a potential solution is far from easy or obvious, and there is a risk of making things worse if not done with an extreme level of thought and consideration.
(Alternate pessimistic take: A large number of users don't care or read anything, they just click "allow" on anything that gets in their way. A smaller set of users are terrified and disgusted by repeated invasions of the privacy and click "deny" on everything. None of these implementations are doing any good for either group. The allow/deny design pattern is badly broken and in need of rethinking.)
> In this Friday’s magic demonstration, I’m going to show how what you see in Privacy & Security settings can be misleading, when it tells you that an app doesn’t have access to a protected folder, but it really does.
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?
I could absolutely be missing something here, but the title would be accurate in saying, “MacOS ACLs aren’t terribly intuitive”. But I think the behavior they’re documenting is intended behavior.
No, that’s not true at all. Granting permission using the folder picker is required.
“Word” would like to access the files in your “Documents” folder
“Terminal” would like to access the files in your “Downloads” folder.
Yes, because I am telling them to access the files.
you hand-audit every update for every program you run? can you share your workflow to do this?
otherwise, i am not sure how you can possibly guarantee that the programs you are running "dont do shady shit" (or, "wont do shady shit" in the future). there have been several compromises of non-shady programs and libraries in recent memory.
All that remains is an algorithm to reliably determine which programs do "shady shit". How is it that you determine that Microsoft updates have not been tampered?
(insincere) apologies for the snarky tone. You are making light of a very hard problem and default deny until confirmed by the user isn't a bad first approximation.
> only way you can protect your Documents folder from access by Insent is to run the following command in Terminal: tccutil reset All co.eclecticlight.Insent then restart your Mac
Even if you're not an Apple fan, these sorts of stories are kind of great for learning about product development and companies in general, I think. jwz's stories of Netscape are also phenomenal. (Just don't click on any HN links that go to jwz.org, or you'll have to clear cookies to see any content there in the future. He's not a fan of the exploitation that startups frequently do to their employees and views HN as a primary channel of promoting that exploitation.)
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
> 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_...
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.
[0]: https://news.ycombinator.com/item?id=17101053
This is every OS. Unless you're telling me linux users have never had to open terminal to change something? Or windows users never need to use powershell when installing the OS in order to create a local non-cloud account
What non-gui first OS are you running? DOS?
Is this a GUI bug or is the wifi disabled setting overrided for a split second on startup? I haven't looked into it, but the latter would be extremely concerning.
similar, user-hostile behaviors I have found include:
- wifi network passwords are persisted through a system wipe and reinstall in recovery mode - a phone home is required by an activation step during installation - bluetooth is always re-enabled after an upgrade
Not user-hostile in the least. This is to ensure that the Mac can find Magic input devices.
But also, once they've explicitly granted access, and then implicitly granted access to the same folder, disabling explicit access changes nothing.
Pretty scary considering the blast radius of Electron apps: huge attack surface (Chromium + Node.js), require permissive entitlements to function (e.g., disable-library-validation, allow-unsigned-executable-memory), JS code is often unencrypted/easy to modify, easy inheritance to all the TCC permissions the user granted to the app.
Popular Electron Apps: Claude Desktop app, Spotify, Slack, Discord, Microsoft Teams, VS Code, Notion, LM Studio...
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 for power users is infuriating at times. Multiple restarts of Mac and various processes (and when you realize not enough scopes have been granted, another subsequent restart). I think Mac forcing all users into its sandbox system has been one of my least favorite impacts since upgrading macOS, leading to the enshittification of macOS.
The craziest thing is background processes started by Terminal/iTerm (such as tmux) can inherit Terminal or iTerm’s elevated status even when Terminal or iTerm are no longer running, dead, or killed. So you’ll have a bunch of elevated processes without the elevated parent or grandparent process running—it makes me feel the whole permissions scheme is more performative than actually useful.
https://www.youtube.com/watch?v=8CwoluNRSSc
The way macOS handles permissions with user prompts might be the wrong UX, but giving every program carte blanche by default is definitely not the answer either.
It’s dangerous, particularly for those of us who are developing and publishing software that’s used by many thousands of people — we’re juicy targets and every time we disable protections in the name of convenience and carelessly run random third party software with unfettered access we’re playing with fire. I find myself consistently stunned by the flippant attitude SWEs take towards securing their systems. Our confidence that we’re too smart to fall victim is entirely misplaced.
With the App Sandbox, sandbox extensions are issues whenever you open a file using the file picker. They only last until the app is restarted.
A caveat is that you can save "Security Scoped bookmarks" (basically a signed base64 blob [1]) and pass that around to preserve access, but that isn't very common.
[1] https://www.mothersruin.com/software/Archaeology/reverse/boo...
I would say that TCC is working as intended, unfortunately, with many obscure behaviors to avoid breaking existing apps.
It's even more unfortunate that a lot of apps that could be easily sandboxed aren't.
I would like to be able to run arbitrary code with gradual/granular privilege escalation. (e.g iOS/android with more affordances and escape hatches. macOS is getting there, but it's been a pretty bumpy/potholed road). Right now if I download a random github repo, I'd put it in a docker container and give it ports/volumes/etc.
I feel like it should still be much easier, but the general sandboxing model seems directionally functional. (My understanding is containerization isn't a silver bullet security-wise, still requires fiddling, and would be a resource hog ram-wise if not CPU?)
I wish I could pick a parent folder/file and get a box to control everything (network/disk/folders/peripherals/accessibility).
It has the https://xkcd.com/1200/ problem on almost all end-user setups.
But about the unix permissions model, is it really useful? During all my years of using linux on my personal machine, I've always had everything owned by my own user. Setting up specific users for programs would be a pain, and I don't think anybody does that? Servers is a different question, because then you're not actively using the system in the same way, which makes managing user accounts and their permissions on an app-level doable.
For normal users I think what's done on iphones and such works fairly well, and there they actually seem to have implemented it properly so that it doesn't require a restart to grant permissions.
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 <the low contrast update>.
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.
As a precaution would it be a good idea to run that reset command for all apps?
IMHO where it really needs to be protected from when iCloud suddenly starts grabbing everything w/o the user's permission to upload it to some random Apple servers.
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 Full Disk Access toggled on look identical, with "Full Disk Access" in gray. What the hell am I supposed to make of that?
Is it a bug? Do they have full disk access? Is the UI trying to imply that those apps are solely controlled by the FullDisk toggle and are ineligible to request granular permissions for Desktop/Documents? Or that they are eligible, but haven't requested it? Or maybe they did request it, and I granted it, but I don't get to see it? Who knows?
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:
"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...
It seems most likely that this is some kind of bug where that command or its underlying actions should be called every time the user unchecks something in the settings panel.
This is what we get when the iPhone’s permission system is grafted on top of a desktop OS that was never designed for it. I think they could have done something that is more Unix-like and yet friendly to the GUI end user.
And it absolutely was a magic fix. I stand by 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.)
FTFF
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.
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.
And this is for sandboxed apps. You correctly point out that non-sandboxed apps have even more access. So a user’s mental model should be that all open dialogs grant permanent access.
Thus, there's no way to remove access short of disabling SIP and deleting the com.apple.macl xattr.
This is not true, you do give consent when you pick a folder to open
Giving access to a file via the Open and Save panel is an explicit declaration of consent.
Because the panel is provided by OS itself, the app doesn't get access to the item until the user has selected a folder or file through that panel.
The UI just doesn’t reflect this.
That's the bug. Either that or MacOS has two separate/distinct mechanisms for managing permissions, which would be a huge security flaw.
It's not a good look for Apple, and it's not great that the permission revocation basically doesn't actually work, but any malware that could have infected the system due to this issue would have also been able to infect the system while the permission was still (intentionally) enabled.
There are many apps that themselves are not malicious but they run untrusted code via plugins and stuff. Like VS Code for example.
So you gave it a permission and then revoked it thinking all is fine. tomorrow an extension was hijacked and it now reads your files. cool?
But since they don't consider these as vulnerabilities in the first place, then yeah, sure.
whether it is a vuln is different argument (it's sandbox escape and definitely usable as part of an exploit)
VPN should be properly implemented though as you're able to verify network requests on your own and don't necessarily have to trust apple. Best guarantee is to have a VPN at router level that can't be circumvented by anything (+ a trusted router vendor)
[1] https://www.macworld.com/article/675671/apples-own-programs-...
As if that's going to happen.
Edit: I saw they accessed his Mac but they had his password. File Vault 2 wasn’t bypassed, and afaik has never been cracked.
Nevermind just saw this: https://news.ycombinator.com/item?id=47716490
But sure, if I was assigned to make an all-purpose desktop operating system today from scratch, I would likely do this differently, but along with a bunch of other things I think (and the app would have to be implemented differently too).