Telemetria w Windows 10 dwa lata później - czy wiemy coś nowego?

Minęły ponad dwa lata od opublikowania mojego artykułu na temat telemetrii w systemie Windows 10. Znajduje się on do tej pory w czołówce moich najpopularniejszych wpisów blogowych, mimo, że nie planowałem zajmować się tym tematem szerzej. Z tegoż powodu w tekście brakuje na przykład szczegółowych opisów dotyczących wyłączania usług i usuwania komponentów. Pojawiły się też wątpliwości dotyczące wiarygodności samego pomiaru, ale tu akurat jestem zdania, że niepomyślność wyniku ("wniosek: wszystko śledzi") wskazuje poszlakowo na wystarczającą dokładność wykorzystanych narzędzi. Nie jest to jedyny argument za, ale o tym później.

Wprowadzenie

Tematyka telemetrii w międzyczasie przycichła, świat nie zbojkotował Windows 10, a samo zagadnienie stało się medialnie niemodne, skutkiem czego niemal zupełnie już zniknęło. Wynika to nie tyle z przyjęcia (rzeczowego) argumentu, że skala telemetrii siłą rzeczy nie może być olbrzymia, a raczej z fraktalnie wadliwej postawy "nie mam nic do ukrycia", opartej na szeregu fundamentalnych błędów logicznych.

Dla mnie z kolei istnienie telemetrii jest oczywistością: używany przeze mnie system Windows Server już od dekady ma domyślnie uruchomione członkostwo w CEIP i WER, ausługa DiagTrack nie była dla mnie nowością z Windows 10, a dobrze znaną zabawką. Rzeczą, która jest mi jednak obca zupełnie, jest ruch generowany przez Windows w tzw. "userlandzie": nałożona na wierzch powłoki systemowej warstwa kafelkowa to nie tylko mało gustowne, kolorowe prostokąty, a całe API i środowisko uruchomieniowe, działające pod spodem. Jest to środowisko zaskakująco rozbudowane i solidne, jak na miernotę kafelkowych aplikacji. To właśnie ono jest odpowiedzialne za generowanie największej ilości ruchu w komunikacji z chmurą Microsoftu. Trąci od niego metodyką działania smartfonów i należy się go obawiać o wiele bardziej, niż samej telemetrii.

Dwa lata temu wspomniałem, że nowe mechanizmy są kiepsko udokumentowane, ukryte i bronią się przed wyłączeniem. Dziś wiem nieco więcej, mimo, że poziom dokumentacji nie wzrósł ani trochę. Chcę wrócić do badania ruchu generowanego przez Dziesiątkę. O ile poprzednim razem chodziło mi o sprawdzenie, ile go jest i dokąd idzie, teraz chcę się zająć przybliżeniem zasady działania kolejnych "warstw" dodanych do Windows 10 i wyjaśnić dlaczego w ogóle występuje ich komunikacja ze światem zewnętrznym. Wątpię, że uda mi się zaprezentować godną zaufania i niezawodną metodę zablokowania ww. ruchu, ale jednocześnie mam bardzo duże opory przed odsyłaniem do gotowców, które bardzo często są inwazyjne, a zarazem nieskuteczne (nieaktualne?).

Warstwa aplikacji

Zacznijmy więc od samej góry. Od tego, co może się wydarzyć wskutek naszych własnych działań, a nie poprzez zautomatyzowane wyzwalacze tajemniczych środowisk uruchomieniowych. A na samej górze leżą aplikacje UWP. Są one szalenie mało popularne, bowiem zdecydowana większość użytkowników korzysta z alternatyw, ale niektóre aplikacje są jednak używane dość powszechnie - należy do nich na przykład aplikacja Zdjęcia. Po co aplikacja Zdjęcia (Microsoft.Windows.Photos_8wekyb3d8bbwe) ma się łączyć z internetem? Powodem jest OneDrive. Zdjęcia aktualizują bazę danych dla "zalążków" (stubs) zdjęć, niepobranych jeszcze z OneDrive, by móc wyświetlać widok galerii. Ponadto, aktualizują pamięć metadanych w chmurze, by automatycznie katalogować zdjęcia wg. różnorakich kategorii. Kiedyś takie cudo odbywało się wyłącznie offline - dziś konieczna jest ciągła gotowość na przygotowanie albumu do udostępnienia online. Trzeba też dbać o aktualność kafelka z aplikacją: musi wyświetlać najnowsze fotografie nawet, gdy OneDrive nie pobrał wszystkich zdjęć z chmury, bo pracujemy akurat na przecenionym tablecie z dyskiem eMMC o pojemności 32GB. Aplikacja Zdjęcia nie korzysta z żadnej wbudowanej infrastruktury ani danych telemetrycznych. Będąc jednak aplikacją UWP, działa na modłę appek mobilnych i okresowo uaktywnia się jako proces w tle (bez UI), wykonuje swoje synchronizacje, a następnie idzie spać dalej. Nie jest to zadanie wykonywane w ramach Harmonogramu Zadań. Ten leży bowiem "niżej" w systemie i nie jest częścią ogółu rozwiązań składających się na kafelkowy pomysł na Windows.

