Can you trust that permission pop-up on macOS?

> These experiences have been why I’ve not a big fan of “capabilities” as a concept. The UX around them is awful, and almost has to be.

I don't think the UX has to be awful. The problem is just that they're kinda half baked on macos, and bolted on, and not really a first class citizen. There's no reason you couldn't have:

- A preferences dialog showing which long-lived capabilities you've granted to which application. (Which is almost exactly what the accessibility preferences pane already is.) Ideally this UI could have a log of ways in which the application has used that capability recently and the ability to revoke it. Maybe even the ability to review the app's use of the capability. Show the review score to other users when the app asks for the permission.

- A little blob of text saying why the application is asking for the specified permission. iOS requires this from all 3rd party apps. So its kinda weird that MacOS is missing explanatory text entirely on these popups.

- Clear indication of what would happen if you said no.

- Interdiction. In a good capability systems (eg SeL4), a capability object doesn't tell you what you can do with it. Eg, you can't ask a file handle which file its actually associated with. This means you can craft your own "virtual" capability which fakes the expected behaviour and pass that to an app instead. Any calls made using the capability come to you. Whenever phone apps ask for access to my contact address book, I'd love to be able to say yes, but give them access to like 100mb of fake entries instead.

- And on top of interdiction: logging, call whitelisting, "Little snitch", etc.

- More fine grained capabilities. I don't want to give any app a "root my computer" capability. I don't want that to be a thing applications ever need or get access to.

I think macos's problem is that its trying to bolt on capabilities after the fact. POSIX isn't built around capabilities. As a result, app developers don't think in terms of capabilities, and they expect their apps (new and old) to work without them. In a real capability based OS, fopen() should probably take a capability as a parameter. But making that change would require changing just about every program ever written for the platform. And modifying the standard library of all programming languages.

Capabilities are what lets you open a file picker from an app that cannot read your files, giving you a seamless and secure interaction with no extra UI.

They are definitely not always awful.

Yes, this is the whole issue with these kinds of systems. The message gets lost in translation to the user. An OG java applet would say "this app is signed, do you want to continue", and the engineer at the bottom is the only one that knows what that even really means, which is that the applet gets to run outside the sandbox if the user runs it. Windows UAC is similar, as are most Linux desktop security mechanisms.

Yeah, to be perfectly honest, I understand. I think TCC is meant to be the primary consent system, but there are others (such as the Authorization system, and the Service Management framework).

I think Apple took a step in this direction when they started forcing you to navigate to Security & Privacy to enable the modal the first time when launching an untrusted app.

They could probably add an opt-out step two for consumer level use where that step is also required for all root permissions requests. I would add a fast blink of the webcam light to prove trusted modal is open.

Currently it is incredibly clunky (they should put a notification at the top of the settings like for software updates), but you have some indication what app is triggering it and the dialogue could be hidden until it is time to review updates. Showing all entitlements and privacy settings should also be required any time a root password is requested with changes being noted as unusual, including changes in developer accounts.

Damn, that really puts things into perspective. Granted, attached modals presuppose there's a window to attach to. But I think that would probably be true 9 times out of 10.

This is pretty straightforward for a malicious application to simulate.

Thanks for posting. I’ve had this vividly in my mind for years, but didn’t remember the source. Makes so much sense.

What's the problem here? Javascript popups can't read your fingerprint so what would be the endgame of a fake passkey popup?

Apple also sells a wireless keyboard with touchid integrated. Works great. Especially if you also set pam to use touchid for sudo. They’re not cheap though.

Apple themselves have a quirk in some cases where apps that aren’t in an Applications folder get mounted as read-only.

Granted I haven’t seen the bug in awhile, but I also never saw acknowledgement of it being fixed so…

No comment on the overall topic, but I have long made a practice of installing into $HOME/Applications instead[1], and it's rare for me to encounter software that cares. A few apps have added popups to explain to beginners "Hey, you're running me from the Downloads folder, uhh, want me to properly move myself to /Applications/?" but that's about it.

The only apps I run from /Applications that aren't part of the OS are the ones that still use "Installers" like Adobe apps, because I assume they spew crap all over anyway. I haven't tried moving those, but I wouldn't be surprised if they deeply cared.

[1] The idea being that I could then migrate more easily by copying the whole home directory, and thus all my apps that didn't require "installation" would come over.

Nope, that was fixed several releases back. macOS doesn't use the concept of a root user for years. It's there in the APIs for backwards compatibility but the actual enforced permission model is nothing like UNIX.

1. Apps can't tamper with each others files. Try writing an app that writes to another app's bundle, even if it's in $HOME, and you'll find you can't. One way to test this quickly is to ensure that your terminal app doesn't have "Manage applications" privilege in the settings app, restart it, then use vim to open a file in a bundle that appears to have user write permissions. You'll find it is read only.

