Wns windows com что это

From Wikipedia, the free encyclopedia

Windows Push Notification Service

Windows Push Notification Service (commonly referred to as Windows Notification Service or WNS) is a notification service developed by Microsoft for all devices running Microsoft Windows platforms. It allows for developers to send push data («toast» and «tile» updates) to Windows and Universal Windows Platform applications which implement the feature.^[1] Designed as a successor to the Microsoft Push Notification Service, it was first supported on Windows 8 and subsequently on Windows Phone 8.1 upon its release.^[2]

The Windows Push Notification Service (WNS) was designed as a successor to the Microsoft Push Notification Service (MPNS), 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 (Windows Phone 8 or Windows Phone 8.1), 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.^[3]

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.^[4]

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.^[5] 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.^[6] 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.^[7]

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.^[8]

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 (called Channel URI Identifiers) for all devices that register to use the service.^[2] 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 unique Channel URI Identifier.^[9] 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.^[1] 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.^[10] 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.^{[citation needed]}

• Official website

Время на прочтение7 мин

Количество просмотров17K

Картинка с сайта: habr.com

Недавно я вернулся к мысли о возможности совершения битсквоттинга. В статье по ссылке эта тема рассматривается очень глубоко, поэтому здесь я объясню в очень общих чертах:

Когда вы пытаетесь получить доступ к сайту по его домену, этот домен хранится в памяти вашего компьютера, устройства и т.д. в структуре, выглядящей примерно так:

Теперь представим, что компьютер перегрелся, произошла вспышка на Солнце или космический луч (вполне реальная штука) инвертировал в компьютере значение одного бита.

О нет! Теперь в памяти хранится значение whndows.com, а не windows.com! Что же произойдёт, когда придёт время создания подключения к этому домену?

nslookup whndows.com

*** can’t find whndows.com: Non-existent domain

Домен не резолвится в IP-адрес!
Оказалось, что из 32 возможных доменных имён, находящихся в одной замене бита от windows.com, 14 имён были доступны для покупки! Это довольно редкий случай — обычно такие имена покупаются компаниями, например, Microsoft, чтобы предотвратить их использование в целях фишинга. Итак, я их купил. Все. Примерно за 126 долларов.

(Если вы являетесь верифицируемо ответственным лицом, то я с радостью передам вам владение этими доменами. В противном случае я придержу их и продолжу сливать деньги.)

windnws.com
windo7s.com
windkws.com
windmws.com
winlows.com
windgws.com
wildows.com
wintows.com
wijdows.com
wiodows.com
wifdows.com
whndows.com
wkndows.com
wmndows.com

Теперь нам нужно, чтобы эти домены на что-то указывали. Я арендовал VPS, сконфигурировал IPv4/IPv6 и создал подстановочные DNS-записи, чтобы указывать на них.

Подстановочные DNS работают следующим образом: я создаю запись, сообщающую, что whndows.com указывает на 123.123.123.123, и когда кто-нибудь запрашивает abs.xyz.whndows.com, он получит в качестве ответа ту же DNS-запись 123.123.123.123. Поскольку в этом исследовании мы имеем дело с инвертированием битов, это позволяет мне перехватывать любые DNS lookup поддомена windows.com, в которых инвертировано несколько битов.

Настроив DNS, мы используем tshark для выполнения перехвата пакетов через публичный интерфейс нашего VPS и подождём, пока не произойдёт что-нибудь интересное.

Ниже приведена краткая выжимка интересных вещей, которой можно поделиться без возможности идентификации пользователей.

Чтобы отличить оппортунистическое сканирование от ситуации инвертирования битов, я использовал GreyNoise.io. Это отличный продукт!

NTP UDP port 123 time.windows.com

UDP-пакеты, предназначенные для порта 123, пытаются задать время на часах компьютера с помощью Network Time Protocol (NTP).

time.windows.com — это стандартный NTP-сервер, настроенный для всех машин под Windows и они регулярно сверяют по нему время. Если им не удаётся получить время, то они пробуют снова, и снова, и снова.

