[kodfodrasz]

UWP is limited as it is relatively new. The new (capabilities based) security model is clearly better than the old "if you are admin, you can do whatever you want" model. The old model was inadequate even at the start of the multimedia age, but it was not recognized until recently. The new sandboxed operation creates more portable and reproduceably operating apps.

The limitations will show, as more and more usecases will be attempted, and surely many will be addressed.

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.

The old system had defaults originating from the single user non-multimedia usecases left over as a legacy, but currently we have so many things going on our computers, that privacy/security needs a rethinking of old concepts to cope with new challenges.

[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.

[koko775]

WinRT means:

* No app closure callbacks. You don't know if it's suspending or exiting.

* No "are you sure you want to exit? Save/Don't save" dialogs. If you close or crash pray your data was saved, and if it takes a long time to flush to disk...really pray.

* No minimizing/backgrounding to tray icons allowed.

[kodfodrasz]

* I guess You can create a background worker handling persistence, which runs until completion even if the UI has been closed. (I have not used UWP yet)

* IMHO save/don't save dialogs are an usability antipattern.

* Tray icons are also something of a remedy of the past. They are now replaced by background operations and live tiles. I can see why those can be problems, I can imagine the usecases you would solve using those tools, but the new app model is build around a slightly different workflow.

But if you do not like the way to solve it as it is intended in the new app model, the solution is: report it/upvote it. If you tell your problems here, then some members of HN community will know it and understand it, but it is unlikely that it will be acted upon by Microsoft. For that you need to have your voice heard on their forums. (eg. feedback app, uservoice...)

[emodendroket]

> No "are you sure you want to exit? Save/Don't save" dialogs. If you close or crash pray your data was saved, and if it takes a long time to flush to disk...really pray.

Of course not, because it's supposed to also work on mobile. Does your iPad let applications prevent you from going back to the home screen?

[flukus]

> Of course not, because it's supposed to also work on mobile. Does your iPad let applications prevent you from going back to the home screen?

You don't see the problem here? Why do I want the restrictions of mobile phones limiting my desktop applications?

[emodendroket]

Well, for one, I don't see how else the concept of "universal apps" could possibly work.

[flukus]

Neither do I. The question then becomes "should they exist?".

[emodendroket]

It might not be a good fit for Office. But it seems fine for some applications.

[WorldMaker]

There is a Suspending callback.

Sounds like you have some misconceptions about the UWP/WinRT application lifecycle:

https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/a...

[m_fayer]

If I recall correctly, this callback has some undocumented deadline. Go over that and it's unceremoniously killed, great way to corrupt whatever you're desperately trying to write to disk.

[WorldMaker]

No, it is a pretty well documented deadline at this point. The callback is not intended for I/O work, but to clean up resources or to spin up any background tasks you might need for I/O. There are lots of articles full of best practices for the app lifecycle. Yes, it's different than Win32. Yes, it's influenced by mobile and low resource environments. But it's better for it and worth learning.

[flukus]

I really disagree with UWP being a better model than limited UAC. Apps being able to talk to each other and the filesystem and interacting is what makes them useful. The linux/sudo approach is the best comrpomise between security and utility I'm yet to come across.

> The old system had defaults originating from the single user non-multimedia usecases left over as a legacy, but currently we have so many things going on our computers, that privacy/security needs a rethinking of old concepts to cope with new challenges.

I android has proven anything it's that sandboxed applications don't solve this problem.

[raesene6]

Generally the way I've seen sudo implemented in all desktop linuxes is that after providing a password the process gets all access.

This to me isn't a great trade off as it relies on the user invoking the process understanding the security risks they're taking, which is a tricky one.

Sure you can do more with sudo, but unless it's the default, most people won't

[flukus]

There's room for improvemnt, it's just the best trade off I've seen. Windows has it's "click yes to continue" buttons, android has it's permissions thing that is useless to everyone. At least making people pause and type a password might make them think about what they're doing a bit.

[icebraining]

The best trade off I've seen is what Nokia's S60 (and iOS, or so I've heard) did: have granular permissions like Android, but show a dialog when the app first tries to use them, instead of having a laundry list at installation time.

You're more likely to think twice when you open your flashlight app and it asks "Do you want to allow [Flashlight App] to read all your contacts?"

[flukus]

It that once off or every time? There have been a few Android apps that started off OK and transitioned to spyware.

[rahoulb]

On iOS it asks the first time the app wants a particular permission but doesn't ask again. If you want to change your initial choice, you can head to Settings and view/change the grants/revokes by permission or by app.

[icebraining]

Can't remember. Still, I don't think it matters - if you know an app has turned into spyware, why are you opening it again instead of uninstalling it?

[swiley]

The global filesystem is only a problem if you run lots of closed source/untrustworthy apps. Many of us don't and use the global filesystem very heavily and very much hope it does not go away.

[UK-AL]

Except for the vast majority of people are not IT experts. The store model is probably vastly safer for the average user.

[garganzol]

An average user is a myth. Every kind of average user has its own traits and they differ widely.

That's why there is such thing as system settings.

And yes, most desktop users are conscious when they work with files. Windows by default suggests "My Documents" folder as a target destination which is a pretty sane safe choice for all traits of average Joes.

[UK-AL]

That not the issue though. Programs that plaster your registry full of crap or replace or change os files etc

[flukus]

That can be solved by not requiring admin privileges to install software and getting rid of the registry, which was an awful idea to begin with.

[swiley]

Don't run stuff as root then.

[swiley]

Honestly I think not having a global filesystem makes things harder for the "average user." Most college students aren't going to only keep their word documents in word for example, they need to email them and upload them to tools like blackboard.

[kodfodrasz]

this is why shared storages are also needed, where apps can have a common view of some set of data.

[benaadams]

You go via the Save/Load dialogs which give access to a file; apps just aren't given non-permission/user-interaction file enumeration by default except for certain directories https://msdn.microsoft.com/en-gb/windows/uwp/files/file-acce...

[flukus]

Sounds like it's not possible to create a custom file manager, or space visualizer or anything like that?

[flukus]

But then all the data people care about will go there. How is that different from /home/user/ ?

[swiley]

In other words: a global filesystem.

[raesene6]

Unless you or someone you trust has audited an application, all apps are untrusted and should be given least privileges (e.g. the mobile/UWP model).

Personally I'd suggest that the trade off is whether the risks of global filesystems are worth it in productivity benefits.

For standard users (non IT-professionals) I think they are not and for IT professionals, in most cases, I think they are.

[kodfodrasz]

I guess you also only then need a firewall, if you use closed source software. When using OpenSource software you can always be sure that nothing will do unauthorized access to your network, willingly or accidentally...

[benaadams]

That's a bit naive... Just two examples

OpenSSL has had 22 vulnerabilities in 2016 so far [1]

Linux has has 336 vulnerabilities in 2016 so far [2]

[1] https://web.nvd.nist.gov/view/vuln/statistics-results?adv_se...

[2] https://web.nvd.nist.gov/view/vuln/statistics-results?adv_se...

[kodfodrasz]

I tried to point to the flaw in the parent comment's logic with a sarcastic answer. :)

[pjmlp]

Average users don't ever know where they are supposed to save their files.

Every time I visit family I get to sort out the files scattered around the hard disk.

[flukus]

Every time I call my mum I have to call my dads mobile first because she can't remember to press the button to hang up. Ther's only so much simplyfying you can do.

Funilly enough, in her 70's now she's taught herself to use a computer and can manage documents in the file system.

[ahoka]

I think it's the same tier as global variables: an anti-pattern.