Czego nigdy nie będziemy wiedzieć o aplikacji Zdjęcia? Tego, czego nie wiemy na temat całego ekosystemu Windows 10: czy pod spodem nie dzieje się więcej, niż się wydaje. Owszem, adresy URL wskazują na synchronizację z dyskiem chmurowym OneDrive, ale Internetowa Gra Warcaby z Windows XP łączyła się z XNA Game Studios, a Galeria Gadżetów Paska Bocznego Windows - z passport.net. Nazwy domen są mylące i nie są mocnym dowodem. Szyfrowany kanał komunikacji nie oznacza, że Windows ukrywa coś przed nami, a raczej, że chroni nasze dane przed oczami osób trzecich. Ale skanując bibliotekę zdjęć, może robić o wiele więcej. Badając ruch I/O w systemie, można zauważyć, że plik wykonywalny Zdjęć dotyka każdego pliku leżącego w bibliotece obrazów. W skrajnym przypadku może wyliczać sumy kontrolne naszych zdjęć, celem odnalezienia czegoś, co zleciły Microsoftowi np. służby specjalne. Może nasze zdjęcia są przeszukiwane pod kątem wzorców? I to niekoniecznie celem wykrycia nielegalnej pornografii, a na przykład skanów jakichś dokumentów. Na pewno coś takiego dzieje się, gdy trzymamy zdjęcia w chmurze - co do tego nie ma wątpliwości. Być może jednak podobne badanie ma miejsce na lokalnych plikach? Nie będę ponownie przytaczał mojej opinii na temat zdania "nie mam nic do ukrycia". Odeślę jedynie do tej publikacji i zarzucę jego wyznawcom… poważne ubytki poznawcze.

Warstwa tajnego wspomagania

Zdjęcia są aplikacją która ma tylko jedną cechę aplikacji "systemowej". Jest dostarczona jako element "zaopatrzenia" obrazu Windows (provisioning). Coś w stylu androidowego mechanizmu sideload. Wewnętrzne wdrożenie aplikacji zachodzi z flagą wyszarzającą przycisk odinstalowania, ale w dalszym ciągu można się jej pozbyć, przesyłając ją jako obiekt do cmdletu Remove-AppxPackage. Zatem Zdjęcia są aplikacją na równi z zewnętrznymi aplikacjami firm trzecich, które możemy instalować przez Sklep. Zejdźmy więc warstwę niżej. Tutaj znajdują się aplikacje, które jedynie udają, że są zwyczajnymi aplikacjami UWP, a praktyce jednak ze względu na ograniczenia funkcjonalne WinRT i UWP korzystają z natywnych aplikacji Win32 pracujących pod spodem jako usługi. Takie rozwiązanie jest oszustwem, ponieważ "normalne" aplikacje UWP działają w piaskownicach i nie mają dostępu do tak niskiego poziomu. Co więcej, podobne zagrywki 25 lat temu były źródłem pozwów: Microsoft miał nielegalnie usprawniać działanie swoich aplikacji, korzystając z nieudokumentowanych funkcji Windows, dzięki czemu wypadały one lepiej, niż programy konkurencji. Dziś już jednak nikt się niczym nie przejmuje i można odstawiać takie numery w biały dzień.

Które aplikacje działają w tym "oszukańczym" trybie? Wszystkie, które korzystają z opisanego przeze mnie niegdyś tajemniczego "koszyka usług Unistack" (UnistackSvcGroup). Wzbudzał on moje podejrzenia, ponieważ, jak mówiłem, wszystkie usługi, które do niego należą, nie pojawiały się w wykazie przystawki MMC "Usługi". Widać je było w programie Autoruns, ale próba ich usunięcia kończyła się błędem odmowy dostępu. W efekcie, moja opinia na temat UniStack była dość złowroga. Dzisiaj mam nieco większą wiedzę na temat działania owego dziwadła i kulisy okazują się być mniej przerażające, aczkolwiek same usługi - nieco dziwniejsze.

Usługi działające jako UniStack nie są uruchamiane przez systemowego użytkownika używanego do uruchamiania większości usług: LocalService lub NetworkService. Zamiast tego, pracują pod kontrolą… zalogowanego użytkownika. Każdemu, kto jest choć trochę zapoznany z administracją Windows Server, ta niecodzienna konfiguracja powinna włączać lampki ostrzegawcze i nasuwać dwa pytania: "dlaczego wobec tego to w ogóle pracuje jako usługa" oraz przede wszystkim: "co z hasłem, skoro uruchamianie usługi jako inny użytkownik wymaga jawnego podania domeny i hasła". To drugie jest oczywiście gorsze. Zanim przedstawię wynik swojego śledztwa dotyczącego Unistack, odpowiem na dwie powyższe kwestie techniczne, ponieważ odpowiedzi otwierają oczy na niektóre pomysły zrodzone wraz z Windows 8.

W krainie wadliwych usług

Windows 10 twórczo rozwija pewien straszny pomysł z czasów Ósemki i dla każdego użytkownika tworzy nową, oddzielną usługę dla każdego elementu UniStack. W systemie są zdefiniowane "zalążki" owych usług, jej bazowe prototypy, siedzące w bibliotekach DLL. Na ich bazie tworzone są klony, hostowane już przez systemowego demona SVCHOST. Nie da się wielokrotnie uruchomić tej samej usługi pod wieloma użytkownikami. Można albo stworzyć nad‑usługę, której wszystko wolno, albo mnożyć usługi na bazie wspólnego korzenia. Drugie podejście jest wbrew pozorom o wiele rozsądniejsze: pozwala uniknąć w przyszłości aktualizacji w stylu "Nieprawidłowo sformatowana wiadomość Skype od kontaktu zawierającego emoji w nazwisku pozwala na zdalne wykonanie kodu i przejęcie kontroli nad komputerem". W razie dziury w takiej usłudze, kod zostałby wykonany na prawach użytkownika, a takie podejrzane zachowanie dostałoby dostrzeżone i ubite przez Defendera. Przyjmijmy wersję, że Defender by się tutaj spisał. Nieusuwalność usług Unistack wynika zatem nie z chęci ukrycia czegoś mrocznego, a z tego, że są one tworzone dynamicznie i niszczone po wylogowaniu. Nie da się usunąć owych usług, bo gałęzie Rejestru, w których siedzą, są otwarte do zapisu. Bez problemu da się jednak usunąć prototypy. No, może nie "bez problemu", ale da się. Tymczasem zauważyć warto, że hasło do wspomnianych usług nie jest w nich przechowywane jawnie.

W jaki sposób można odkryć, że hasło użytkownika nie jest przeklepane do konfiguracji usługi? Można tego dokonać, bo Unistack (celowo dalej nie wyjaśniam, czym jest!) rozrósł się na tyle, że zaczęły nad nim pracować różne zespoły. Pierwsi twórcy dopilnowali, by usługa była ukryta na liście i nieedytowalna. Następni zadbali już tylko o nieedytowalność. Ale zapodziała się jedna taka, którą nie tylko widać gołym okiem, ale i można w niej gmerać. I jej ustawienia zdradzają, że korzysta z magicznych wihajstrów Windows 10, bo z klasycznego (Windows 2000) punktu widzenia, jej konfiguracja jest nieprawidłowa.

Pozostaje ostatnia kwestia, nierozwiązana w mojej analizie z 2015 roku. Co jest powodem, dla którego większości usług Unistack nie ma na liście przystawki MMC Usługi? Czy Microsoft znowu chce coś przed nami ukryć? Wyżej wymienione poszlaki wskazują, że powód leży gdzie indziej. Przystawka services.msc dotyczy usług systemowych. Uruchamianych na lokalnej stacji roboczej, a więc patrząc z perspektywy komputera, a nie użytkownika. A usługi Unistack to atrapy, podróbki prawdziwych usług. Jest ich tyle, ilu jest użytkowników, nie zawsze są uruchomione, a usługa-matka nie pracuje nigdy. Umieszczenie ich na klasycznym wykazie usług jest zatem mylące, ponieważ nie zgadza się scope. Podejrzewam, że taka była wejściowa motywacja ukrywania owych usług w wykazie. Motywacja od tego czasu zapomniana, ponieważ nowe już widać. Za chwilę okaże się, dlaczego uznaję to za wysoce zabawne - powód jest bowiem jeszcze lepszy.

Gdy już wiemy, skąd pochodzą oraz jak ukrywają się usługi Unistack, wyjaśnijmy wreszcie dokładniej, czym są. Co jest tak strasznie ważnego, że aż musi być zaklęte w obiekt niewidoczny w wykazie usług? Otóż członkowie UnistackSvcGroup odpowiadają za utrzymanie "chmurowego stanu" konta użytkownika. Są szyną, przez którą w tle aktualizują się książki telefoniczne, maile, zakładki, SMSy i kalendarze. Oraz drugą szyną, przez którą dostają się do owych danych aplikacje. Właśnie te "oszukane" aplikacje z przywilejami, o których dyskusja zaprowadziła nas na niniejsze manowce. Znajduje się wśród nich również usługa odpowiedzialna za przysyłanie aktualizacji kafelków i powiadomień (Windows Push Notification Service). Zatem nic spektakularnego. Usług wydaje się być trochę sporo, ale granularyzacja svchost i uruchamianie ich w kontekście użytkownika mają wiele zalet związanych z bezpieczeństwem i wydajnością. Ponadto, dostarczana funkcjonalność jest inna od tej oferowanej przez SettingSyncHost, czemu dziwiłem się w pierwszej analizie. Spotkamy się z nim na nowo, gdy będziemy nurkować głębiej w Windows 10. Dwa lata temu nie rozumiałem, dlaczego wszystko nie idzie przez to samo gardło, dziś już wiem.

Zaginione dokumenty

Tutaj czas na plot twist! Otóż klękajcie narody - Microsoft udostępnił dokumentację! TAK! Istnieje dokument opisujący wyżej wymienione, magiczne usługi i znajduje się tutaj. Niniejszy dokument jest wymowny na tak wiele sposobów, że to wprost urzekające. Wydano go we wrześniu 2017, ponad dwa lata po premierze Windows 10. Dotyczy on Windows Server 2016, a zrzuty ekranu z tego systemu ukazują styl graficzny żywcem przeciągnięty z Windows XP, a ściślej z nigdy niewydanego produktu Whistler Server 2002. Poza tym, ta dokumentacja jest jak Isla de Muerta: nie da się na nią trafić, chyba, że już uprzednio wie się, gdzie ona się znajduje. Ja znalazłem ją tak:

Sam dokument brzmi, jak opowiadanie, a nie instrukcja. Konwencja nazewnicza w tekście jest całkowicie swobodna - "template service" raz oznacza jedno, a raz drugie. Nie znajduje się w nim wytłumaczenie, do czego służy Unistack. Są opisy usług, owszem, ale to te same opisy, które są w systemie. Pojawia się natomiast wytłumaczenie, dlaczego usługi nie pokazują w wykazie usług. Jest marne i doprawdy rozczulające. Artykuł informuje, że usługi nie znajdują się w wykazie, więc nie da się nimi zarządzać z poziomu edytora zasad grupy. Wyjaśnijmy, co to znaczy i jakie ma konsekwencje, również "polityczne". Czysto chmurowe usługi działające w przestrzeni użytkownika są, wskutek świadomych decyzji projektowych, ukryte na liście usług, aby nie dało się nimi centralnie zarządzać w organizacjach (domenie). Oznacza to, że zaprojektowano je, by były narzędziami konsumenckimi, niepodatnymi na centralne zarządzanie, zawsze działającymi kafelkami. Według owej myśli projektowej, Windows miał mieć dwie twarze - wysoce konfigurowalnej i zarządzalnej korpo-stacji roboczej oraz kolorowego, prostego interfejsu na przenośne, mobilne urządzenia.

Z tego powodu, usługi Unistore (przechowywanie i udostępnianie stanu chmurowego) oraz Push Notifications (WNS) są niezarządzalne. Mają działać zawsze. Jednakowoż dwie pozostałe usługi Unistack, czyli "Sync Host" oraz "Connected Devices Platform"… już są zarządzalne. Teraz można próbować zgadywać, dlaczego tak jest. Można próbować użyć rozsądku: te dwie ostatnie usługi porozumiewają się z siecią, Unistore nie połączy się bez nich z internetem, więc ich wyłączenie załatwia sprawę. Pudło: Push Notifications też łączy się z siecią i jego normalnie wyłączyć się już nie da. Ale usunięcie wszystkich aplikacji UWP sprawi, że WNS nie będzie się nawet miało z czym łączyć! No niby prawda. Tylko, że jakoś strasznie brzmi, jak wishful thinking, a nie jak rzeczywiste, techniczne wytłumaczenie.

Moja hipoteza jest inna. Moim zdaniem wszystkie z tych usług miały być docelowo niewidzialne, ale niektórym zespołom udało się uniknąć implementacji tego horrendalnego wymagania. Następnie zapomniano o nim, nowe usługi działające według mechanizmu "na żądanie" już się nim nie przejmują, a ludzie wysłani do napisania dokumentacji na ten temat jawnie twierdzą, że całe to zamieszanie to idiotyzm i Unistack powinien być od początku widoczny w całości.

"Chwała nam i naszym kolegom! Ch**** precz!"

Dokumentacja usług zawiera bowiem detaliczny opis wyłączania wszystkich usług szablonowych Unistack(!!!). I to nie za pomocą jakiegoś tajniackiego, nieudokumentowanego dotychczas przełącznika, tylko z wykorzystaniem zdalnych modyfikacji rejestru aplikowanych przez obiekty Zasad Grupy. To kolejny pośredni dowód, że Microsoft jest zbieraniną zespołów, które bardzo często wyznają wrogie sobie nawzajem opinie, a proces wytwórczy prowadzi do tego, że wszystkie ulegają ekspresji jednocześnie. Ma to miejsce ze względu na to, że zespoły mają nie tylko sprzeczne opinie, ale i sprzeczne interesy. Ludzie od kafelków mają stworzyć niemożliwy do popsucia, zawsze działający podsystem, podczas gdy ludzie od serwera mają pilnować, by wszystko bez wyjątku zawsze było zarządzalne.  Odgórny management, jak to w korpo bywa, jakimś cudem klepnął obie koncepcje, prowadząc do bitwy na implementacje. W międzyczasie przychodzi trzeci zespół, który z rocznym opóźnieniem ma opublikować dokumentację - prędko zauważa, że cały problem jest bez sensu i został niemalże zmyślony. Trwając w tej opinii tworzy więc artykuł "jak ominąć chore ograniczenia naszych kolegów". I publikuje go pod niemożliwą do wyszukania nazwą.

Jak wspomniałem - usługi Unistack są mniej mroczne, ale o wiele bardziej żenujące. Dzięki nim udało się napisać pięć akapitów o synchronizacji poczty! Wróćmy już więc do naszego rozbioru Dziesiątki. Skończyliśmy na aplikacjach z "nielegalnym" wspomaganiem, wśród którego znalazł się także demon powiadomień kafelkowych, możliwy do wykorzystania również przez niewspomagane aplikacje UWP firm trzecich. Istnieje jednak jeszcze jeden wspomagacz faworyzujący aplikacje wbudowane i można go znaleźć w Usługach (MapsBroker), ale i w Harmonogramie Zadań. Zadania MapsToastTask i MapsUpdateTask odpowiadają za aktualizację map offline i z tego, co widzę, to mimo możliwości wybrania "systemowego dostawcy map", powyższe zadania dotyczą tylko appki z mapami od Microsoftu. Mimo, że aplikacjom UWP nie wolno sięgać do Harmonogramu Zadań, bo mają własne API. I właśnie to API znajduje się warstwę niżej. Jest to rdzenny runtime środowiska UWP, implementujący ważne cechy systemu chmurowego. Należy do niego  BackgroundTaskHost, SettingSyncHost i RuntimeBroker. Nazwy wyjaśniają tutaj w zasadzie wszystko. Każda z niniejszych aplikacji łączy się z chmurą Microsoftu - pierwsza dostarcza infrastrukturę dla działania zadań w tle dla aplikacji UWP. Dobrym przykładem będzie komunikator: nie musimy uruchamiać całej appki, żeby móc odbierać powiadomienia. Druga aplikacja odpowiada za synchronizację ustawień Konta Microsoft między urządzeniami. Chodzi tu nie tylko o tapetę, ale i  o licencje, hasła, zakładki, języki i historię. Coś w stylu profili wędrujących w Active Directory (long shot, ale przyjmijmy, że mechanizm jest podobny). Trzecia jest dyrygentem niektórych czynności wspólnych dla aplikacji WinRT i UWP. Podobno ma się zajmować jakimś ściślej nieokreślonym zbiorem zadań związanych z kontrolą uprawnień, ale nie wyjaśnia to ani dlaczego potrafi mieć gigantyczne wycieki pamięci ani dlaczego łączy się z internetem. Łańcuchy tekstowe w środku pliku EXE nie mówią zbyt wiele. O wiele więcej mówi Network Monitor. A ten pokazuje, że wszystkie trzy z owych aplikacji potrafią być bardzo gadatliwe, a jednocześnie dotyczą wyłącznie chmurowego świata UWP.

