The Windows Push Notification Service was designed as a successor to the Microsoft Push Notification Service, which was only supported natively on the Windows Phone 8 Operating System. Developers can still use the MPNS on apps that are installed on newer versions of Windows Mobile, but only if the Windows application was already registered to use the MPNS and has been converted to a Microsoft Silverlight application and modified to re-target the new platform. In 2015, Microsoft announced that the WNS would be expanded to utilize the Universal Windows Platform architecture, allowing for push data to be sent to Windows 10, Windows 10 Mobile, Xbox, as well as other supported platforms using universal API calls and POST requests. During the 2015 Build keynote, Microsoft announced a Universal Windows Platform bridge that would allow Android and iOS software to be ported to Windows 10 Mobile and published to the Windows Store. In August 2015, A version of the Microsoft Android bridge toolset was reported to be leaked and available on the internet along with its documentation. The leaked toolset required developers to register and use the WNS to send notification data to ported applications, and would not allow for Google Cloud Messaging to be used instead. Microsoft later discontinued the Android bridge project in favor of continuing support for iOS application porting instead. During the 2016 Build keynote, Microsoft announced an update to the WNS and the Windows 10 Operating System that will allow for Android and iOS devices to forward push notifications received to Windows 10 to be viewed and discarded.
Architecture
The architecture of the Windows Push Notification Service is similar to that of its predecessor, in that it consists of servers and interfaces that generate, maintain, store, and authenticate unique identifiers for all devices that register to use the service. When a device enrolls to receive data and notification information using the WNS, it first sends a device registration request to the WNS network. The WNS network acknowledges the request, and responds with the device's uniqueChannel URI Identifier. Typically, the device will then send its identifier to a server owned by the developer so that it can be stored and used for sending notifications. When the app developer wishes to transmit a notification or other WNS data to the device, it will transmit a POST request to the WNS network. The network will acknowledge and authenticate the request. If the authentication succeeds, the data to be transmitted is enqueued and then sent to the device from the WNS network using the Channel URI Identifier.
Privacy Issue
With Windows 10, while connected to a VPN that disallows Split Tunneling, the WpnUserService_ process bypasses the tunnel, connecting directly to Microsoft. This behavior will reveal the real IP address of the host. This can be observed with the Windows Resource Monitor.
