[milgra]

I don't know the exact issues but might be related to the issues why I left Apple : I was developing a very successful little tool for MacOS ( https://github.com/milgra/macmediakeyforwarder ) which listened for keypresses. From 2016 to 2019 it became harder and harder to install it because apple added more and more restrictions to apps like this. By 2019, you had to enable the application explicitly to listen for events at least in three places deep down in the system preferences, click accept in various popups and if you stuck somewhere then nobody could tell why it wasn't working. So I had a very expensive laptop and the OS didn't let me use it freely. So I just switched to freebsd and linux. Hardware quality is far away from Apple's but it is cheap, I don't have fancy productivity apps like photoshop and final cut but with open source tools and with my own desktop applications I created the best looking/most usable desktop experience MacOS will never have. ( https://swayos.github.io/ )

[kitsunesoba]

I think permission systems are bound to wind up in all desktop operating systems, eventually. They’re already on Linux for those using Flatpak. Trusting random third party binaries with access to everything is increasingly too much of a gamble, even for more technical users.

That said, I agree that the macOS implementation has issues. It’s tricky though, because if they make it as simple as confirm/deny dialogs, you’ve set users up to quickly succumb to “yes-click syndrome” which is likely why Apple went with the “flip a switch in a preference pane” design for some permissions instead.

[tsuujin]

“Click yes syndrome” is so prevalent is has an actual name: banner blindness.

Last year you might have heard a court case talking about a nurse who killed a woman by accidentally giving her the wrong medication. She took responsibility but talked at length about how the system in place encourages workers to blindly click yes on alerts about medication because there are many of them. The training they got was basically “just click yes three* times” (* I don’t remember the actual number but three seems right).

One of those warnings could have saved a life had she read it, but she had been clicking yes many times a day every day for a long time and she no longer even saw the banner for what it was.

Interesting stuff from a UI/UX perspective.

[wkat4242]

"Random third party binaries" are not something Linux users really use, generally. Most of it is open source and comes through the repository.

[KerrAvon]

Insecurity through obscurity is possible even in open source. See log4j, but there are other examples — and infinite proof of concepts of people breaching repositories. Even on the desktop, you want multiple layers of security to limit potential damage.

Do use Linux on the desktop and be happy if it makes you happy, but don’t smugly assume you’re immune to the outside pressures in today’s world that are causing Apple to institute basic UI security measures on macOS. This isn’t a walled garden issue, it’s “make sure the user knows this binary is doing something that allows it to be a keylogger if the developer is so inclined.”

[wkat4242]

Well yes but Linux has had solutions for this a long time. AppArmor, SELinux.

Some distros like RHEL already bundle apps with profiles that make sure the app can only do what it's supposed to do.

[ilyt]

SELinux in particular is complex enough many vendors just give up and write "disable SELinux" in install manual...

Also it is totally not fit for the "ask user for permission" model.

[cglong]

It worked for Android! https://source.android.com/docs/security/features/selinux

[stametseater]

Indeed. The idea of flatpack is to change desktop linux culture by normalizing the installation of 3rd party software, particularly proprietary software that people otherwise wouldn't trust without some form of sandboxing.

Who does this benefit? I can think of two groups of people. 1. Commercial software vendors who want more Linux users to install their proprietary software. 2. 'Transplants', new Linux users who are already accustomed to the Windows/MacOS style of wantonly installing proprietary third party software they downloaded off random corners of the net, and don't want or know to change their habits.

The value proposition for experienced linux users who don't do that sort of thing in the first place is next to nil. The only applications that might benefit from such sandboxing are applications like browsers, which have large attack surfaces and might be compromised while browsing the net. But even this is mostly theoretical, not a realistic day-to-day concern for typical linux desktop users.

[MayeulC]

> The value proposition for experienced linux users who don't do that sort of thing in the first place is next to nil. The only applications that might benefit from such sandboxing are applications like browsers, which have large attack surfaces and might be compromised while browsing the net. But even this is mostly theoretical, not a realistic day-to-day concern for typical linux desktop users.

You are jumping to conclusions here. RCEs are probably more common than you think, and I'd prefer anything that interacts with the Internet to be sandboxed.

