[WayneBro]

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.

All of the options are listed here - http://stackoverflow.com/questions/12341707/communication-be...

You can also use a loopback exemption, but it requires installing a fake root certificate (no thanks!) - http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/Conf...

or

http://loopback.codeplex.com/

[Someone1234]

> However UWP can't listen for changes in those same files, so it's a real PITA.

It can via the ContentChanged event see this example:

http://stackoverflow.com/questions/39737147/how-can-i-watch-...

> Give it a try. You can't send requests to `localhost` or `127.0.0.1` at all.

Luckily getting the local IP address is easy enough from UWP: http://stackoverflow.com/questions/33770429/how-do-i-find-th...

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.

[pedasmith]

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.

[WayneBro]

> 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!)

[rasz_pl]

How about approaching this from the other end - reengineer windows filtering to allow control of localhost traffic.

[pedasmith]

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" :-)

[rasz_pl]

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.

[WayneBro]

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.

[nitrogen]

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)?

[vmarsy]

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.

[1] https://blogs.windows.com/buildingapps/2017/01/25/calling-wi...

[Kipters]

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.

[rasz_pl]

>http://loopback.codeplex.com/

is there anything like this, but working the other way around? I want to be able to forbid ordinary Win32 programs from accessing loopback/localhost.