@ireneista @FenTiger The short version is that if you build packages the way upstream would (same version, bundled dependencies, etc), you can package a lot of things quickly, but you also don’t gain many benefits from packaging. If you try to ensure everything is built from the real source, with dependencies that are consistent across the distribution, one risks breaking applications (see Bottles and OBS Studio) and can easily burn out from the effort.

@ireneista @FenTiger Interestingly, I think accessibility is the opposite: Apple and Microsoft blow the open source tech out of the water.

@ireneista @FenTiger I have mixed views on this. The biggest problem I have with distro packaging is that it is O(N × M) (where N = packages and M = distros), which is O(N2). That’s not sustainable in the long term unless the number of distros stays small. Also, many applications use packaging-unfriendly technologies like Electron or Flutter. You can package a lot more stuff if you are willing to allow Internet access during the build or treat what npm install gives you as source code (spoiler: it usually isn’t), but the maintenance burden if packaging everything is incredible (and, IMO, often unsustainable).

@ireneista @FenTiger I think that is a problem with Apple and Google being allowed to build operating systems. GrapheneOS has less of that problem, and Qubes OS and Spectrum don’t have it at all.

@ireneista @FenTiger Yup, I’m working on virtio-IOMMU interrupt remapping right now.

@ireneista @FenTiger I think something like GrapheneOS’s scoped storage and contacts is the best solution to that. Apps think they have the broad permission when in fact they have much less access, and the OS tricks them so they are none the wiser.

@ireneista @FenTiger would you be able to help come up with a better system for Flatpak? There clearly needs to be a way to control access to things like location.

I’m a huge fan of “only this time” permissions.

@ireneista @FenTiger that I agree with.

@ireneista @FenTiger Education doesn’t solve the huge power disparity between application developers and end users. Only something that has more power than the app developer can do that. Another option is to lie to the app and tell the app that it has permissions that it actually does while giving it access to only a subset of information, which is what GrapheneOS does.

How would you make the permission taxonomies different?

@ireneista @FenTiger There is another factor, which is that most users will say yes to permission prompts (even ones that are not technically necessary) if that is what is needed to use an app they absolutely need to use. In other words, most users do need to be protected from app developers who know that users must use their app (perhaps to interact with some hardware device, or to do some other task) and can use that to coerce them into granting unnecessary permissions.

@ireneista @FenTiger I think a key reason it has a chance to succeed is that it throws the whole application in a VM and makes that the security boundary, which means that the application still thinks it has all the privileges it used to. It's very hard to impose OS-level sandboxing on applications without breaking compatibility and forcing developers to adapt, and that in turn is very difficult without significant market power.

@ireneista @FenTiger I’m actually working on something for them now 🤣

@ireneista @FenTiger I meant, “What would be an example of a “sandbox [that] actually answered to the user”?”. Hardware being under contract is a separate problem that should not be allowed in the first place.

@ireneista @FenTiger what do you mean by “answered to the user”? Users can run apps as root if they want?

@karolherbst why over?

@Theeo123 which literally can’t be done, because that’s how the math works. Service providers don’t have keys, and demanding passphrases from end users has been ruled a 5A violation.

@ireneista @FenTiger to elaborate, I can think of many problems with both iOS and Android: iOS doesn’t allow sideloading outside of Europe and is unusable without an Apple account, Android is far too tied to Google Mobile Services and to Google in general, and both Apple and Google use their mobile OSs in a way that is (to the best of my understanding) anti-competitive (see US lawsuits against Google and EU DMA lawsuits against Apple). However, I generally think of the sandboxing as a good thing: it means that an app compromise doesn’t automatically result in full system compromise, and allows limiting what an app can do without the user’s permission. Therefore, I am genuinely curious why you think it is bad.

@ireneista @FenTiger they almost do, actually. The only limitation is on JIT compilation of native machine code, and even that isn’t strictly enforced yet.

I totally agree that Google is not a good company for all sorts of reasons, though I am a big fan of some of their open source work. However, I am genuinely surprised that you listed sandboxing as the main problem with commercial mobile OSs.

@ireneista @FenTiger Why is that sandboxing bad?