[userbinator]

Personally I hope once the global filesystem concept will be gone, and apps will use isolated or shared storages where shared storage will get explicit access rights for each app/user it is shared with

I very much hope not, since default and easy global sharing is what makes desktop OSs so very useful, and a lot of this sharing is spontaneous, creative, and ad-hoc. Besides, we already have things like filesystem permissions. By all means have a sandbox for "the untrusteds", but I don't want the equivalent of being forced into the "everything which is not explicitly allowed is forbidden" bureaucracy.

[kodfodrasz]

Filesystem permissions cannot be controlled on a per app level. I do not like the fact, that an installation of for example a game needs admin rights, and has every chance to access data it should not be able to do.

I see your point, that the current solution offers a simple (and vulnurable solution). This is why I have said that these challenges need to be addressed. The current solutions may not be the best, but for an evolution to start we need to make changes, and try different approaches.

[userbinator]

Filesystem permissions cannot be controlled on a per app level.

I thought that's how Android's filesystem permission works? Each app runs as its own "user", and the FS permission bits restrict what it can access. This is a common solution in the Unix world. The problem on Android is that the filesystem is relatively hidden, and there's no easy way to change those permissions to allow more or less access.

Perhaps having the user as "root", along with all the actually-trusted apps (including those from the OS), and everything else setuid to their own per-app users, would be a useful configuration. Everything that's fully trusted is free to interact, while isolating those which aren't.

I do not like the fact, that an installation of for example a game needs admin rights, and has every chance to access data it should not be able to do.

That's possibly because of a need to install kernel-mode components (might be DRM related). If you're truly paranoid, VMs would be a better choice for isolation. But fundamentally, I don't believe in installing/using/changing apps that I don't completely trust, so perhaps this is a less of a problem for me and I'd rather have everything be "open".

[flukus]

> Filesystem permissions cannot be controlled on a per app level

They can if you adopt a user per app model. I thought this is what android/UWP did under the hood.

> I do not like the fact, that an installation of for example a game needs admin rights, and has every chance to access data it should not be able to do.

I doesn't. The biggest cause of this is the default of requiring admin to access program files, even if it's only touching it's own new folder.

Installing off steam happens without admin rights, apart from the VC++ redistributable (why is that a thing?).

[WorldMaker]

Steam is a terrible security example because Steam just gives Everyone Read/Write/Execute access to its folder(s) on Windows. The Steam solution to permissions on Windows has always been to basically just give up and not bother.

[flukus]

Has it ever been a problem in practice? I'm not aware of it ever being one. Worst case scenario some malicious software destroys a game install and some saves, unpleasant but not the end of the world.

It comes with some great benefits though, like easy modding. Imagine if my text editor couldn't access my games folder?

[WorldMaker]

Every day I'm surprised there hasn't been some malware that strikes at the default Steam install locations. The malware would not need admin access, could easily just wipe out the whole directory and be a noxious pest. More concerning, with a bit more work malware could trojan every EXE and/or DLL in the directory and likely won't get caught [1]. Once trojaned, all that any of the EXEs need to do is pop up a decent mockup of Steam's "Installing VC Redistributable" dialog [2] and get an easy UAC prompt opportunity (that Steam has already taught most gamers to expect semi-regularly) and from there full admin rights...

Not that I want to give malware devs any ideas, but I would be surprised if the above never crosses their minds. I suspect the main reason that it hasn't happened to date is that most malware devs are likely gamers and don't want to defecate where they eat.

As for the "great benefits", as much as I like modding, I like my system security a little bit better. There are definitely ways to do modding both securely and easily (and reproducibly) using things kind of like Docker containers and patch overlays, and I'd love it if, say, Valve invested some time into that as a secure platform service. For some of the games it supports Steam Workshop gets sort of, partly there, some of the time...

(But ultimately, I think game developers mostly don't care about security and Steam especially isn't very well incentivized to move out of the dark ages anytime soon. Bringing things back around, I'm hopeful that with the UWP platform exploring things like modding as a service we'll at least see that sort of innovation from Microsoft and the UWP converge towards the best of all worlds, eventually, hopefully...)

[1] Steam has a baroque assortment of DRM and anti-cheat mechanisms, obviously, but only while it is running and even then most of them are passive when a game isn't running. Steam absolutely has no idea what would be legitimate modding to game EXEs (as many mods do that) and what would be trojan-ing. Most people leave Steam running just about all the time, which locks down some of Steam itself, but not everyone does and all it takes is finding one good crash vector for Steam...

[2] Steam also seems to be several anti-practices here because as far as I can tell Steam doesn't ever bother to check if VC Redistributables or DirectX are already up to date on the system, it just spams the installers regardless...

[emodendroket]

Well, I mean, if I'm picking, I'd rather other applications can get to my games folder than the other way around.