Flatpak allows me to easily sandbox Steam games. It provides an easy target to tell user to test against to eliminate distro-specific issues. It allows to run glibc-only software on distributions such as Alpine. It allows me to have multiple versions of a program installed concurrently. It prevents programs from cluttering my home directory, and sandboxing gives me extra peace of mind. As a non-root user, I can also install flatpaks. Ostree also usually makes updates more efficient.

If you use a couple flatpak apps, they are available regardless of your distribution. That helps when working on multiple different distributions.

Use an old-ish debian but need a feature from the latest unstable software ABC? Install ABC as a flatpak, and do not compromise the stability of the base system by enabling all sorts of external, unstable sources.

[Jasper_]

for 6 years you could get root on Debian with the "beep" command

[stametseater]

In those 6 years, how many programs packaged and distributed by Debian were exploiting that?

If you can run the "beep" command, you can also edit the user's environment and from their easily escalate to root anyway. In modern desktop linux, the user is almost always the admin as well, a single person using their personal computer, so getting root is merely a matter of waiting until the next time that user uses sudo/etc. Windows tries to mitigate this sort of attack using secure UAC prompts that are apparently difficult for attackers to emulate, or so I've been lead to believe. But common desktop Linux distros don't require anything like that. Instead, the user has to be cognizant of such possibilities and not run programs from people and organizations they don't trust.

[wpm]

Yeah, because I definitely double check the provenance of the 30 dependencies that blow past my terminal when I apt install something, that I also very much looked into and aren’t blindly typing commands from Stack Overflow into my terminal because I’m trying to solve some problem.

[em-bee]

because I definitely double check the provenance of the 30 dependencies that blow past my terminal when I apt install something

why would you? that's the package maintainers job. each of these dependency also has a maintainer, so by definition all dependencies have a provenance that is as good as the package you are installing.

this is not npm where anyone can upload something and you have to check the provenance of each yourself

[kitsunesoba]

Repos are generally safer yes, but they can still act as vectors for malware.

There’s also systems like Arch’s AUR which is quite popular and more likely (if still unlikely) to carry malware, to the point that the Arch Wiki warns that use of AUR is at the user’s own risk.

Plus, many people are going to need to use proprietary software, which is always an unknown and likely to act badly in any number of ways. A lot of such software is Electron-based to boot, and devs are notorious for using ancient (and vulnerable) Electron versions.

[mvanbaak]

every package system (apt/yum/pkg/whatever) is distributing binaries. So yeah, the upstream project can be open source, but there is 0 guarantees that the binary I install on my system is the exact same binary as I would get if I build the source myself (and this does not even touch on the subject that compilers can add weird stuff as well)

Sure, it's better than closed source, because at least you have the possibility to check all this. In practice though, we outsource this responsibility to the package maintainer of the package system we use.

[em-bee]

there is 0 guarantees that the binary I install on my system is the exact same binary as I would get if I build the source myself

not true, for years there are efforts in various distributions to make package builds reproducible. there are ways to build a package from source that allows you to get the same results and verify it.

we outsource this responsibility to the package maintainer

which is the point. i trust the package maintainers to do a better job at that than myself.

[sandworm101]

Except when it comes to hardware. Proprietary drivers are still widespread.

[jcastro]

Citation needed?

[pjmlp]

curl | sudo bash

[jasonjayr]

> Trusting random third party binaries with access to everything is increasingly too much of a gamble, even for more technical users.

Regardless, I'd still like the final say in making that decision, otherwise it's not really my computer anymore, is it.

[kitsunesoba]

Escape hatches should exist, but I think it's better if those exist on a per-program basis.

If a systemwide "disable all safeguards, give all programs access to everything all the time" switch exists, the level of friction encountered when accessing it should be very high to help deter social engineering attacks. It's a one-time action so the annoyance level of that friction is negligible, since those using it will only need to do so on clean installs.

[kergonath]

This why there are settings for this sort of things. Nobody in this thread is saying that something was impossible, just that some settings had to be changed and the UX was suboptimal.

[Blikkentrekker]

These permission systems in practice don't really do as much to shield users as many think though.

People often just drop the word “sandbox” and say “applications are sandboxed” and that that means that they're safe but it's really not that simple in practice. What often happens is that such applications still need to communicate over some socket with some server that was never designed for such a sandbox, say PulseAudio, and in many cases can then simply instruct the outer daemon to do whatever they want with full permission, either by design, or by oversight since the no one who wrote the outer daemon thought about it at the time since they were never designed for that purpose.

