Zmiany w obsłudze User-Agent w przeglądarkach opartych na Chromium

Zgodnie z publikacjami na blogu projektu Chromium, w sierpniu 2019 r. w ramach Privacy Sandbox Project, został opracowany mechanizm Client Hints. Pod koniec ubiegłego miesiąca ponownie zrobiło się o nim głośno, a to za sprawą publikacji Mike Westa (Chrome Security Team) i Yoav Weissa (Chrome Developer Relations Team) na W3C Community Group i zapowiedzi jego implementacji przed końcem roku.

Zasięg zmian jest bardzo szeroki, bo obejmuje wszystkie zależne od Chromium przeglądarki, co sumarycznie przekłada się na ponad 75% użytkowników.

Nowy mechanizm ma na celu zapewnienie deweloperom możliwości negocjowania treści na podstawie identyfikatora User-Agent klienta, bez odsłaniania zbędnych informacji, które służą tworzeniu „odcisku palca” użytkowników i ograniczają prywatność.  

Co to w ogóle jest User-Agent?

Zanim wejdziemy w dalsze szczegóły, przypomnijmy, co to jest User-Agent (UA)? UA jest ciągiem znaków (tekst), jaki przeglądarki internetowe oraz inne oprogramowanie klienckie przesyła serwerowi w czasie inicjalnego połączenia z witryną lub aplikacją webową. User-Agent to swego rodzaju wizytówka, zawiera informacje o typie przeglądarki, silniku renderującym oraz systemie operacyjnym, przykładowo:

Powyższy zrzut ekranu wizualizuje identyfikację mojej przeglądarki za pomocą useraget v2.2.1 (na whatsmyua.info można zobaczyć wyniki useragent, ua-parser-js oraz platform.js). Rzućmy okien na wyniki z komunikatora Teams. 

Powyższa funkcjonalność może być użyteczna, gdy serwer oczekuje wykonania czynności, którą nie każde oprogramowanie klienckie potrafi zrealizować, dając tym samym możliwość obsługi wyjątków. Takimi funkcjonalnościami może być uwierzytelnianie zintegrowane z Windows, obsługa akceleracji 3D, obracanie ekranu lub odtwarzanie określonych formatów wideo. Wydaje się, że to dość użyteczne, prawda? 

Diabeł tkwi w szczegółach

Niestety (nader często) UA jest wykorzystywany do innych niż wskazane wcześniej cele, np. bardziej precyzyjnego śledzenia użytkowników lub blokowania konkurencji. Przed pierwszy bronią się użytkownicy, za pomocą opcji wbudowanych lub dostarczanych przez rozszerzenia, przed drugim „ograniczani” dostawcy oprogramowania i usług.

Vivaldi podobnie jako nowy Edge opiera się na kodzie Chromium. Jednak Google Search oraz Docs, Netflix Player, Facebook WhatsApp, a nawet Microsoft Teams, blokują możliwość korzystania lub robią to z umyślnymi błędami (które znikają, gdy tylko UA przeglądarki zostanie „sfałszowane”). Dlatego od grudnia 2019 r. Vivaldi maskuje swój UA, z wyjątkiem kilku witryn, z którymi otwarcie współpracuje (duckduckgo.com, ecosia.org, qwant.com i startpage.com).  Google blokuje używanie rozwojowych wersji Edge w Stadia Cloud Gaming Service oraz kilku innych usługach. 

Powiecie (zresztą słusznie, że to) dość skrajne przypadki. Jednak, gdy się przyjrzeć zachowaniu przeglądarek, okaże się, że wszyscy „kłamią” na swój temat, udając, że są wszystkimi. Im bardziej tak się dzieje, tym mniej użyteczne staje się wykrywanie User-Agent. 

Jaki jest plan Google?

Google planuje zaprzestać aktualizowania komponentu UA w Chrome nowymi ciągami (tekstem UA, który Chrome udostępnia stronom internetowym).

Plan długoterminowy polega na ujednoliceniu wszystkich ciągów znaków UA Chrome w ogólne wartości, które nie ujawniają zbyt dużej ilości informacji o użytkowniku. Oznacza to, że nowe wersje przeglądarki Chrome na nowe platformy, takie jak nowe modele smartfonów lub nowe wersje systemu operacyjnego, będą używać ogólnego identyfikatora UA, a nie takiego, który jest dostosowany do konkretnej platformy.

Na przykład w przyszłości witryna internetowa nie będzie w stanie stwierdzić, czy użytkownik korzystający z Chrome używa Chrome w systemie Windows 7 lub Windows 11, czy też użytkownik mobilny Chrome korzysta z telefonu Samsung Galaxy, iPhone czy Pixel.

Strony internetowe będą mogły stwierdzić, że użytkownik korzysta z Chrome na komputerze lub urządzeniu mobilnym i nic poza tym.

Ze względu wsteczną kompatybilność User-Agent w Chrome będzie nadal działać, więc nie uszkodzi to mechanizmów i skryptów w dotychczasowych witrynach i aplikacjach webowych. Z czasem jego znaczenie będzie jednak maleć. 

Oto aktualny plan Google dotyczący ograniczenia obsługi User-Agent:

• Chrome 81 (połowa marca 2020 r.) - Google planuje wyświetlać ostrzeżenia w konsoli Chrome dla stron internetowych, które czytają ciąg znaków UA, aby programiści mogli dostosować kod swojej witryny.
• Chrome 83 (początek czerwca 2020 r.) - Google zamrozi wersję przeglądarki Chrome w identyfikatorze UA i ujednolici wersje systemu operacyjnego.
• Chrome 85 (połowa września 2020 r.) - Google ujednolici identyfikator UA dla desktopowych wersji przeglądarek. Podobne ujednolicenie spotka też wersje na systemy mobilne.

Poniżej przedstawiono przykładowy User-Agent dla mobilnej wersji Chrome  po zamrożeniu modyfikacji UA:

Mozilla/5.0 (Linux; Android 9; Unspecified Device) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/71.1.2222.33 Mobile Safari/537.36

Tak z kolei będzie się prezentować Chrome w wersji na desktopy po zamrożeniu UA:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.1.2222.33 Safari/537.36

Gdy użytkownik otworzy witrynę lub aplikację webową, jego żądanie będzie zawierać zamrożony identyfikator UA, a także specjalny nagłówek „Sec-UA”, który przekaże podstawowe informacje o kliencie, jak pokazano poniżej.

Sec-CH-UA: "Examplary Browser 73"

Jeśli serwer potrzebować będzie więcej informacji, poprosi o to w nagłówku odpowiedzi „opt-in”. Wówczas, zostanie poproszony o dostarczenie dodatkowych informacji, np. takich jak wersja pomocnicza i system operacyjny. Można to zrobić za pomocą następującego żądania w nagłówku HTTP:

Accept-CH: UA, Platform

Wówczas klienci, którzy będą kompatybilni i których ustawienia na to pozwolą, prześlą następującą odpowiedź na takie żądanie:

Sec-CH-UA: "Examplary Browser 73.3R8.2H.1"
Sec-CH-Platform: "Windows 10"

Decyzja o wysłaniu informacji będzie należała do klienta, zatem indywidualni użytkownicy oraz organizacje będą mogły stosować własne reguły odpowiadania, udzielając dodatkowych informacji witrynom i aplikacjom z zaufanych adresów.

Aby skorzystać z Client Hints, witryna lub aplikacja webowa musi spełnić następujące wymagania:

• Żądania opt-in serwera muszą być kierowane z adresu głównego poziomu witryny (top-level navigation request) przez bezpieczne połączenie (TLS).
• Odpowiedzi są dostarczane tylko w odpowiedzi na oryginalne żądanie (inaczej niż w przypadku ciasteczek) w bezpiecznym połączeniu.
• Jeśli odpowiedzi otrzymane przez witrynę lub aplikację webową otwartą przez użytkownika (własne, first-party) mają być dostarczane do określonych serwerów innych podmiotów (third-party hosts), należy je jawnie wydelegować.
• Odpowiedzi są przekazywane z prefiksem Sec-, aby zapewnić większe bezpieczeństwo oraz uniknąć błędów z obsługą po stornie niekomatybilnych serwerów.

Uwzględniając powyższe, Google chce usunąć dostęp do właściwości navigator.userAgent za pomocą JavaScript w Chrome 81.

Co z implementacją w innych przeglądarkach?

Apple (Safari), Microsoft (Edge) oraz Mozilla (Firefox) w mniej lub bardziej oficjalny sposób potwierdził, że zaimplementują proponowany przez Google mechanizm wycofania obsługi User-Agent na rzecz Client Hints. Na szczegóły przyjdzie nam jeszcze poczekać. 

W mapie rozwoju Edge nie ma jeszcze informacji o nowym mechanizmie. 

Nie ma ich też w artykule Site compatibility-impacting changes coming to Microsoft Edge, gdzie w pierwszej kolejności informujemy o dużych zmianach, które wpływają na kompatybilność przeglądarki.

Jaki to ma wpływ na rozwiązania Microsoftu? 

Nie ulega wątpliwości, że zmiany te będą miały wpływ na witryny oraz aplikacje webowe uruchomione na ISS w Windows Server, a także Azure Web App oraz Azure Web Sites.

Zmiany dotkną także platformy uwierzytelniania w chmurze (Microsoft Online Services Sign-In, Microsoft Office 365 Identity Platform) oraz usług federacyjnych Active Directory Federation Services.

W tych drugich, w Windows Server 2016 i nowszych, istnieją dwa mechanizmy wykrywania zgodności klientów z mechanizmami logowania zintegrowanego z Windows. Aby się o tym przekonać, przyjrzyjmy się właściwości WiaEvaluationMethod zwracanej przez polecenie Get-AdfsProperties.

Ustawienie WiaEvaluationMethod może przyjąć dwie wartości: WiaCapabilityDetection oraz WiaUserAgentDetection. Domyślne ADFS posługuje się drugą wartością, co powoduje, że oferuje mechanizmy logowania zintegrowanego klientom (Kerberos, Single Sign-On (SSO)), których User-Agent znajduje się na liście kompatybilnych.

Oznacza to, że najpóźniej we wrześniu należy się spodziewać poprawki, która dostarczy obsługi żądań opcjonalnych przez serwer usług federacyjnych i tym sposobem pozyskiwane będą wymagane elementy identyfikujące klienta za pomocą Client Hints.

Z drugiej strony, może to być także dodatkowa motywacja dla grupy produktowej, aby wznowiono prace nad mechanizmami WiaCapabilityDetection oraz dostarczono ich publicznej dokumentacji.