В сумме, на протяжении 14 дней мой сервер получил 199 180 подключений NTP-клиентов с 626 уникальных IP-адресов.

NTP-клиент для ОС Windows не имеет внутренней верификации аутентичности, поэтому злоумышленнику ничего не стоит сообщить всем этим компьютерам, что сейчас время после 03:14:07 вторника 19 января 2038 года и посеять хаос, поскольку ячейка памяти, хранящая время в формате 32-битного числа со знаком, переполняется.

Однако, как оказалось, примерно у 30% этих компьютеров подобные действия ничего не изменят для их пользователей, потому что их часы уже и так сломаны.

С помощью фильтра tshark ntp.xmt мы можем извлечь Transmit Timestamp, то есть текущее по мнению компьютера время на момент обновления времени.

tshark -r capture.pcap -T fields -e ntp.xmt -2 -R ntp.xmt | sort -u

Sep 28, 1984 19:41:12.638290998 EDT
Sep 28, 2012 11:59:42.976403314 EDT
Sep 28, 2029 21:50:47.552079831 EDT
Sep 28, 2100 18:13:09.180229791 EST
Sep 29, 1975 08:36:52.200231052 EDT
Sep 29, 1980 23:44:14.142299217 EDT
Sep 29, 2036 11:54:11.410350275 EDT
Sep 29, 2038 06:18:34.082394858 EDT
Sep 29, 2046 16:00:00.102963544 EST
Sep 29, 2050 06:39:18.880921186 EST
Sep 29, 2074 07:31:58.701524704 EST
Sep 30, 1999 00:29:32.120677896 EDT
Sep 30, 2009 02:54:33.318870579 EDT
Sep 30, 2049 00:14:59.396552253 EST
Sep 30, 2075 13:56:14.492526678 EST
Sep 30, 2081 01:56:58.477295064 EST

HTTP TCP port 80 sg2p.w.s.windows.com

Для настоящего домена sg2p.w.s.windows.com отсутствуют активные DNS-записи.

Однако, судя по User-Agent и времени запросов, можно понять, что эта активность напрямую связана с тем же приложением, которое сгенерировало показанный ниже трафик для client.wns.windows.com и skydrive.wns.windows.com

GET / HTTP/1.1
Host: sg2p.w.s.windo7s.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 client.wns.windows.com

Похоже, они напрямую связаны с сервисами Windows Push Notification Services (WNS), позволяющими сторонним разработчикам отправлять toast-, tile-, badge- и raw-обновления с собственного облачного сервиса. DNS-запись — это CNAME для wns.notify.trafficmanager.net.

DNS-записи:

client.wns.windows.com.        IN    CNAME   wns.notify.trafficmanager.net.
wns.notify.trafficmanager.net. IN    A       52.177.166.224

HTTP-запрос:

GET / HTTP/1.1
Host: client.wns.wkndows.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 skydrive.wns.windows.com

Словом Skydrive до смены имени назывался OneDrive.

DNS-записи:

skydrive.wns.windows.com.      IN      CNAME   client.wns.windows.com.
client.wns.windows.com.        IN      CNAME   wns.notify.trafficmanager.net.
wns.notify.trafficmanager.net. IN      A       52.179.224.121

HTTP-запрос:

GET / HTTP/1.1
Host: skydrive.wns.windo7s.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 time.windows.com

Понятия не имею, откуда пришёл этот запрос и почему HTTP запрашивается с сервера, который должен быть NTP-сервером. WHOIS по IP, сделавшему этот запрос, показан ниже:

inetnum:        123.112.0.0 - 123.127.255.255
netname:        UNICOM-BJ
descr:          China Unicom Beijing province network
descr:          China Unicom
country:        CN
admin-c:        CH1302-AP
tech-c:         SY21-AP
mnt-by:         APNIC-HM
mnt-lower:      MAINT-CNCGROUP-BJ
mnt-routes:     MAINT-CNCGROUP-RR
mnt-irt:        IRT-CU-CN