[kitsunesoba]

Of course, but that just means that said daemons need to be reworked to not have access to everything either.

This is why there's a push to do as much as feasibly possible in userland in both macOS and Linux, so even when a bad actor tries to route through system components the blast radius is limited. Realistically, they should be sandboxed too — an audio daemon for instance has no business directly accessing storage or network facilities for example.

[phkahler]

>> I think permission systems are bound to wind up in all desktop operating systems, eventually

What I'm about to say may seem wrong, stupid, or crazy at first. I think permissions often belong in the GUI. Applications would get no access to the file system directly, but they could use an API in the gui to open files - only files that are granted access by the user, often by selection in a File->Open dialog or other direct user interaction. By putting the granting of access in the GUI toolkit, we can run untrusted apps natively with no OS permissions.

Maybe not directly in the GUI, but something like that. Trust the user but not the app.

[CamperBob2]

At some point you have to trust the user to choose the apps they want to run. That's simply not the OS's job.

To the extent that it is the OS's job, you don't have a computer anymore. You have an appliance. Sometimes that's OK; I don't complain because I can't run Doom on my dishwasher. But let's be clear about what is a general-purpose personal computer, and what is not.

[kitsunesoba]

> To the extent that it is the OS's job, you dn't have a computer anymore. You have an appliance.

In my opinion, that depends on the existence of an escape hatch. If it's like iOS where there effectively is none, sure, but if it's like macOS where SIP, Gatekeeper, etc can be temporarily disabled to make changes and then re-enabled or disabled entirely it's a different story.

[fomine3]

That what Microsoft WinRT/UWP/whatever implemented.

[equivocates]

Maybe this is an unpopular opinion, but I prefer my OS put several hurdles in front of a key logging app.

[milgra]

Even if you downloaded that app explicitly for key logging? That's crazy! :)

[tourist2d]

... and the OS is supposed to determine your intent how?

[noisy_boy]

By whatever mechanism the OS has to verify that you have the privilege. E.g. sudo. Not by raising a plethora of hurdles.

[oefrha]

An admin password prompt is hardly a deterrence to people doing stupid things. A young physics PhD friend of mine fell victim to a tech support scam, happily installing whatever spyware “Apple Support” told her to install over phone. That was a few years ago. The average person is too easily social engineered into allowing anything.

[wutbrodo]

Sure, I don't think either this[1] commenter or Ken Thompson were trying to say that the product category shouldn't exist. A computer is vastly overpowered for what the average user is capable of or interested in doing[2], which is why toy devices like iPads are so popular.

I interpreted both of their comments as claiming that the direction MacOS is taking is a poor fit for those who still get value from powerful, general-purpose computers (myself very much included! I occasionally have the misfortune of using Macs, but am much much happier on systems where I can dig as deep into its layers as I need to solve my problems or scratch my itches)

[1] https://news.ycombinator.com/context?id=35219381

[2] Though I do think it's a minor tragedy that the increasing amount of guardrails has narrowed the opportunity for an inquisitive youngster to explore his computer's internals

[noisy_boy]

> The average person is too easily social engineered into allowing anything.

How many "average" users you know who use sudo? At some point, the software needs to acknowledge users who are saying "I know what I'm doing and the risks, just let me do it" i.e. sudo.

[unethical_ban]

At what point do we say "that's her own fault"? How do we evolve to be alert to threats if we just hide them away and take agency from individuals?

[kergonath]

An admin check tells the OS that you are an admin, not that you know what the software does and that you are ok with CoolWallpapers logging all inputs.

[noisy_boy]

It also tells the OS that I have root privilege and I should know what to do with that power, not babysit me.

[amelius]

They should have built this in from the start then, not semi-randomly break things.

[jen20]

This is a bizarre argument.

Do you feel the same way about Windows finally starting to take security seriously back in the mid 2000s?

[amelius]

Security should never come as an after-thought.

This especially holds for complex systems with multiple stakeholders, like OSes.

[jen20]

So what should happen when the threat model changes? Just abandon all software, ossify it in a poor state, or something else?

