[Shank]

I think the most obscene thing here is that macOS is now littered with permission prompts for camera, background execution, etc, but makes no effort to stop even industry partners from spraying the disk with dozens of files that can’t be removed easily.

[functionmouse]

That's because this particular sort of cyber security is merely theatrics with the goal of reducing user agency and increasing paranoia and vendor lock-in. The user facing friction is the goal. There will always be scams and viruses; the only practical outcome will be that you have less control over your computer, and Apple/MS/Google have more. See: Sideloading, Wayland, UWPs, iOS JIT, Windows XP and 7 still being used for accessibility

[nerdjon]

I strongly disagree.

I often have apps on my Mac or iPhone that ask for permission to see my camera, microphone, contacts, etc etc that I don't want it to see. But I do want other apps to be able to access those things.

Being able to stop those apps from accessing before they do instead of trying to fix it after is incredibly valuable.

Sure some users just accept everything, but that is not an argument against them existing in the first place.

[alpaca128]

Those examples are very reasonable. However I also had Mac OS suddenly treat all m4a files on the system as potential malware and it blocked any attempt at opening them. Why did it do that? Because I checked the "set as default app" option, one minute after I had already opened the same file using the same application. The only way to open the files was by entering the password in the settings app each time - but re-setting the same app as default in the file's Get Info dialog got rid of that "protection" system-wide without any password prompts or extra permissions. I don't see how that was supposed to help with security.

[StilesCrisis]

I am pretty sure you're running into a bug and trying to make sense of a behavior that wasn't intended to exist.

[alpaca128]

This has been a thing long enough for online guides to exist that explain how to get rid of it. Fortunately, because setting the default program in a second place to get rid of a security barrier wasn't my first guess. When does a bug start to become an undocumented feature?

[StilesCrisis]

This certainly isn't the only Mac bug that would be old enough to drive.

[ryandrake]

We are moving away from the old world where you can trust the applications you are running on your computer, to today's world where you can't. The unix permission model is based on apps running as your user having access to every device and file you, the user, have access to. The threat was "other system users trying to access your files and devices" but now the threat is "applications you run trying to access your files and devices." OS vendors have been slow to adapt to this new threat model.

Even today, any rando application I download and run can read and/or write to any file on my system that I own and have permission to read and/or write, unless I go out of my way to run it in a chroot, a container, a jail or whatever. That's just poor security in a world where nearly every commercially developed application is an attacker.

[AlienRobot]

To be fair, this is partly because of the internet.

If you install random apps and it destroys your PC, you can fix that by having backups. By contrast on work computers with important data, everything is supposed to be locked down and you can't install random apps. But then we started to increasingly connect devices to the internet.

Now gaining access over a smartphone essentially means being able to send payments via the banking apps. People are sending money with crypto so they are susceptible to simple clipboard swap attacks that are almost impossible for the user to detect until it happens. Then there is all the personal data that can be stolen that can be used for other attacks in the future.

Essentially the amount of damage you can take by losing access has increased much faster than the security devices meant to prevent.

To make matters worse, the security devices that are marketed to the average user tend to be exploitative rather than trustworthy (e.g. OneDrive).

It feels like instead of protecting users developers seem more interested in creating something that only does half of the job and then blaming the user for not knowing how to do the other half, so a comprehensive solution for the problem is never created.

[ryandrake]

I think there are a lot of things that users can be protected from:

1. Protect users from attackers external to the computer

2. Protect users from attackers who are other users on the computer

3. Protect users from applications run by other users on the computer

4. Protect users from applications they themselves run on the computer

5. Protect unprivileged (non-root) users from their own actions

6. Protect privileged (sudo/root) users from their own actions

OSes have been historically OK at 1-3. Not great or even good. There have been a lot of remote code vulnerabilities and local vulnerabilities over the years.

OSes have pretty much ignored 4 until maybe a decade ago, and are making token progress toward it, but I don't think many of them take it very seriously.

OSes have instead started to crack down on 5-6, which I'd argue isn't even the job of an OS.

[dcrazy]

macOS now implicitly sandboxes your Documents, Downloads, and Desktop folders. Random apps can’t read from those locations without triggering a security prompt.

[anthk]

Namespaces in 9front (actual ones, not second hand ones like under Linux) makes isolating software trivial.

[perching_aix]

> this particular sort of cyber security is merely theatrics with the goal of reducing user agency

Literally all security features carry the hazard of being used for oppression and being ineffective or counter-effective. That's how constraints work.

You need two things for a security feature:

- a segmentation under which a behavior is considered unsafe / unsecure (arbitrary, subjective)

- a technical solution that constrains the behavior of <thing> in <usage context> so that the aforementioned is mitigated

So something being "a tool of oppression" or "a tool of safety" is a matter of your alignment with that segmentation. And it being a theater or not is a matter of functional soundness given a threat model. So is its tendency to become counter-effective.

Constraints are just constraints. Whether they're effective and whether you're disadvantaged by them are both separate, independent matters. Empirical too.

[Zak]

I think we're on the same side in principle. The ability for people to interact with the wider world using general purpose computers that they fully control should be sacrosanct, and attempts to interfere with that such as remote attestation, app store exclusivity, and developer verification are evil.

Sandboxing apps by default is not that. The principle of least privilege is good security. If I vibecode some quick and dirty hobby app and share it with the world, it's better if the robot's mistake can't `rm -rf ~/` or give some creep access to your webcam.

The user should be able to override that in any way they see fit of course.

[lpcvoid]

>Wayland

I can see the rest, but why did you mix in Wayland, a open source display protocol?

[grufkork]

I think there's some controversy regarding that programs are limited in what extent they can access each other. You need sudo to do global hotkeys/keylogging, probably accessing pixel contents of other apps, etc. I suppose they mean it only prevents some specific threats while leaving open goals in other, even more easily exploited places

[Kaliboy]

Maybe I don't understand your point, but why is Waylabd in your list?

[404mm]

It’s like they went backwards on this. The utility that handles .pkg files used to have a command line uninstall option.

Anyway, I kinda like PearCleaner for removing the cruft. It’s not perfect but it’s open source and one of the better options imo.

[SilverElfin]

You often cannot even tell what the permission prompts are for. Sometimes they have generic names like a programming language is requesting something. Not sure what that’s about.

[milkshakes]

those are interpreters, the language is interpreted by a binary called `ruby` or `python`, for example, so that happens to be the process that's requesting the permission