Comment by ashishb

A better example would be requiring the mailman to obtain written permission to step on your property every day. Convenience trumps maximal security for most people.

Attempt at real life version (starts with idea they are actually not trustworthy)

  - You invite someone to sit in your living room
    - There must have been a reason to begin with (or why invite them at all)
    - Implied (at least limited) trust of whoever was invited
  - Access enabled and information gained heavily depends on house design
    - May have to walk past many rooms to finally reach the living room
    - Significant chances to look at everything in your house
    - Already allows skilled appraiser to evaluate your theft worthiness
  - Many techniques may allow further access to your house
    - Similar to digital version (leave something behind)
      - Small digital object accessing home network
      - "Sorry, I left something, mind if I search around?"
    - Longer con (advance to next stage of "friendship" / "relationship", implied trust)
      - "We should hang out again / have a cards night / go drinking together / ect..."
      - Flattery "Such a beautiful house, I like / am a fan of <madlibs>, could you show it to me?"
  - Already provides a survey of your home security
    - Do you lock your doors / windows?
    - What kind / brand / style do you have?
    - Do you tend to just leave stuff open?
    - Do you have onsite cameras or other features?
    - Do you easily just let anybody into your house who asks?
    - General cleanliness and attention to security issues

  - In the case of Notepad++, they would also be offering you a free product
    - Significant utility vs alternatives
    - Free
    - Highly recommended by many other "neighbors"
  - In the case of Notepad++, they themselves are not actively malicious (or at least not known to be)
    - Single developer
    - Apparently frazzled and overworked by the experience
    - Makes updates they can, yet also support a free product for millions.
    - It doesn't really work with the friend you invite in scenario (more like they sneezed in your living room or something)

> When I run 'notepad dir1/file1.txt', the package should not sneakily be able to access dir2.

What happens if the user presses ^O, expecting a file open dialog that could navigate to other directories? Would the dialog be somehow integrated to the OS and run with higher permissions, and then notepad is given permissions to the other directory that the user selects?

FreeBSD used to have an ELF target called "CloudABI" which used Capsicum by default. Parameters to a CloudABI program were passed in a YAML file to a launcher that acquired what was in practice the program's "entitlements"/"app permissions" as capabilities that it passed to the program when it started.

I had been thinking of a way to avoid the CloudABI launcher. The entitlements would instead be in the binary object file, and only reference command-line parameters and system paths. I have also thought of an elaborate scheme with local code signing to verify that only user/admin-approved entitlements get lifted to capabilities.

However, CloudABI got discontinued in favour of WebAssembly (and I got side-tracked...)

Redox is also moving towards having capabilities mapped to fd's, somewhat like Capsicum. Their recent presentation at FOSDEM: https://fosdem.org/2026/schedule/event/KSK9RB-capability-bas...

Seems like a bad time to bring this up when it wouldn't have helped with this attack at all.

Eli5, what is that supposed to mean?

> Yet we look at phones, and we see people accepting outrageous permissions for many apps

The data doesn't support the suggestion that this is happening on any mass scale. When Apple made app tracking opt-in rather than opt-out in iOS 14 ("App Tracking Transparency"), 80-90% of users refused to give consent.

It does happen more when users are tricked (dare I say unlawfully defrauded?) into accepting, such as when installing Windows, when launching Edge for the first time, etc. This is why externally-imposed sandboxing is a superior model to Zuck's pinky promises.

For all its other problems, App Store review prevents a lot of this: you have to explain why your app needs entitlements A, B and C, and they will reject your update if they don't think your explanation is good enough. It's not a perfect system, but iOS applications don't actually do all that much snooping.

Snap and Flatpak do both sandboxing and package management.

You can use the underlying sandboxing with bwrap. A good alternative is firejail. They are quite easy to use.

I prefer to centralize package management to my distro, but I value their sandboxing efforts.

Personally, I think it's time to take sandboxing seriously. Supply chain attacks keep happening. Defense is depth is the way.

Notoriously not actually secure, at least in the case of Flatpak. (Can't speak to Snap)

Not sure how something can be called a sandbox without the actual box part. As Siri is to AI, Flatpak is to sandboxes.

I tend to think things like .bashrc or .zshrc are bad ideas anyways. Not that you asked but I think the simpler solution is to have those files be owned by root and not writable by the user. You're probably not modifying them that often anyways.

Haha, yes, corrected. Thank you. I have a habit of fusing unrelated expressions.

> but in reality the system is thoroughly backdoored on every level from the CPU on up, and everyone knows it.

Indeed. Why lock your car door as anyone can unlock and steal it by learning lock-picking?

There's a subtlety that's missing here: if your threat model doesn't include the actors who can access those backdoors, then computer security isn't so bad these days.

That subtlety is important because it explains how the backdoors have snuck in — most people feel safe because they are not targeted, so there's no hue and cry.

I'm sure you're right; however, there is still a distinction between the state using my device against me and unaffiliated or foreign states using my device against me or more likely simply to generate cash for themselves.

It's still worth solving one of these problems.

The short answer is tech debt. The major mobile OSes got to build a new third party software platform from day 0 in the late 2000s, one which focused on and enforced priorities around power consumption and application sandboxing from the getgo etc.

The most popular desktop OSes have decades of pre-existing software and APIs to support and, like a lot of old software, the debt of choices made a long time ago that are now hard/expensive to put right.

The major desktop OSes are to some degree moving in this direction now (note the ever increasing presence of security prompts when opening "things" on macOS etc etc), but absent a clean sheet approach abandoning all previous third party software like the mobile OSes got, this arguably can't happen easily over night.

Mobile platforms are entirely useless to me for exactly this reason, individual islands that don't interact to make anything more generally useful. I would never use any os that worked like that, it's for toys and disposable software only imo.

Windows has had this for over a decade, but no one wants to put their application in a sandbox.

And then there’s dbus…

Damn file protection not even enough…