It’s incredibly frustrating. This is my software, running on my computer, yet there are moments when it feels like Apple thinks it’s really in charge. It needs to back off.
He’s so close.
It’s incredibly frustrating. This is my software, running on my computer, yet there are moments when it feels like Apple thinks it’s really in charge. It needs to back off.
He’s so close.
Eh, I think the article is in general correct, the problem isn’t the security prompts its the UX of dealing with them. It seems like the old Vista experience. Apple can and should be doing better, but absolutely a first world problem.
Bill Shooter of Bul,
Seems that we both had the same reaction to the article, haha. It could well have been written about UAC on windows vista.
Apple ads were making fun of UAC back in the day, there’s a lot of irony here.
https://www.youtube.com/watch?v=8CwoluNRSSc
The UX isn’t bad. The prompts happen once when the program needs the access. The UX for adjusting permissions after the prompt could be better though.
The alternative is for programs to fail silently and require the person to dig through logs and settings to figure out what when wrong. Hi SELinux and Bubblewrap!
Flatland_Spider,
I get where the author is coming from. The problem is that the permissions dialogs are shown individually rather than combined so they can be handled once and done.
IMHO permission manifest and/or API that asks all needed permissions in one go, like on android, would be more user friendly. Also, this isn’t something I’ve seen in any mainstream OS, but the option to run with full permissions in a sandboxed environment is something I’ve had on my wish list. Running with full permissions isn’t as big an issue in a sandbox. Then the OS could provide good tooling for what goes into said sandbox.
Handling everything all at once seems like like it would be worse for security then the individual prompts to allow access. Kind of like how bad all the cookie prompts are on web pages. They have an “Accept All”, sometimes a “Deny All”, and the option to select the cookies buried somewhere in a bunch of menus.
> Also, this isn’t something I’ve seen in any mainstream OS,
> but the option to run with full permissions in a sandboxed
> environment is something I’ve had on my wish list.
This is what the “github/containers/bubblewrap” project is doing, and it’s being used with many Flatpak applications.
Of course, fixing user space to begin with would have been preferable.
Flatland_Spider,
But why can’t you offer the same granularity with a simpler composite dialog box instead of popping up several one at a time? That is much worse to me.
It’s always tougher to change the model after the fact. By the reason I’d like more sandboxing options is because it provides isolation without succumbing to the “you need to grant permission before you can run this application”, which I consider deeply flawed. I want to be able to run an application safely in the sandbox especially when trying out new apps. I’d like to put apps through their paces before actually granting them permissions.
Just like MS Office blocking macros even though I took the time going through 5 levels deep into the options and checked the “enable without bothering me” box.
I hate being treated as an idiot in security contexts, just because 99.99% of users are.
Wow, seems like maybe it’s a blessing in disguise that my 2014-era Mac couldn’t update to Sonoma…
Looking it up… This started in 10.15 Catalina, so you’ve probably already been living with it.
Pretty sure I never had to deal with Granulat permissions as discussed in the article.
granular I meant, obviously
Luckily your workflow fits in the rails. Emacs and iTerm are two programs which come to mind as two programs I’ve had to tune permissions for. Emacs definitely stared in Catalina. I’ve kind of forgotten when iTerm started. iTerm asking for permissions happens pretty regularly for me.
“Tonight an old man yells at the clouds. Find out more tonight during the News on 6”
Security is hard, especially the UI/UX part, but necessary. The computing industry has ignored security for decades, and now we’re having to go back and fix it.
Retrofitting user land security onto operating systems which had no concept of user land security is making people think about security.
That’s the entire story here.
There are other models. OpenBSD has pledge and veil which requires the program to declare what access it needs in the code, which is very similar to what’s going on with MacOS, which is great for services, but not necessarily the best for programs people are going to regularly use. (I’ll have to see if there’s a way to adjust this at runtime. It’s been a while.) There are MAC frameworks like SELinux, AppArmor, and Capsicum, which aren’t the friendliest, requiring people to write access policies based on their usage. MAC policies are even more intrusive, and they have a tendency to fail silently which isn’t helpful.
There was an article about how back in the day people were making fun of Symbian apps prompting for permissions, and other mobile OSes ended up adopting the same model because it’s the best way to handle permissions in a consumer OS. I think OSNews even posted the article.
As for macOS itself, this mechanism has been there for a while, I want to say 10.15 Catalina introduced this, and the prompts only happen once. After that, the permissions need to be adjusted in the Systems Preferences. The Systems Preferences piece could use some work. There are parts which are less intuitive then they should be, like there isn’t a simulator to see what the changes would produce.
Wait, Apple doesn’t just indirect the common Open/Save dialogs the way XDG portals do? I’ve never needed to grant Desktop or Documents permissions to any Flatpak-installed application that uses QFileDialog, GtkFileChooserNative, or GtkFileDialog for opening and saving files.
(The downloads folder or music folder or somewhere else where I want it to be able to batch-download or provide its own UI for managing a library of something, sure… but not Desktop or Documents.)