[HN Gopher] You can't trust macOS Privacy and Security settings
___________________________________________________________________
You can't trust macOS Privacy and Security settings
Author : zdw
Score : 400 points
Date : 2026-04-10 15:28 UTC (7 hours ago)
(HTM) web link (eclecticlight.co)
(TXT) w3m dump (eclecticlight.co)
| dackdel wrote:
| can you trust vpn to run well on a mac tho. like mullvad or
| something good.
| post-it wrote:
| Yeah, they run fine.
| AlexandrB wrote:
| 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.
|
| [1] https://www.macworld.com/article/675671/apples-own-
| programs-...
| MegagramEnjoyer wrote:
| 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)
| b8 wrote:
| 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.
| SilverElfin wrote:
| Notification storage? What's the story there?
|
| Nevermind just saw this:
| https://news.ycombinator.com/item?id=47716490
| nroize wrote:
| 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 wrote:
| Why crack it when you have silicon level backdoors?
| nroize wrote:
| In T2? Source?
| throwaway290 wrote:
| 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?
| post-it wrote:
| 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 wrote:
| 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.
| ethanrutherford wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| That makes it OK for you to not responsibly disclose a vuln?
| Cool I guess)
| concinds wrote:
| 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.
| jasonjei wrote:
| 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 (a 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 wrote:
| Someone at Apple should watch some of their old ads.
|
| https://www.youtube.com/watch?v=8CwoluNRSSc
| halapro wrote:
| 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.
| jmount wrote:
| Very much agree. In fact I don't remember Vista or UAC being as
| unreliable as the Mac now is.
| big_toast wrote:
| 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 wrote:
| 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 wrote:
| 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).
| shantara wrote:
| 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.
| iamcalledrob wrote:
| Plus, Apple exempt their own apps from a bunch of these
| permissions (because it would be an unacceptable user
| experience for _their_ customers)
| jjtech wrote:
| 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.
|
| [1]
| https://www.mothersruin.com/software/Archaeology/reverse/boo...
| jasonjei wrote:
| Yes, TCC is what I meant, but my understanding is TCC is a
| platform wide sandboxing system?
| galad87 wrote:
| 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.
| galad87 wrote:
| TCC is a different thing. Sandboxed apps work differently and
| won't need those TCC dialogs.
| traderj0e wrote:
| 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.
| p_stuart82 wrote:
| performative is right. files & folders says blocked. open panel
| access still works. the pane only knows about one path
| cosmic_cheese wrote:
| 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.
| josephcsible wrote:
| > I personally think the traditional *nix model has served us
| quite well
|
| It has the https://xkcd.com/1200/ problem on almost all end-
| user setups.
| streetfighter64 wrote:
| 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.
| liquid_thyme wrote:
| 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.
| chrisjj wrote:
| > Once you have downloaded Insent
|
| As if that's going to happen.
| Angostura wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| 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.
| layer8 wrote:
| 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 wrote:
| 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 wrote:
| 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 exposes
| 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"
| traderj0e wrote:
| 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.
| jeremyjh wrote:
| 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.
| saagarjha wrote:
| How would the app be able to reopen the file then?
| jeremyjh wrote:
| It would ask for permission.
| saagarjha wrote:
| Every time you relaunch the app?
| jeremyjh wrote:
| 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.
| ted_dunning wrote:
| 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 wrote:
| 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.
| tpmoney wrote:
| 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 wrote:
| 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 wrote:
| That URL should expire after a relatively short time.
| jagged-chisel wrote:
| "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 wrote:
| 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 wrote:
| 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.
| traderj0e wrote:
| Other comment seems accurate
| crdrost wrote:
| > 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.
| jbverschoor wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| lynx97 wrote:
| 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.
| mixmastamyk wrote:
| Screen time is swiss cheese as well, not surprised.
| yAak wrote:
| The gotcha is "I gave it permission, then revoked permission in
| the UI, but it still has permission."
| swiftcoder wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| DrammBA wrote:
| 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_.
| relaxing wrote:
| 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.
| nativeit wrote:
| 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.
| kccqzy wrote:
| 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?
| altairprime wrote:
| 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!
| xp84 wrote:
| 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 wrote:
| > _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 wrote:
| 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.
| dadoum wrote:
| 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).
| absolutedev wrote:
| Great insight! Thanks for sharing.
| absolutedev wrote:
| 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 wrote:
| Don't applications running under your user account have access
| to your user's home folder by default?
| iAMkenough wrote:
| 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.
| ted_dunning wrote:
| The article seems to be saying that is true unless you
| implicitly and somewhat invisibly grant access via the file
| picker.
| josephcsible wrote:
| The entire point of macOS's TCC was supposed to be to make
| that not the case anymore.
| eviks wrote:
| 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
| sillyfluke wrote:
| 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 wrote:
| 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
| epistasis wrote:
| 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 wrote:
| Is there a common source/collection of such stories?
| epistasis wrote:
| 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 wrote:
| 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
| cjcole wrote:
| "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.
| KaiMagnus wrote:
| Very cool story. Now I'm wondering if this event happened
| sometime during this section from one of Carmack's own
| posts:
|
| > I was brought in to talk about the needs of games in
| general, but I made it my mission to get Apple to adopt
| OpenGL as their 3D graphics API. I had a lot of arguments
| with Steve.
|
| https://old.reddit.com/r/Games/comments/8l9qw2/john_carma
| ck_...
| MetaWhirledPeas wrote:
| 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 wrote:
| I remember when this story (first?) came up on hn,
| there's a long thread here[0]
|
| [0]: https://news.ycombinator.com/item?id=17101053
| dangus wrote:
| 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 wrote:
| This reminds me of the early days of MacOS where "repair
| permissions" was the magic fix to everything, or so it was
| rumored.
| dangus wrote:
| Whoa you are bringing back some memories.
|
| And it absolutely was a magic fix. I stand by it.
| steve1977 wrote:
| Safari is snappier now
| bombcar wrote:
| 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.)
| throwyu wrote:
| I never trust american and Chinese companies
| cifer_security wrote:
| This is exactly why the security model matters. If the OS or app
| can access your data, so can anyone who compromises it. The only
| real solution is client-side encryption where the server NEVER
| sees plaintext -- your keys stay on your device.
|
| We've been building something in this space -- Cifer Security
| uses ML-KEM (post-quantum) for key encapsulation and Poseidon
| hashing, with Groth16 proofs for verifiability. The server is
| intentionally blind to what it's storing.
|
| The macOS permission model is theater if the app itself isn't
| zero-knowledge. Privacy can't rely on UI toggles -- it has to be
| cryptographic.
| misir wrote:
| 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
| TeMPOraL wrote:
| 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.
| xvector wrote:
| Yet more AI slop on HN
| concinds wrote:
| 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 wrote:
| That is really poorly worded by Apple, because if I understand
| it correctly, the "Files & Folders" list is just a list of apps
| that have _requested_ Full Disk Access /FDA (or other
| locations).
|
| It's really confusing that some of those settings can be
| toggled on/off, while the Full Disk Access is greyed out and
| can only be toggled under "Privacy & Security".
|
| To add to the confusion, toggling FDA off just protects a few
| selected folders that Apple decided are extra sensitive, like:
| Messages ~/Library/Messages Safari
| browsing history ~/Library/Safari Cookies
| ~/Library/Cookies Identity services
| ~/Library/IdentityServices Spotlight data
| ~/Library/Metadata/CoreSpotlight Phone call history
| ~/Library/Application Support/CallHistoryDB Facetime data
| ~/Library/Application Support/Facetime TCC database
| ~/Library/Application Support/com.apple.TCC.db
|
| "Normal" files and folders on your disk (including Desktop,
| Documents, Downloads, network volumes, and removable volumes)
| can always be accessed (even with FDA permission revoked!)
| after a simple prompt. [1]
|
| [1] https://support.apple.com/guide/security/controlling-app-
| acc...
| binaryturtle wrote:
| 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.
| SomaticPirate wrote:
| What is the arcane Terminal command to undo this access?
| cedws wrote:
| 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 wrote:
| 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 wrote:
| No?
| isodev wrote:
| 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.
| ezfe wrote:
| 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.
| dogusyilmaz wrote:
| I guess yes
| jijji wrote:
| linux and unix before it has been a pretty consistent interface
| for decades, especially since the introduction of X windows in
| the 1980's..
| jms703 wrote:
| So the title should be something more like "macOS apps retain
| access to folders after access is removed by the user".
| ezfe wrote:
| 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 wrote:
| 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.
| xvector wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| heyaco wrote:
| is this is why apple pushed an update yestersay?
| oceanplexian wrote:
| 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.
| lapcat wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| >I didn't give
|
| This is not true, you do give consent when you pick a
| folder to open
| nottorp wrote:
| 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.
| zahirbmirza wrote:
| could the same be said of iOS?
| ezfe wrote:
| iOS does not allow any access to files outside of the file
| picker or the apps own folders
___________________________________________________________________
(page generated 2026-04-10 23:00 UTC)