GET / HTTP/1.1
Host: time.wiodows.com
Connection: close
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Accept-Encoding: gzip
Accept-Language: zh-cn,zh-tw
Accept: */*

Вскоре после этого запроса произошла ещё более странная ситуация! Baidu — это один из крупнейших китайских поисковых движков. Не забывайте, что я сконфигурировал свои DNS-сервера для резолвинга в режиме подстановки. Существует очень малое количество способов, которыми Baiduspider мог бы узнать о существовании time.wiodows.com. Особенно учитывая, что ранее к этому домену был выполнен только один запрос (показанный выше).

GET / HTTP/1.1
Host: time.wiodows.com
Connection: close
User-Agent: Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)
Accept-Encoding: gzip
Accept-Language: zh-cn,zh-tw
Accept: */*

HTTP tcp port 80 windows.com/stopcode

При возникновении синего экрана смерти в Windows пользователю предлагается посетить https://www.windows.com/stopcode. Естественно, если компьютер завис, он не может просто открыть ссылку. Большинство людей, скорее всего, просто отсканировали бы QR-код, но те, кто ввёл адрес с опечаткой, оказались здесь.

Картинка с сайта: habr.com

GET /stopcode HTTP/1.1
Host: wildows.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 5.0.1; ALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.111 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

Особенно любопытен следующий запрос. Из-за характера запроса я укажу некоторые подробности обобщённо или полностью отцензурирую, потому что не совсем понятно, что происходит.

IP из диапазона 113.96.0.0 — 113.111.255.255 (CHINANET-GD) делает запрос с телефона под Android.

GET /topode HTTP/1.1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 7.1.2; M6 Note Build/N2G47H; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/77.0.3865.120 MQQBrowser/6.2 TBS/045223 Mobile Safari/537.36 MMWEBID/9551 MicroMessenger/7.0.14.1660(0x27000E37) Process/tools NetType/4G Language/zh_CN ABI/arm64 WeChat/arm64 wechatdevtools
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US
Host: wintows.com
Via: 1.1 TENCENT64.site (squid/3.5.20)
X-Forwarded-For: <Department of Defence IP>
Cache-Control: max-age=259200
Connection: keep-alive

Похоже, какой-то пользователь из Китая использует squid для инъецирования HTTP-заголовков в каждый запрос, исходящий из его сети, в том числе и со своего мобильного телефона. На его компьютере возникает синий экран смерти, поэтому пользователь пытается поискать код STOP-ошибки на windows.com/stopcode с телефона. Он вводит URL с ошибкой и оказывается на моём сервере, где я вижу, что он инъецирует HTTP-заголовок для X-Forwarded-For, пытающийся представить запрос так, как будто он отправлен с IP, принадлежащего Министерству обороны США.

Когда я поискал исходный IP на GreyNoise, то узнал следующее: «Этот IP-адрес оппортунистически сканировал Интернет и совершил полное TCP-соединение. Спуфинг зафиксированной активности невозможен. GreyNoise определил, что этот IP-адрес сканирует Интернет через следующие порты: 443 / TCP».

Наблюдая за тем, что мой трафик получается по 80 / TCP, могу предположить, что это не предусматривалось.

HTTP TCP port 80 windows.com/?fbclid

Как и можно было ожидать, кто-то в Facebook обязательно должен был опечататься в адресе windows.com, из-за чего создалась ссылка с уникальным токеном ?fbclid=xyz. Краулер Facebook пытается запросить адрес, то же самое делает и Bing, если он на другом языке, после чего пытается перевести его.

GET /?fbclid=IwAR28VIBcDUlzO4XQOk9R-EWYLsnjUf-SrrKKZyAdOvrV2Mtv5JoJVO3PSUQ HTTP/1.1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534+ (KHTML, like Gecko) BingPreview/1.0b
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Host: wintows.com
Connection: keep-alive

Подведём итог

Нас не должно удивлять, что сервис NTP, работающий на всех машинах c Windows в мире, использующий в стандартной конфигурации time.windows.com, генерировал больше всего трафика, вызванного инвертированием битов. Я по-прежнему получаю кучу трафика. Больше всего меня удивило то, сколько трафика я получал от доменов, ошибочно указанных пользователями при вводе URL.