You always to be advocating for ossification to avoid breaking apps which are no longer ok under an evolved threat model.

Finally, you didn’t actually answer the question I asked. It’s all very well and good to say how things should be, but people have to face the world as it actually is instead.

[Blikkentrekker]

“keylogging” is such a moral panic.

If applications can edit arbitrary files on the system it's already game over. I have no idea why people focus so much on “keylogging” as the supposed super important and dangerous thing.

If one run any malware with the full file edit permissions of one's user account at that point in theory the only solution is erase not only the hard drive, but also every other drive on any other system one's user account has access to or at least in sofar those do not have some logging for connexions in some way to see who connected that cannot be edited by the permissions one has on that system. Of course if one has root on one's own system nothing on that system can be trusted any more from that point. The malware could in theory have edited the firmware at that point to hide any checks one could do with a recovery system on a portable drive, but that's all quite theoretical of course, but it's possible in theory.

Keylogging is such a strange thing to focus on in the face of being able to edit arbitrary files owned by the user.

[sys_64738]

Oh I dunno, maybe because there's so few third party needs to log keystrokes from the user. When that need arises then you have to ask why...

[Blikkentrekker]

It doesn't matter and it's still a theatre. Those malicious applications can do what they want regardless by editing arbitrary files and obtain the same end.

The supposed threads of malicious applications keylogging and stealing your website passwords to worry about is rather strange when such an application can edit the files on your system such that you're starting a modified version of a web browser they injected with whatever code they want to do the same. In fact, this is probably easier to do than try to write some kind of a.i. that filters what it thinks are “password keypresses” opposed to altering the code of the web browser such that it simply sends whatever is being put into a field marked as “password” on a website.

It's a moral panic boogeyman that has no actual implications for actual real life security. Like quite a bit of “security” talk these days. Much of it comes down to the “door in your room” analogy where “security experts” talk about putting a big door in the middle of one's living room with an impenetrable lock on the idea of kindly asking criminals to only go through that door to steal things. In reality they'll just walk around it, and now one has an inconvenient door in the middle of one's living room.

[kergonath]

> By 2019, you had to enable the application explicitly to listen for events at least in three places deep down in the system preferences, click accept in various popups and if you stuck somewhere then nobody could tell why it wasn't working.

It’s an improvement for users because it means that not all random applications and programs that run can act as keyloggers. It’s optimising for the common use case (random people running random software and being very annoyed if they get ransomed) against the rare case. It’s the same thing with debuggers and attaching to other processes. In the end it is a good thing to not be able to do that without explicit authorisation.

> So I had a very expensive laptop and the OS didn't let me use it freely.

It does not prevent you from doing it. It added some friction, sure, and you can find that this friction is unacceptable (and changing OS every now and then is a good idea in general anyway). But from a fundamental perspective the functionality is still there. The OS still lets you do this.

> I created the best looking/most usable desktop experience MacOS will never have.

It is great that you have both the ability and the time to do this. I’ll look into it for my Linux boxes.

However, my experience is that it’s never actually “the most beautiful/user-friendly/consistent/polished” (things we see all the time with new DEs). They all tend to fall apart with millions of corner cases and inconsistencies every time you get off the beaten path. In any case, good luck with your project.

[elcritch]

Sure optimizing for security makes sense, but Apple isn't just doing that. They're also removing ways to override those restrictions. Often old methods to disable them or to whitelist an app silently stop working. Sometimes new ones don't always work, or require an absurd number of hops.

It seems alongside security there appears to be a strong desire at Apple to make macos a walled garden like iOS devices. They've hamstrung mobile safari for years to ensure the app store doesn't have competition from web apps.

[dtgriscom]

Given that it should be difficult, if not impossible, for random applications to listen in on user actions, is there a better way Apple could have done this?

(Disclaimer: Apple fan/user since 1985.)

[milgra]

A popup on the first start with an alert and a password prompt is a good solution, but usually too many users type in their passwords blindly in case of a password prompt, so I would go with just an alert with "you need root privileges to run this app" and then they have to figure out 1. why do they need root privileges 2. how do they start an app with root privileges.

[KerrAvon]

