> I love Windows but I seriously will not touch UWP until they loosen up the sandbox restrictions so that I can do regular IPC with a win32 desktop app.
The whole reason for the UWP sandboxing is to make it so that users can confidently install UWP applications with some assurances that it isn't spyware/malware/blackmailware that will take over their PC or steal their personal information.
UWP is Microsoft's answer to years of criticism they received for the way process permissions work on Windows. They aren't going to just dump it all because you and a few others find the priviledge model inconvenient.
> You can't even send an HTTP request to a little node.js Web server running on your desktop right now.
If your node.js web server was network accessible you could. But, no, it won't allow unchecked IPC as that directly defeats the whole point of sandboxing to begin with.
Personally I haven't used UWP much either, but that has nothing to do with sandboxing and everything to do with poor performance and UI issues (e.g. window controls, built in UI elements, etc). I still find the Windows 10 UWP Calculator horrible to use, it was a MASSIVE downgrade over the old one.
Honestly, this particular complaint reminds me a lot of UAC. After decades of people complaining that Windows account security was too lax, they implement the graphical popup equivalent of `sudo`. Then proceed to get skewered in public opinion for having done it.
Yes, proper security means you will be inconvenienced. In the same way that you would be inconvenienced if your bank called you to confirm that $10000 wire you didn't initiate. It's inconvenient that you have to take a call and resolve the issue, but it's a hell of a lot better than finding out at some indeterminate point in the future that $10000 is missing from your account.
If only. sudo, as configured out-of-the-box on Ubuntu, gets out of your way and lets you work (Except if you haven't properly authenticated in the last 15 minutes); polkit is similarly out-of-your-way.
Sudo is also (relatively) easy to configure: "this command line can be run under sudo by anybody", "this command must not be run under sudo even if they know their password", etc.
UAC is always-in-your-face about everything, often unexpectedly - it hijacks your desktops at inopportune times, and there's no way to tell it "Yes, this software can do this again for the next 15 minutes without asking me again".
UAC is very, very far from being the graphical popup equivalent of sudo. If it had been, people would not have complained as much. (Someone always complains. But in the case of UAC, most of the complaints are justified)
Not true: UAC only pops up for apps that need to access a file/registry key, etc. that affects system-wide behavior
"... often unexpectedly - it hijacks your desktops at inopportune times ..."
This isn't true: UAC pops up precisely when an app is launched that needs to access/modify a system-wide resource. If you're running apps that OFTEN need to access system-wide resources, you could choose to run them as admin and avoid the UAC pop-ups ... while also hoping that those apps are not malicious or over-enthusiastic about "helping".
"and there's no way to tell it "Yes, this software can do this again for the next 15 minutes without asking me again"."
There kinda is - just run the app as Admin. It'll then run with admin rights until you close it.
Of course, without specific examples of what you see as erroneous behavior, I've posted what are, I am sure, inadequate responses to your specific issues. If you'd like to share you specifc issues, I am sure we could have a more fruitful dialog and who knows, I may be able to carry your case internally to see if we can improve things in future OS releases (no guarantees here other than my trying my best).
While what you say was true about Vista, in Windows 7, 8, 8.1, and 10 UAC prompts are suppressed when they're the direct result of user interactions within the OS itself. Each OS reduced the number of UAC prompts a user experiences.
They also broke the security on the default configuration because now you can just interact with the system components to bypass UAC, see e.g. [0]. This is officially not a security vulnerability because UAC isn't actually a security barrier unless you set it to "Always prompt", but just a feature to make applications play nice. But note that it's not on "Always prompt" by default...
To be fair, MS didn't really communicate clearly to their downstream vendors that the OS was getting "locked down" and they didn't wait long enough for the driver manufacturers to catch up to the new standards.
That said, it was ironic that people complained about security in a Windows release.
We can improve security by turning the computer off but you have to balance security and utility. At the moment UWP is way to far towards security.
Until you can run power tools (compilers, IDE's, web servers, system tweakers) as UWP apps it will be inferior to win32.
This is why no one is investing in UWP apps, you don't want to spend months/years developing something only to find out that the app is crippled because of a limitation you weren't aware of.
> Seems a little silly that my UWP app can access everything on my network except for my own darn computer via localhost, doesn't it?
Unfortunately for historical reasons localhost (127.0.0.1) are treated almost like a named pipe. Meaning a LOT of Win32 (and UNIX-style) applications treat data over that path as "trusted."
For one specific example, I've used a HP driver that installs a local webserver for no good reason, and if you can send a specially crafted request it will execute that request in the SYSTEM context. All you need is localhost access and knowledge to pull it off (this is not exploitable remotely).
A lot of software has been designed with the assumption that localhost is trusted and they have therefore used it for IPC. This is exactly what you're attempting to do too. But let me ask you this, what happens if a third party UWP application tries to use your localhost backdoor? Does it allow UWP malware? How are you going to verify that only YOUR UWP application connects to your Node.js instance?
File IPC allows you to limit it to just your UWP application because presumably the file will be within that UWP application's unique storage block. It might be a pain but at least the ultimate result is secure.
One of the programs that does this is dnscache. It wouldnt be all that bad if localhost wasnt the actual named pipe instead of virtual network interface :( - you cant filter localhost traffic with a firewall in windows. This means everything with localhost access can speak to the internet (dns pipe) bypassing any firewall rules you might set.
The whole reason for the UWP sandboxing is to make it so that users can confidently install UWP applications with some assurances that it isn't spyware/malware/blackmailware that will take over their PC or steal their personal information.
UWP is Microsoft's answer to years of criticism they received for the way process permissions work on Windows. They aren't going to just dump it all because you and a few others find the priviledge model inconvenient.
> You can't even send an HTTP request to a little node.js Web server running on your desktop right now.
If your node.js web server was network accessible you could. But, no, it won't allow unchecked IPC as that directly defeats the whole point of sandboxing to begin with.
Personally I haven't used UWP much either, but that has nothing to do with sandboxing and everything to do with poor performance and UI issues (e.g. window controls, built in UI elements, etc). I still find the Windows 10 UWP Calculator horrible to use, it was a MASSIVE downgrade over the old one.