2. root can't make arbitrary changes to the system unless you disable SIP (requires messing around in recovery mode terminals).

Which is madly insecure, right?

You need to manually create it.

In the Finder it is translated to your system language. For example, „Programme“ in German. It is still Applications in the terminal.

You can still choose to install apps to ~/Applications if you are an admin.

You can just make sudo not require a password... You'll never see any prompt again then.

At least Windows now makes the UAC dialog distinct from the rest of the OS and any other Window. macOS (and most linux DEs too) just look like any other application dialog, easily spoofed.

UAC on Windows opens up on the secure desktop, which is isolated in protected memory and not accessible to other processes. It's also visually distinct, hiding all other UI elements, and nothing else can present the actual secure desktop, only UAC can. Granted, I've seen some fairly convincing looking fake prompts (that regular users would fall for) but to me they were still obviously fake, and they were unable to hide all UI elements like UAC does.

The secure desktop for UAC is also supposed to help prevent cursor offsets and other attacks (replacing the system cursor with fake one that shows as if it's over the "no" button but is actually going to click on "yes").

macOS could really use something like that for it's prompts, and I don't know why any other OS hasn't implemented something like UAC's secure desktop.

Every time I update an app I have to be told I downloaded it from the Internet and do I trust it. Can this app look on the local network? Constantly being nagged to the point I don't even check/care anymore. Exactly what Vista used to do.

Oh god, don't get me started...

1. iCloud nags never go away if you don't log into iCloud

2. Apple Music is just an advertisement by default and "conveniently" opens every sound file mimetype

3. Functionally useless subscription slopware like AppleTV+ comes installed by-default for no reason

4. Package management is a colossal clusterfuck that can't even enforce package parity across system architectures

5. Apple still doesn't trust their users enough to have modern amenities like a native Vulkan runtime or Nvidia GPU drivers

Vista was terrible, but it didn't suffer from this level of identity crisis.

Neither was Windows if you knew what you were doing.

I ran Windows XP for years without antivirus back in the early 2000s and so did others.

Seems like it should only need to do this once. I get this with almost every Slack and VSCode update. The correct solution for me is to quit Slack.app and let my company's management software do the update for me.

I installed Slack from the app store and never see this popup.

Discord does this as well I believe. I often needed to enter the administrator password to install a helper after the system had been off for a couple days.

A software updater was going to be my best guess at what this was. I guess I understand the flexibility it brings, but it definitely does have some security trade-offs.

> Slack is just a messaging application.

I kinda like this angle. While Slack makes an effort to work basically everywhere with low effort, I wonder what would follow if it wasn't the case.

For instance if for some stupid legal reason Slack was banned from macos, how many people would just switch to another OS ? I'd bet it would be a non trivial amount of users at this point.

> Slack is just a messaging application

its sold more as a way to store and all conversations than the ability to be a messaging application.

the original pitch was to make all information, even private conversation of previous employees, searchable.

Being paranoid, would it be possible that another app already installed (but not trusted enough to give privilege, let’s say a shady mouse driver or screenshot app) detect when slack (more trustfully) does launch to open a dialog at that precise time and deceive the user? Let’s say the shady app is named « SIack » or something close enough to be missed - but brand itself as innocents « screenshotPro4000 » in the app itself graphics so you’re not suspicious.

> The day Apple prevents users from giving sudo access to a third-app app is when the Mac fully becomes a walled garden, and you can expect pages of HN complaints.

I can see this happening, but it probably won't anytime soon. macOS is still open enough, and with the assumption that sometimes processes need root (see third-party Launch Daemons).

It would probably break quite a lot. But I wouldn't be surprised if they eventually gradually move macOS in that direction.

As of the latest macOS update, every app is now asking every few days if it can have access to devices on your local network, or something to that tune. My theory right now is it's something in chromium that automatically asking for this and Electron apps will do this out of the box, but I can't remember which apps exactly have been doing this.

Regardless, yes it causes the exact issue you're talking about. I don't even read what the popups say anymore, I'm just blindly hitting an accept button.

If someone cold calls me and asks me to verify myself, I refuse.

If it’s an expected call or they give me a good reason to, I’ll call their listed contact number back.

So far I have not missed out on anything of consequence by refusing to identify myself to someone who initiated contact with me.

I wonder why they don't add a little led to their laptops that would indicate that it really is the system asking for your password. Kind of like the camera led.

I mean, a website could display a crafty popup-appearing box and try to get you to type in your username and password. Not really sure how you can prevent that.

Vista used the “the background dims quite a bit” to try to deal with that.