[DCKing]

The opsec reason I use Safari as a work browser today is that Safari has a much more blunt tool to disrupt cookie stealers: Safari and macOS do not permit (silent) access to Safari's local storage to user level processes. If malware attempts to access Safari, its access is either denied or the user gets presented a popup to grant access.

I wish other browsers implemented this kind of self protection, but I suppose that is difficult to do for third party browsers. This seems like a great improvement as well, but it seems this is quite overengineered to work around security limitations of desktop operating systems.

[ezst]

Seems like a very weak mitigation, if this is to protect against malwares running in your user session, alongside your browser. Can't they already do all kinds of nefarious keylogging/screen recording/network tracing/config file editing enabling impersonation and so on?

I mean, if my threat model starts with "I have a mal/spyware running alongside my browser with access to all my local files", I would pretty much call it game over.

[DCKing]

> I mean, if my threat model starts with "I have a mal/spyware running alongside my browser with access to all my local files", I would pretty much call it game over.

This is a big problem I have with desktop security - people just give up when faced with something so trivial as user privileged malware. I consider it a huge flaw in desktop security that user privilege malware can get away with so many things.

macOS is really the only desktop OS that doesn't just give up when faced with same user privileged malware (in good and bad ways). So there it's likely a good mitigation - macOS also doesn't permit same user privileged processes to silently key log, screen record, network trace and various other things that are possible on Windows and common Linux configurations.

[ezst]

Yeah, I'm siding with the sceptics on this one. Adding more layers of indirection against those malware running under a user session seem like a good idea in general, but in practice, you showed how ineffective the macOS approach is: under this model, every application is let to defend itself in an ad-hoc and specific manner. That doesn't generalise well: you can't expect every software, tool, widget, … vendor to be held to the same level of security as Apple.

Another approach is to police everything behind rules (the way selinux or others do), which is even better in theory. In practice, you waste a ton of time bending those policies to your specific needs. A typical user won't take that.

Then there is the flatpak+portal isolation model, which is probably the most pragmatic, but not without its own compromises and limitations.

The attitude of trusting by default, and chrooting/jailing in case of doubt probably still have decades to live.

[DCKing]

> under this model, every application is let to defend itself in an ad-hoc and specific manner.

This description of the macOS model doesn't really apply so I'm not sure if I'm misunderstanding you or you're misunderstanding the model.

> Another approach is to police everything behind rules (the way selinux or others do), which is even better in theory. In practice, you waste a ton of time bending those policies to your specific needs. A typical user won't take that.

While SELinux could probably provide this kind of data protection on Linux, the method of technical enforcement is only one part. There's a lot of UI involved to get right, and that will require far more effort.

> Then there is the flatpak+portal isolation model, which is probably the most pragmatic, but not without its own compromises and limitations.

That model doesn't really apply here. Flatpak et al allow applications to self confine in order to protect the other things the user is doing. What I'm talking about is for an app to have some protections of its own data from the other things the user is doing. I'm not talking about sandboxing, this data protection.

[ezst]

>> under this model, every application is let to defend itself in an ad-hoc and specific manner.

> This description of the macOS model doesn't really apply so I'm not sure if I'm misunderstanding you or you're misunderstanding the model.

I admit I might be misunderstanding, since, again, I don't use macOS. But from your description:

>>> Safari and macOS do not permit (silent) access to Safari's local storage to user level processes. If malware attempts to access Safari, its access is either denied or the user gets presented a popup to grant access.

it sounds like safari detects that a foreign application is trying to read its data, warn the user and lets them call the shot on that. I don't see how that isn't very specific to safari and to one specific type of mitigation. Unless the same prompt shows up for every program trying to access every other one's configuration? Then I suppose we hit the usability nightmare I'm on about, with utilities like ncdu, borg and others just unable to do their job.

> While SELinux could probably provide this kind of data protection on Linux, the method of technical enforcement is only one part. There's a lot of UI involved to get right, and that will require far more effort.

My experience with SELinux was not that of a problematic UI or ecosystem of utilities around it, but more one of incurred fatigue working against rules: once you've hit your tenth AVC denial trying to get something to run, you might as well want to disable SELinux altogether. Or maybe that's what you call UI? Either way, I don't think there is a viable "fix" for it.

>> Then there is the flatpak+portal isolation model

> That model doesn't really apply here.

I mean, I was merely stating facts about what's existing out there. Anyhow

> What I'm talking about is for an app to have some protections of its own data

This isolates applications and their data from one another, in that aspect they are relatable.

[fourfour3]

On macOS, basically all of these are extra permissions that you have to grant to an application - you'll get prompted with a popup when they try to do it.

eg: local network access, access to the documents and desktop folder, screen recording, microphone access, accessibility access (for keylogging), full disk access, all require you to grant permission