Hacker News Reader

Comment by AnIdiotOnTheNet | Hacker News Reader

It's high time we started enforcing that by default at the OS level.

It’s notable that you bring this up in a news story about PC gaming, which is a prime example of why this shouldn’t be enforced. There are huge community efforts around modding games—adding features, updating old titles, improving performance, etc etc. All of this is essential to PC gaming, and all of it becomes impossible if software is sandboxed.

You can look at macOS as an example. Using the command line I start searching through my home directory. I get a pop up saying, "Terminal wants to access your Contacts: yes/no" "Terminal wants to access your Calendar: yes/no." This is the kind of behavior I think most people would like.

An example of the bad side is that Nvidia says they cannot develop drivers for their cards because Apple hasn't allowed them to (Apple develops the drivers). I technically believe they can, but they would have to make the user jump through some very unreasonable steps (reboot into a maintenance mode and disable integrity protection).

> I technically believe they can, but they would have to make the user jump through some very unreasonable steps (reboot into a maintenance mode and disable integrity protection).

Just confirming this is accurate. SIP wouldn't need to be disabled completely, just the blocking of unsigned kexts. (Apple allows you to selectively enable and disable pieces of SIP).

I don't think this would be so wholly unreasonable. The types of users installing third party video cards in their Macs are the types of users who should know how to do this. At the cost of their security, you could argue, but of course you still have normal Unix root restrictions to protect you there, as long as you're savvy enough to not grant such permissions to any random software.

You as the administrator should have the ability to change what you see fit. But a program should be sandboxed in such a way that it cannot willy-nilly obtain a copy of another programs data. I know ultimately there must be a way for to it to happen, but it should be explicit. In this case the Epic Launcher should, on access to Steam "sandbox", a OS dialog pops up so you can allow or prevent it.

DOSBox is a sandbox and I mod DOS games all the time as a hobby. I can run modded games in Sandboxie, or in containers in Linux. I fail to see how sandboxing is at all incongruent with modding.

Unless of course by enforce you mean taking control of the sandboxing away from the user, in which case I totally agree that should not be done because I'm against that kind of user-hostile bullshit.

> Unless of course by enforce you mean taking control of the sandboxing away from the user, in which case I totally agree that should not be done because I'm against that kind of user-hostile bullshit.

Nearly every effort I've seen by OS makers to implement sandboxing by default also makes the sandbox difficult or impossible to disable. iOS, UWP, the list goes on. I agree they shouldn't be connected, but they nearly always are. And it's always done in the name of protecting users.

macOS is the one bright spot here, and even then, the new dialogs in Mojave that can't be disabled fare crippling if you make heavy use of apps that need access to other app's sandboxes[1]. I'm convinced that if Apple moves to ARM, it will likely come with a massive tightening on user restrictions, in the name of security.

[1] https://apple.stackexchange.com/questions/339509/edit-tcc-db...

Be that as it may, we both agree that OS developers taking control away from the user is orthogonal to application sandboxing.

Sandboxing should be done, treating users like children who need to have control stripped from them for their own good should not.

If basically every example of by-default application sandboxing also results in a loss of user control, are they really orthogonal?

As soon as you implement the option at an OS level, there are going to be (many!) developers who want it enforced for all users. It's the obvious path to go down.

I'm not sure why this is the case. I don't see why you wouldn't be able to edit things that are in the sandbox (you create it in the first place, after all), whilst making sure things in the sandbox can't access anything outside it. AFAICT, it's basically just running as a different user. User user gets edit access, Epic user only gets access to its own folder.

The problem is that third-party-Dark-Souls-modding-tool.exe needs access to Dark-Souls.exe’s sandbox.

Note, I use Dark Souls as an example here (as opposed to, say, Skyrim) because Dark Souls mods were very much not developer-sanctioned at the outset. If From Software had needed to explicitly allow mods, you can bet they never would have happened.

So then you give it access. Nobody is saying that you, the user, should not have control over these sandboxes.

I think most current examples of sandboxing also implies app signing and whatever restricts users' own control, hence the confusion. Users are sometimes allowed to lift the restriction but it's mostly an all-or-nothing bet.

I am already enjoying this on my Windows Store delivered games.

You can surely think about a model of sandboxing with public and private (even internal for company wide) restrictions.

That's what UWP does on Windows. And it was immediately derided by nearly everyone for being too closed down.

That's because any benefit UWP brought was outweighed by all its drawbacks, at least for me.

UWP was broadly criticized because of how it operated. Every notification I got from UWP was something along the lines of "In order to rename this file, _____ program needs access to LITERALLY EVERY FILE AND PERMISSION AVAILABLE ON YOUR COMPUTER AND/OR HOME NETWORK"

Maybe if these notifications were less vague, they wouldn't be hounded as annoying and useless... Just saying.

Sure, but don't forget about user consent part. Preferably with an option to give that consent just once. Otherwise, you'd destroy a whole dimension of software interoperability and end-user scripting.

This is kind of a legacy desktop issue these days. The mobile OSs and all the cloud stuff use things like containerization and chroots.

Reply on news.ycombinator.com