Don't ask don't tell

Na obsługę UWP w systemie składa się oczywiście o wiele więcej usług, jak AppXSvc, TimeBroker, InstallService (dla Sklepu), PushToInstall, embeddedmode, NcbService, SystemEventsBroker itd. Ale mają one tą przewagę nad wyżej wymienionymi, że nieprowokowane, nie uruchamiają się same. Oznacza to, że kompletne wyautowanie się ze świata UWP pozwoli nigdy nie dostrzec owych usług. Jednakże, pomysł na mobilny system operacyjny nie kończy się tam, gdzie API. Podobnie, jak Android, poza środowiskiem uruchomieniowym system dostarcza pokażą paletę nowych rozwiązań sieciowych, by implementować ideę "zawsze podłączonego" urządzenia. Windows 10 generuje więc ruch sieciowy (LAN i WAN), implementujący zbiór nowych, modnych standardów, jak AllJoyn (AJRouter), Geofencing (lfsvc), Natural Authentication, Network Connected Devices Auto-Setup, Windows Perception Service (spectrum), NFC (SeMgrSvc), Mobile Hotspot (icssvc - cóż za wspaniała ewolucja ICS!) i oczywiście cała gama wspomagaczy do Xboksa. Można na nie polować, ale ciekawym zrządzeniem losu, funkcjonalności oferowane przez te usługi są skategoryzowane rolami i dodane jako reguły Zapory:

Pozwala to… wyłączyć je na Zaporze. Bez konieczności wiercenia we wnętrznościach Windows 10. Zawsze mniej inwazyjne jest zablokowanie czegoś na zaporze, niż zatrzymywanie niezarządzalnej, ukrytej usługi. Zapora Windows naprawdę działa i użycie jej do zablokowania niechcianego ruchu jest wystarczające. Pozwoli uniknąć uszkodzenia systemu - próbowałem zatrzymać niechciane usługi chmurowe, ale poza zatrzymaniem ruchu sieciowego uszkodziłem pasek zadań i menu Start. Można wyłączyć te usługi Unistack wg. poradnika Microsoftu, ale nie dotykałbym niczego więcej. Tymczasem Zapora Windows pozwala zablokować ruch nawet indywidualnym aplikacjom UWP. Potraktowanie systemu kuracją zaporową istotnie ucisza ruch sieciowy, ale nie likwiduje go. Poza usługami ściśle systemowymi, o których poniżej, na liście dzielnie pozostają aplikacje BackgroundTaskHost, SettingSyncHost i RuntimeBroker. Nawet, jeżeli nie logujemy się do systemu chmurowym kontem i nie korzystamy z żadnej aplikacji UWP. Trudno tu o rozsądne wytłumaczenie. Faktem jest, że łączą się z siecią tylko raz, przy zalogowaniu. Ale po co w ogóle to robią? Jak się tego dowiedzieć? Trudno znaleźć więcej informacji ponad to, że połączenie jest jednorazowe i objętościowo bardzo małe.

Między chmurą a krzemem

Mniej więcej w tym miejscu kończy się "pomysł na system chmurowy". Całe API aplikacji kafelkowych oraz wszystkie sieciowe nowinki techniczne można ująć w nawias i w całości wyłączyć. W efekcie otrzymamy Windows 7 na kodzie Windows 10. Ale czy zrzucenie nawisu w postaci tego okropnego, nowego API sprawia od razu, że nasz system wraca do stanu znanego z Siódemki? Nietrudno się domyślić, że nie. Dokonano bowiem wielu zmian pod maską "systemu właściwego". Dotyczą one czterech głównych elementów: konta Microsoft, telemetrii, Windows Update oraz Defendera. To właśnie one generują ruch sieciowy po wyrzuceniu/zablokowaniu całego śmiecia od UWP. Każdy z nich miał swój początek w Windows 7, ale był wtedy znacznie, znacznie mniejszy.

Host Usług Diagnostyki

Zacznijmy od telemetrii. Od czasu premiery Windows 10 jest to termin-chochoł, używany do straszenia użytkowników dbających o prywatność. Przesuwa to dyskusję na niewłaściwy obszar, ponieważ telemetria istniała również w poprzednich wersjach Windows i była nie mniej ukryta. To, co generuje najwięcej ruchu, to komunikacja z usługami chmurowymi Microsoftu. Aby unaocznić potęgę różnicy między tymi mechanizmami: wyciąg informacji o zainstalowanym sprzęcie oraz numery wersji oprogramowania układowego w każdym z urządzeń, wysyłany do Microsoftu to telemetria. Zaś każde wyrazy wpisywane do Cortany, a więc i do pola wyszukiwania w menu Start, opatrzone godziną i wysyłane do Akamai - to już komunikacja chmurowa. Która z tych rzeczy jest groźniejsza dla prywatności? Pierwsza może pozwolić najwyżej na wydedukowanie, jakim budżetem dysponuję podczas kupowania sprzętu. Druga natomiast może dotyczyć wszystkich moich wyszukiwań, w tym na przykład cytatów z lokalnie przechowywanych dokumentów. W dodatku ruch jest generowany za każdym razem na żądanie, dzięki czemu otrzymujemy również metadane, jak np. częstotliwość.

Ponieważ zewsząd podnosiły się krzyki dotyczące telemetrii, Microsoft próbował zaadresować wątpliwości dotyczące telemetrii właśnie. Efektem nieprawidłowo ukierunkowanej krytyki jest dzisiejszy pokraczny ekran konfiguracji prywatności, otrzymywany podczas czystej instalacji Windows 10. Pozwala on wybrać poziom objętości danych telemetrycznych. Najwyższy korzysta z mechanizmu Event Tracing, przesyłając informację np. częstości wykorzystania niektórych komponentów, powtarzalności używania elementów GUI, metod rekonfiguracji ustawień systemowych oraz rodzaju wykorzystywanych Narzędzi do Rozwiązywania Problemów (diagcab).  Tymczasem nawet zupełne wyłączenie usługi telemetrycznej nie wpływa decydująco na wagę danych wysyłanych przez chmurowe narzędzia Dziesiątki. Owszem, krzywo patrzę na to, że Microsoft sprawdza, jak często uruchamiam Visual Studio. Ale o wiele gorzej znoszę perspektywę generowania miniaturek dla wszystkich moich zdjęć na dysku z wykorzystaniem zaplecza technicznego online! Krytykowanie Microsoftu za telemetrię pozwala im udawać idiotów - kolejne wersje Windows 10 otrzymają coraz bardziej fikuśne metody konfigurowania usług diagnostycznych, podczas gdy chmurowe aplikacje dalej będą się "by design" dzielić ze światem wszystkim, co robimy.

Nierówna walka z faktami

Wyłączenie usługi DiagTrack, odpowiedzialnej za niesławną telemetrię nie zda się na wiele, bo prędzej czy później uruchomi ją ponownie Windows Update, Defender, Centrum Zabezpieczeń lub Host Ochrony Oprogramowania. Narzędzia systemowe nie pozwalają na wyłączenie gromadzenia i wysyłania danych. Konieczne jest unieruchomienie usługi i zablokowanie hostów odbiorczych na zaporze. Natomiast powtórzę jeszcze raz, że nie martwiłbym się o telemetrię. O wiele bardziej martwiłbym się o komunikację chmurową, którą opisałem wyżej. A dokładniej mówiąc, o dwadzieścia osiem pozostałych komponentów Windows 10, opisanych w artykule "Zarządzanie połączeniami wykonywanymi przez komponenty systemu Windows z usługami firmy Microsoft". Jego publikacja miała miejsce dwa lata po premierze Windows 10. Dokładnie tych informacji zabrakło w lipcu 2015. Mimo, że z definicji nie da się podejrzeć, jakie dane są wysyłane do Microsoftu, to oficjalna lista źródeł komunikacji, wraz z opisem konfiguracji każdego z komponentów uciszyłaby zdecydowaną większość krzyków. Skutkiem ubocznym publikacji takiego zestawienia dwa lata temu byłby zapewne masowy bunt i wdrożenie owych ustawień przez setki tysięcy użytkowników, co w wielu miejscach doprowadziłoby do awarii i uszkodzeń. Biorąc pod uwagę, jak wiele aktualizacji otrzymała pierwsza wersja Windows 10, nietrudno się domyślić, że dane telemetryczne były wtedy na wagę złota. Niemniej, brak dokumentacji zaszczepił masowe przekonanie, że użytkownik końcowy nie ma kontroli nad systemem, którego używa. Nie pomogły smaczne detale takie, jak brak opcji "Wyłącz" na liście dostępnych progów objętości danych telemetrycznych. Mimo, że tak ustawiona usługa, objętościowo (w dalszym ciągu przecież nie mamy pojęcia o zawartości!) wysyła wręcz mniej danych niż to, co jawnie zbiera od nas skan WSUS usługi Windows Update czy taki siedemnastoletni wynalazek, jak Raportowanie Błędów Windows (obecne z nami od czasów Windows XP, przeportowane w dół do 98 i Me wraz z Internet Explorerem 6). A owe źródła to przecież też telemetria. Taka sama od lat.

Wspomniana lista komponentów, które łączą się z Microsoftem zawiera zarówno dotychczasowe elementy, które komunikowały się z chmurą w czasach Windows 7 i Windows XP, jak i najnowsze cuda techniki, czyli przede wszystkim stos aplikacyjny UWP. Microsoft podzielił się metodą zablokowania wszystkich wynalazków, które przytoczyłem powyżej: kafelki, synchronizacja poczty i ustawień, konto Microsoft, usługi sieciowe przestrzeni użytkownika, mechanizmy dostępu aplikacji UWP, Sklep Windows oraz telemetria. Mimo, że została ona napisana głównie pod kątem masowych wdrożeń i zarządzania z użyciem Active Directory, da się jej użyć do wycięcia całego ruchu również na prywatnym komputerze i mogę potwierdzić, że przepis od Microsoftu jest skuteczny:

Zastosowałem metodę opisaną w niniejszym przepisie w połączeniu z artykułem o zablokowaniu usług szablonowych, usunięciem aplikacji UWP, z których nie korzystam i zablokowaniem wszystkich reguł na Zaporze. Wszystko klik-klik. Jaki sens ma wkładanie takiego wysiłku w blokowanie ruchu generowanego przez Windows 10? Mam na myśli użytkowników prywatnych, a nie kontrolowane środowiska sieciowe, jak uczelnia lub korporacja. To zależy, od czego chcemy uciec.

Gdzie uciekać i przed czym?

Jeżeli podchodzimy do tematu pryncypialnie i z założenia nie chcemy udostępniać żadnych danych, a w dodatku nie ufamy, że nie dzieje się to za naszymi plecami, to Windows ze swej natury nie jest dobrym wyborem. Dziesiątka nie ukrywa przede mną żadnego dodatkowego, tajnego ruchu sieciowego, bo wykryte zachowanie i tak jest wystarczająco podejrzane i niegrzeczne. Zresztą wycięcie wykrytego i konfigurowalnego ruchu naprawdę prowadzi do ciszy w eterze, co sprawdzałem (w zeszłym roku) na zarządzalnych switchach oraz bramie internetowej. Ale po prostu z definicji nie możemy wiedzieć, że system nie zadzwoni do domu, bo nie znamy jego źródeł. Mając więc ideowe motywacje, trzeba zrezygnować z Windows i nie ma tu różnicy między 10, 7 i XP.

Jeżeli nie chcemy dzielić się danymi pozwalającymi na stworzenie portretu psychologicznego z kolejną korporacją i jesteśmy w stanie założyć, że nasze zabiegi dają wymierny efekt, "wystarczającym" podejściem będzie odżegnanie się od stosu UWP. Nieposyłanie fraz wyszukiwania do Cortany, niebadanie statystyk wykorzystania aplikacji kafelkowych, nieprzepuszczanie poczty przez appkę "Poczta", nietrzymanie plików na OneDrive, wyłączenie przesyłania informacji w ramach ETW: to wszystko pozwoli nam zmniejszyć skalę tego, jak wiele wie o nas Microsoft, a w praktyce - amerykański wywiad, z radością gromadzący przecież tak wspaniałą pożywkę dla algorytmów głębokiego uczenia, tym razem z dziedziny psychologii. Oczywiście, taką redukcję informacji wnioskować można wyłącznie po objętości. Treść komunikacji jest zaszyfrowana (całe szczęście), ale nie jest wykluczone, że nawet po zmniejszeniu  rozmiaru wysyłanych danych o 90%, w dalszym ciągu Windows 10 śle na nas temat całkiem dużo.

Tam i z powrotem

Pozostaje też kwestia skuteczności naszych zabiegów. W przypadku niewyłączenia Windows Update, duża część ustawień może zostać odkręcona przez którąś z aktualizacji. Te ustawienia, które zostały nałożone mechanizmami systemowymi powinny się ostać (choć i to nie jest regułą!), ale np. takie ręczne blokady komponentów dodawane do zapory prawdopodobnie zostaną odblokowane na nowo, jeżeli pakiet serwisowy dotyczyłby akurat któregoś z nich. Warto też pamiętać, że co pół roku jest wydawana nowa wersja Windows 10, a w ramach aktualizacji system jest wręcz podmieniany na nowy, wiele usuniętych aplikacji jest instalowanych ponownie, a spora część ustawień - przywracana do fabrycznych. Wyłączenie Windows Update jest nieobsługiwane poza domeną, można go dokonać ręcznie nieco na siłę, można też wyłączyć "Optymalizację Dostarczania", czyli coś na kształt torrentów dla łatek. Z tym, że jeżeli chce się uniknąć instalowania aktualizacji i wysyłania raportów przez Windows Update, należy stronić od Windows 10 i albo pozostać przy wersji 7, aktualizowanej ręcznie pakietami "tylko zabezpieczenia" albo użyć wariantu LTSB Dziesiątki i udawać, że ma się bankomat, a nie laptopa.

Na deser

Defenderowi chciałbym poświęcić oddzielny wpis, badałem ten produkt przez ostatnie kilka miesięcy i mam do opracowania spory zbiór wyników. Na deser został nam jednak ostatni gadatliwy komponent Windows 10, o nazwie WLIDSVC. Pochodzi on jeszcze z Windows 8. Gdy odszukałem go w wersji Developer Preview z 2011 roku, wywołał u mnie szczery uśmiech. Potwierdziła się wtedy pewna moja hipoteza. Ale idźmy po kolei.

W okolicach premiery Windows 7 opublikowano pakiet aplikacji "Podstawowe Programy Windows Live". Były to zdrowsze czasy i zamiast dołączać do systemu milion programów-makiet, jak dziś, zdecydowano się usunąć te elementy, które nie będą używane przez wszystkich. W ten sposób z Siódemki poleciał program pocztowy, komunikator, edytor galerii fotografii i program do amatorskiej obróbki filmów. Można je było zainstalować oddzielnie, co zawsze robiłem, ponieważ bardzo lubiłem program Windows Live Mail i w dalszym ciągu korzystam z Movie Makera. Wszystkie z Podstawowych Programów potrafiły pracować offline, ale udostępniały też możliwość łączenia się z chmurą Microsoftu za pomocą konta Windows Live. Logowanie było wspólne: raz wpisane hasło wędrowało między aplikacjami i "wpisywało się samo" w formularze logowania na stronach Microsoftu. Niniejsza funkcja była dostarczana przez program o nazwie WLIDSVC.

Opis tego programu brzmiał "Windows Live Credential Provider". Co to jest Credential Provider? To nie jest ogólne określenie na dostawcę hasła, to oficjalna nazwa podsystemu wtyczek do systemowego ekranu logowania. Domyślnie, Windows pyta o hasło. Możemy jednak uruchomić innych dostawców poświadczeń(Credential Provider): na przykład kartę inteligentną albo odcisk palca. Można też tworzyć własnych. HP dołączał ze sterownikiem do laptopowej kamerki wtyczkę "Face Recognition Credential Provider", która pozwalała logować się do systemu za pomocą buźki. Widząc opis WLIDSVC postawiłem hipotezę roboczą, że nie jest to zbieżność nazw, a program miał w założeniu pełnić rolę znacznie szerszą, niż tylko logować do aplikacji Windows Live.

W Ósemce, WLIDSVC dostał kolegę WLIDCREDPROV, który już jawnie był wtyczką do ekranu logowania i pozwalał uwierzytelnić się do systemu za pomocą konta Microsoft (które musiało wcześniej zostać zarejestrowane w systemie). Użycie tej samej nazwy "Credential Provider", będącej komponentem LSA każe mi domniemywać, że instalacja Podstawowych Programów Windows Live w 2010 roku miała dodawać do Siódemki możliwość logowania za pomocą konta Microsoft. Miałoby to bardzo wiele sensu i kolejny raz potwierdziłoby, że Windows 8 był znacznie mniejszą rewolucją, niż ogłoszono, bowiem poza ładnym "pokrowcem" z aplikacji WinRT wiele nowości powoli dojrzewało już od wielu lat. Zresztą Metro też nie było nowe i nawet raz już o tym pisałem.

Podsumowanie

Mam nadzieję, że udało mi się przekazać więcej uzupełnionej wiedzy na temat telemetrii w Windows 10, niż dwa lata temu. Niewątpliwie pomogło w tym doświadczenie, ale także opublikowane z groteskowym opóźnieniem dokumenty od Microsoftu. Znając fundamenty techniczne chmurowej komunikacji, możemy samodzielnie określić, na ile chcemy Windowsowi pozwalać na korzystanie z danych o nas i naszym sprzęcie. Na swoim komputerze korzystam z wersji LTSB Windows 10, więc nie mam Sklepu, konta Microsoft, żadnej aplikacji Metro oraz nowinek sieciowych typu Teredo. Zmniejszyłem intensywność telemetrii, ale nie wyłączyłem ani Windows Update, ani Defendera. Nie mogę ich wyłączyć, bo ich potrzebuję. Wdrażanie systemów operacyjnych to moja praca, pozbawiając się dostępu do Windows Update wyrządzałbym sobie krzywdę nie tylko pod względem obniżonych zabezpieczeń.

Używam również dysku OneDrive oraz Office 365 do edytowania dokumentów, które na nim leżą. Uruchomienie Worda lub OneNote'a kończy się eksplozją połączeń sieciowych we wszystkich możliwych kierunkach. Więc nawet, gdybym całkowicie wyłączył telemetrię, Office i OneNote mocno zadbają o przesłanie do Microsoftu tylu danych diagnostycznych, ilu tylko im się zapragnie. Dołączyłyby to kopii wszystkich tekstów, nad którymi pracuję, bo trzymam je na OneDrivie, żeby móc edytować je z każdego miejsca. A włączony Windows Update może mi pewnego dnia ściągnąć aktualizację do Defendera, który postanowi na wszelki wypadek policzyć sumy kontrolne wszystkich moim plików i wysłać do MAPSa "celem analizy".

Wywinięcie takiego numeru dostałoby jednak dostrzeżone przez pewne inne urządzenie pracujące w mojej sieci a także - gwarantuję - przez tuziny osób mądrzejszych ode mnie, trudniących się bezpieczeństwem sieci komputerowych na co dzień.

Addendum

Zupełnym zbiegiem okoliczności leży tu jednak laptop z Fedorą, na procesorze bez Intel Management Engine. Niedawno wymieniałem w nim kartę sieciową Wi‑Fi. To ThinkPad, ma doskonałą klawiaturę - świetnie się na niej pisze maile z mojej skrzynki pocztowej na prywatnym serwerze, spiętej z GPG. Ten laptop jest dość wiekowy, ale dalej wystarczająco mocny do wielu zastosowań. Kompletnie nie wiem, skąd się tu wziął.

Cheers!