Not yet. Their next strategy is to try and use ARM (again) to shove UWP down your throat.
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. You can't even send an HTTP request to a little node.js Web server running on your desktop right now. Fuck that. I'm not buying into it.
> 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.
I don't get the outrage over the rumored UWP only windows. There is no indication that MS would drop win32. This is a separate product, likely for a particular market. It's more of an iPad competitor than a Windows desktop replacement. So don't use it if it offends you, that's OK. I don't think this is all that forceful really.
They already did UWP-only Windows. That was WindowsRT. Nobody bought into that either, but Microsoft still really, really wants that closed-market, walled-garden style business model to happen somehow and so they're going to keep trying.
I believe that their next strategy is to release a full Windows OS (with Win32) that runs on ARM which lets Win32 apps run via an emulator. In this environment, Win32 apps will most likely run like crap and as a matter of course Microsoft is going to keep pushing everybody (developers and users) toward the model that they think will make them the most money.
It's really no problem for my career because I stopped exclusively using Microsoft's tech years ago and I'm comfortable using Linux or a Mac if necessary (but really, I can't stand their UI and I think Apple is even worse than Microsoft in many, many ways). I just like the Windows UI the best and I'd like to be able to build stuff for it in the future....but not if they are working towards taking away my freedom to control my own computer.
Microsoft famously keeps trying, and often the product initially looks like a failure until the third iteration is the one that clicks. (Windows 3.0, Surface 3, Windows NT's third version which was branded "NT 4.0"...)
Windows RT was about as popular as Windows 1.0. I think Microsoft views the upcoming ARM-based "Cloud Windows" (whatever the branding is going to be) as the second iteration of this idea, and hopes to really gain traction a few years later.
Care to elaborate on the HTTP part? You just need the "Internet (client)" capability in your manifest, it's even enabled by default when you create a new project
Moreover, win32 desktop apps can use the AppService mechanism exposed by UWP apps (but cannot host an AppService themselves, just connect to UWP-hosted AppServices)
Give it a try. You can't send requests to `localhost` or `127.0.0.1` at all.
AppService is largely useless for IPC between UWP and Win32 since the UWP app can't initiate a request to the Win32 app.
Another thing you can't do, which is really annoying: UWP won't let your code start an external process and use standard i/o pipes to communicate with it.
The only possibility is to use files for IPC and you'd have to have your Win32 app listen for changes in the file or directory, then open it up and read the data. However UWP can't listen for changes in those same files, so it's a real PITA.
That will work since it is treated like all other network traffic. localhost and 127.0.0.1 are considered privildged routes since you can bypass the firewall and exploit local processes to escalate.
Hey! I didn't implement the loopback restriction in WinRT, but I sure was one of the PMs in the network team when it happened.
As it turns out, pretty much everyone on the thread is right. Localhost is special on a network: it's the only machine that that you're guaranteed actually exists, and is therefore qualified as a high-value target for the bad guys.
I hadn't heard about the printer creating a local HTTP server, but it sure doesn't surprise me one bit.
At the same time, we could identify companies with real products that we wanted in the WinRT ecosystem but where the company already had an architecture that assumed that they could connect to localhost. It was a very painful call, but in the end we decided that security was more important than these companies.
We decided against a checkbox because users already have too many checkboxes, and mostly don't understand any of them.
If knowing the current local IP address gives you access to localhost, that would be a bug. More likely, you see that it works because you're running in a debugger, where the access to localhost is restriction isn't currently enforced.
And for goodness sakes everyone -- stop restricting yourself to IPv4! IPv6 is a real and growing thing! We made a bunch of fixes in Windows just so that the WinRT network APIs would work perfectly without ever knowing or caring whether you were going over IPv4 or IPv6.
> We decided against a checkbox because users already have too many checkboxes, and mostly don't understand any of them.
How did you decide that it was too many? Also, if users don't understand any of them, what's the big deal about one more checkbox?
This was a bad decision IMO and it's the kind of thing that is causing nobody to use UWP. There are so many stories out there of people trying to use UWP for their project and then turning back when they realize how restricted the sandbox is.
Honestly, doesn't it seem a bit absurd that UWP apps can talk to anything else on my network except for Win32 processes on my own computer?
If Windows Phone were a thing, I'd probably be building UWP apps already. Mobile devices are the only place where I accept these types of restrictions, but it's mostly because I have no choice. If Microsoft comes out with a phone that can run Win32 apps, I'd switch to that in a heartbeat because then I could get full Chrome with extensions and I'd be able to do things like run uBlock, quick javascript switcher and all my other favorite extensions. (Yay freedom!)
Because how would an ordinary person every make the right choice? How would any kind of anti-virus every tell the difference between a "good" program that's connecting to an embedded web server in an appropriate way, and a "bad" one that's intended to take over the system?
Most other checkbox security choices at least can be explained. A word processor probably doesn't have any legitimate reason to use Bluetooth (for example), and therefore a customer has a chance of making a reasonable choice.
But for localhost access -- my word, there's no rhyme or reason for it. As a simple example, I worked on a statistical package back in the 90's (yay RS/1!) that was implemented as two programs on Windows. One was the GUI client and the other the statistical server. There's nothing about "statistics" that obviously screams, "must have localhost permissions" :-)
Because you currently ship systems with firewall that is unable to filter outbound traffic per application. DnsCache bypasses filtering by effectively providing tunnel between localhost and external network interface. Maybe you know of a way to selectively limit access to DnsCache per application? effectively whitelist a couple and block the rest?
Ordinary person argument is flawed. So called ordinary person doesnt even know what a network card is.
OK, so ContentChanged is new since the last time I looked - thanks for that! However, IPC via files is still a PITA in general compared to something easy like sockets.
Using an external IP address is a terrible solution for communicating with another process on the same machine. As soon as you disconnect from the network, it will stop working.
What does IPC between UWP and native buy you? Do you have some legacy code that has to run natively (been there with a Java app many years ago using TCP to talk to a tiny host process for some native code)?
No the author, but I can see a use case where you have already existing "services"/"daemons" with your client Win32 app. If you want to rewrite the client from Win32 to UWP, it seems that you wouldn't be able to?
Why do that? Indeed one could just call Windows 10 API from its existing client [1], but it seems that you would miss out on the easy install/update from the Store and other benefits a UWP app provides.
Wow, it's weird I never actually tried to send a request to localhost on UWP, usually only to other PCs on the network during development. I didn't know that.
The Win32 app can connect to the UWP AppService, on PC you can also bundle a desktop app in your package and start it when the UWP app is launched. This desktop app can then act as a bridge between your UWP app and the "legacy" world, offloading the "dirty" stuff to the slave desktop app. It actually works, I used this for getting the taskbar to blink in my side-project for a messaging app.
I think he was talking about programming the apps, not just using them. From the looks of it (after reading the comments here and nothing more, so excuse me if I'm completely wrong) it may be a real inconvenience from the dev perspective: I can somehow understand the "no 127.0.0.1 communication" policy, but I expect to communicate with a spawned process via stdin/stdout pipes.
Old style IPC leads to information leaks and is another attack vector.
You cannot do that on Android for example, Google explicitly removed UNIX V IPC from their Linux fork. You are expected to use TCP/IP or Android RPCs, assuming the app has android.permission.INTERNET permission.
> You have the same issue in other sandbox models.
Would what PC-BSD does with jails qualify as an exception?
> So people are complaining about Microsoft adopting what is already best practices on the other desktop/mobile sandbox models.
Now I'm curious - weren't people complaining when the other sandbox systems were designed/created? It really looks a bit inconvenient (I'm referring to the SO explanation of what Android Chrome does), so I'd expect some reasonable opposition. It could be that with time people got used to the restrictions and don't complain that often anymore.
To be honest, I like PC-BSD model, but that's probably not a good idea for platforms where the resources are constrained. It works ok on the desktop, though - I didn't work with PC-BSD itself for long, but I did the same with Docker on Linux (for web browsers) and the performance hit wasn't that bad IIRC.
As for the other sandbox models, the only people I have seen complaining thus far, has been in sites like HN, I never heard any of our customers complaining about those restrictions, or caring about them.
IIRC iOS lets you connect to other apps on 127.0.0.1 just fine. But it won't work in the obvious use case of a foreground client and a background server without additional hacks, because the server can be suspended and the connection attempt alone won't wake it up.
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. You can't even send an HTTP request to a little node.js Web server running on your desktop right now. Fuck that. I'm not buying into it.