Выводы:

• Битсквоттинг домена с большими объёмами трафика — по-прежнему очень практичная в реализации атака.
• Интегрированные в ОС автоматизированные сервисы создают много битсквоттингового трафика.
• Пользователи по-прежнему часто делают опечатки в именах доменов.

На правах рекламы

VDSina предлагает VDS с посуточной оплатой. Возможно установить любую операционную систему, в том числе из своего образа. Каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!

Картинка с сайта: habr.com

On May 15, 2025
Last updated

Windows Push Notification Services (WNS) overview

The Windows Push Notification Services (WNS) enable third-party developers to send toast, tile, badge, and raw updates from their own cloud service. This provides a mechanism to deliver new updates to your users in a power-efficient and dependable way.

How it works

The following diagram shows the complete data flow for sending a push notification. It involves these steps:

1. Your app requests a push notification channel from WNS.
2. Windows asks WNS to create a notification channel. This channel is returned to the calling device in the form of a Uniform Resource Identifier (URI).
3. The notification channel URI is returned by WNS to your app.
4. Your app sends the URI to your own cloud service. You then store the URI on your own cloud service so that you can access the URI when you send notifications. The URI is an interface between your own app and your own service; it’s your responsibility to implement this interface with safe and secure web standards.
5. When your cloud service has an update to send, it notifies WNS using the channel URI. This is done by issuing an HTTP POST request, including the notification payload, over Secure Sockets Layer (SSL). This step requires authentication.
6. WNS receives the request and routes the notification to the appropriate device.

Картинка с сайта: elcebador.ru

Registering your app and receiving the credentials for your cloud service

Before you can send notifications using WNS, your app must be registered with the Store Dashboard, as described here.

Requesting a notification channel

When an app that is capable of receiving push notifications runs, it must first request a notification channel through the CreatePushNotificationChannelForApplicationAsync. For a full discussion and example code, see How to request, create, and save a notification channel. This API returns a channel URI that is uniquely linked to the calling application and its tile, and through which all notification types can be sent.

After the app has successfully created a channel URI, it sends it to its cloud service, together with any app-specific metadata that should be associated with this URI.

Important notes

• We do not guarantee that the notification channel URI for an app will always remain the same. We advise that the app requests a new channel every time it runs and updates its service when the URI changes. The developer should never modify the channel URI and should consider it as a black-box string. At this time, channel URIs expire after 30 days. If your WindowsВ 10 app will periodically renew its channel in the background then you can download the Push and periodic notifications sample for WindowsВ 8.1 and re-use its source code and/or the pattern it demonstrates.
• The interface between the cloud service and the client app is implemented by you, the developer. We recommend that the app go through an authentication process with its own service and transmit data over a secure protocol such as HTTPS.
• It is important that the cloud service always ensures that the channel URI uses the domain «notify.windows.com». The service should never push notifications to a channel on any other domain. If the callback for your app is ever compromised, a malicious attacker could submit a channel URI to spoof WNS. Without inspecting the domain, your cloud service could potentially disclose information to this attacker unknowingly.
• If your cloud service attempts to deliver a notification to an expired channel, WNS will return response code 410. In response to that code, your service should no longer attempt to send notifications to that URI.

Authenticating your cloud service

To send a notification, the cloud service must be authenticated through WNS. The first step in this process occurs when you register your app with the Microsoft Store Dashboard. During the registration process, your app is given a Package security identifier (SID) and a secret key. This information is used by your cloud service to authenticate with WNS.

The WNS authentication scheme is implemented using the client credentials profile from the OAuth 2.0 protocol. The cloud service authenticates with WNS by providing its credentials (Package SID and secret key). In return, it receives an access token. This access token allows a cloud service to send a notification. The token is required with every notification request sent to the WNS.

At a high level, the information chain is as follows:

1. The cloud service sends its credentials to WNS over HTTPS following the OAuth 2.0 protocol. This authenticates the service with WNS.
2. WNS returns an access token if the authentication was successful. This access token is used in all subsequent notification requests until it expires.