The security barriers for getting keyboard events in macOS are not as simple as “root has access to everything”, and for various reasons can’t and shouldn’t be that simple. So ignoring that part, Apple could make this into a one-click solution, but the number of legit apps that need to do this are so small that it’s very unlikely they will dedicate engineering time to it.

This is obviously where open source is superior. Apple probably can’t justify cleaning this up in macOS, but you can just go in and make it easier on on Linux if you have the knowledge and time.

[tomrod]

One click is preferred. Anything that gets in between a legitimate program and the user is friction.

[drivers99]

using Second Reality as the music for the swayos video was a pleasant surprise

[milgra]

I'm glad you liked it! I miss the golden age of tracker music/demoscene.

[Blikkentrekker]

The situation with Wayland is actually worse than this by far.

[asveikau]

Not sure what you mean.

But at any rate, Wayland is completely optional. You can keep running X and nobody will stop you. People will keep running X without issue for a very long time. This is very different from what the Apple world is like.

[Blikkentrekker]

> Not sure what you mean.

Many of the things one can at least ask permissions for as I read it on the Apple system are actually purposefully simply not available due to similar concerns.

Many of the leading Wayland developers believe in this. The Enlightenment lead developer for instance does not believe a programmatic way to make screenshots or listen to keypresses should ever exist. I had some debates with him about this and he believes the risks are too high as well as revealing that he seemed to believe that streaming videogames did not work by way of a third party tool that captures the screen contents, but that each video game had this functionality built in, which is certainly not the case and that he believes this might explain his reluctance for such an a.p.i. to facilitate this.

> But at any rate, Wayland is completely optional. You can keep running X and nobody will stop you. People will keep running X without issue for a very long time. This is very different from what the Apple world is like.

Opinions are divided on that matter. The reality is that many of the developers of Xorg have abandoned in in lieu of Wayland and many Wayland developers, many former Xorg developers are clear in their opinion that they see it as a replacement, not an alternative and eventually expect everyone to switch.

Whether that will happen is anyone's guess. They are often met with counter arguments that Xorg and the X11 protocol itself simply has features that many businesses and private individuals need for their lifelihood so there is going to be commercial incentive to pick up maintainership should they abandon it. They have also conceded heavily already on many of the features they initially said where either unneeded or a security risk when they realized the reality that many people outside of their bubble did use them. Libinput originally did not have any mouse acceleration settings on the argument that no one would want to turn it off or fine tune it to begin with, but now has it when they realized that unlike what they thought, demand for the ability to fine tune or turn off mouse acceleration is higher than they anticipated.

[jech]

> The Enlightenment lead developer for instance does not believe a programmatic way to make screenshots or listen to keypresses should ever exist.

Rasterman is entitled to his opinion, but every production-ready Wayland server ("compositor") implements an extension to do screenshots:

  * Weston: https://wayland.app/protocols/weston-screenshooter
  * Sway and friends: https://wayland.app/protocols/wlr-screencopy-unstable-v1
  * KDE: https://wayland.app/protocols/kde-zkde-screencast-unstable-v1

They haven't been able to agree on one common extension yet, granted, but the functionality is available.

[asveikau]

>> People will keep running X without issue for a very long time

> Opinions are divided on that matter.

I feel like those holding the opposite opinion are pretty clearly wrong and it seems to be some kind of hubris. Fortunately their opinion is not binding.

> The reality is that many of the developers of Xorg have abandoned in in lieu of Wayland and many Wayland developers,

Not an issue. It doesn't need a lot of maintenance. It's "done". Source is available too. Just needs minimal effort to keep the lights on. As long as someone is interested in running it, as many will be, it will happen.

[Blikkentrekker]

That is a very wrong view of something that communicates so closely with the hardware and deals with graphics.

It's very much chasing a moving target of new graphics technology and many of the innovations made by Wayland have been ported to Xorg. The interesting thing is that screen tearing used to be a problem on Xorg but never was on Wayland but much of the technology responsible for that has now found it's way into Xorg to make it a thing of the past there too. Of course integration with new hardware drivers is also required.

It's entirely possible it will continue to be maintained that way, or that the Wayland philosophy will finally be broken and these things will be added once they realize there is a great enough demand, but these are all possibilities, not certainties.

[dekhn]

I fully expect that when Wayland is completely deprecated, X will still be running in critical situations.