Картинка с сайта: elcebador.ru

In the authentication with WNS, the cloud service submits an HTTP request over Secure Sockets Layer (SSL). The parameters are supplied in the «application/x-www-for-urlencoded» format. Supply your Package SID in the «client_id» field and your secret key in the «client_secret» field as shown in the following example. For syntax details, see the access token request reference.

This is just an example, not cut-and-paste code that you can successfully use in your own code.В

The WNS authenticates the cloud service and, if successful, sends a response of «200 OK». The access token is returned in the parameters included in the body of the HTTP response, using the «application/json» media type. After your service has received the access token, you are ready to send notifications.

The following example shows a successful authentication response, including the access token. For syntax details, see Push notification service request and response headers.

Important notes

• The OAuth 2.0 protocol supported in this procedure follows draft version V16.
• The OAuth Request for Comments (RFC) uses the term «client» to refer to the cloud service.
• There might be changes to this procedure when the OAuth draft is finalized.
• The access token can be reused for multiple notification requests. This allows the cloud service to authenticate just once to send many notifications. However, when the access token expires, the cloud service must authenticate again to receive a new access token.

Sending a notification

Using the channel URI, the cloud service can send a notification whenever it has an update for the user.

The access token described above can be reused for multiple notification requests; the cloud server is not required to request a new access token for every notification. If the access token has expired, the notification request will return an error. We recommended that you do not try to re-send your notification more than once if the access token is rejected. If you encounter this error, you will need to request a new access token and resend the notification. For the exact error code, see Push notification response codes.

The cloud service makes an HTTP POST to the channel URI. This request must be made over SSL and contains the necessary headers and the notification payload. The authorization header must include the acquired access token for authorization.

An example request is shown here. For syntax details, see Push notification response codes.

For details on composing the notification payload, see Quickstart: Sending a push notification. The payload of a tile, toast, or badge push notification is supplied as XML content that adheres to their respective defined Adaptive tiles schema or Legacy tiles schema. The payload of a raw notification does not have a specified structure. It is strictly app-defined.

WNS responds to indicate that the notification has been received and will be delivered at the next available opportunity. However, WNS does not provide end-to-end confirmation that your notification has been received by the device or application.

This diagram illustrates the data flow:

Картинка с сайта: elcebador.ru

Important notes

• WNS does not guarantee the reliability or latency of a notification.
• Notifications should never include confidential or sensitive data.
• To send a notification, the cloud service must first authenticate with WNS and receive an access token.
• An access token only allows a cloud service to send notifications to the single app for which the token was created. One access token cannot be used to send notifications across multiple apps. Therefore, if your cloud service supports multiple apps, it must provide the correct access token for the app when pushing a notification to each channel URI.
• When the device is offline, by default WNS will store up to five tile notifications (if queuing is enabled; otherwise, one tile notification) and one badge notification for each channel URI, and no raw notifications. This default caching behavior can be changed through the X-WNS-Cache-Policy header. Note that toast notifications are never stored when the device is offline.
• In scenarios where the notification content is personalized to the user, WNS recommends that the cloud service immediately send those updates when those are received. Examples of this scenario include social media feed updates, instant communication invitations, new message notifications, or alerts. As an alternative, you can have scenarios in which the same generic update is frequently delivered to a large subset of your users; for example, weather, stock, and news updates. WNS guidelines specify that the frequency of these updates should be at most one every 30 minutes. The end user or WNS may determine more frequent routine updates to be abusive.
• Windows Notification Platform maintains a periodic data connection with WNS to keep the socket alive and healthy. If there are no applications requesting or using notification channels then the socket will not be created.

Expiration of tile and badge notifications

By default, tile and badge notifications expire three days after being downloaded. When a notification expires, the content is removed from the tile or queue and is no longer shown to the user. It’s a best practice to set an expiration (using a time that makes sense for your app) on all tile and badge notifications so that your tile’s content doesn’t persist longer than it is relevant. An explicit expiration time is essential for content with a defined lifespan. This also assures the removal of stale content if your cloud service stops sending notifications, or if the user disconnects from the network for an extended period.

Your cloud service can set an expiration for each notification by setting the X-WNS-TTL HTTP header to specify the time (in seconds) that your notification will remain valid after it is sent. For more information, see Push notification service request and response headers.

For example, during a stock market’s active trading day, you can set the expiration for a stock price update to twice that of your sending interval (such as one hour after receipt if you are sending notifications every half-hour). As another example, a news app might determine that one day is an appropriate expiration time for a daily news tile update.

Push notifications and battery saver

Battery saver extends battery life by limiting background activity on the device. WindowsВ 10 lets the user set battery saver to turn on automatically when the battery drops below a specified threshold. When battery saver is on, the receipt of push notifications is disabled to save energy. But there are a couple exceptions to this. The following WindowsВ 10 battery saver settings (found in the Settings app) allow your app to receive push notifications even when battery saver is on.

• Allow push notifications from any app while in battery saver: This setting lets all apps receive push notifications while battery saver is on. Note that this setting applies only to WindowsВ 10 for desktop editions (Home, Pro, Enterprise, and Education).
• Always allowed: This setting lets specific apps run in the background while battery saver is on — including receiving push notifications. This list is maintained manually by the user.

There is no way to check the state of these two settings, but you can check the state of battery saver. In WindowsВ 10, use the EnergySaverStatus property to check battery saver state. Your app can also use the EnergySaverStatusChanged event to listen for changes to battery saver.

If your app depends heavily on push notifications, we recommend notifying users that they may not receive notifications while battery saver is on and to make it easy for them to adjust battery saver settings. Using the battery saver settings URI scheme in WindowsВ 10, ms-settings:batterysaver-settings , you can provide a convenient link to the Settings app.

When notifying the user about battery saver settings, we recommend providing a way to suppress the message in the future. For example, the dontAskMeAgainBox checkbox in the following example persists the user’s preference in LocalSettings.

Here’s an example of how to check whether battery saver is turned on in WindowsВ 10. This example notifies the user and launches the Settings app to battery saver settings. The dontAskAgainSetting lets the user suppress the message if they don’t want to be notified again.

This is the XAML for the ContentDialog featured in this example.

Куда и для чего передает данные Windows 10? Конечные точки подключения системы

В 2015 году мы опубликовали статью Конфиденциальность в Windows 10, чтобы подчеркнуть основные проблемы конфиденциальности системы, в частности невозможность отключить сбор телеметрических данных через пользовательский интерфейс.

Из-за проблем с конфиденциальностью Windows 10 Microsoft подверглась жесткой критике со стороны государственных учреждений в различных странах, в частности во Франции и в Нидерландах. С выходом Windows 10 сразу стало появляться множество инструментов защиты приватности, например O&O ShutUp10 и Blackbird, которые обещают ограничить Microsoft доступ к персональным данным.

У пользователей и системных администраторов Windows всегда остается возможность заблокировать конечные точки, чтобы соединения для передачи данных даже не устанавливались. Данный метод требует расширенного тестирования, потому что при блокировке соединения может нарушиться критически важная функциональность.

Если вы блокируете конечные точки службы обновления Windows, тогда не удивляйтесь, что система перестанет автоматически обновляться.

Стандартные системы Windows 10 выполняют огромное число подключения в автоматическом режиме для различных нужд. Windows 10 постоянно проверяет обновления, проверяет файлы в рамках сканирований Защитника Windows или передает телеметрические данные на сервера Microsoft.

В то время, как некоторые подключения требуются для нормальной работы системы, другие соединения можно спокойно отключить без существенного влияния на функциональность. Особенно это актуально, если какая-либо функция не используется в системе.

Microsoft опубликовала контрольный список конечных точек подключения Windows 10. Список конечных точек для потребительских версий доступен для Windows 10 версий 1709 и 1803, а список для Windows 10 Корпоративная доступен для версии 1709.

Конечные точки подключения для выпусков Windows 10 версии 1803

Ниже приведен список конечных точек подключения Windows 10 версии 1803 для выпусков, отличных от Windows 10 Корпоративная: