Symulacja mobilnego fingerprintu sprawia, że przeglądarka desktopowa działa pod tożsamością urządzenia mobilnego. Ekran, model urządzenia, sensory i dotyk, sieć i operator oraz identyfikatory UA/App muszą być wzajemnie spójne, aby środowisko wyglądało wiarygodnie podczas kontroli.
Podczas prowadzenia reklam i obsługi kont na platformach takich jak Facebook, Instagram i TikTok wiele działań zachowuje się inaczej na urządzeniach mobilnych niż na desktopie: układ strony jest inny, dostęp do funkcji odbywa się przez inne miejsca, a platforma może inaczej traktować ruch mobilny. Aby sprawdzić te scenariusze bez utrzymywania wielu fizycznych telefonów, trzeba sprawić, by przeglądarka desktopowa prezentowała się jako urządzenie mobilne.
W jednym zdaniu brzmi to prosto, ale w praktyce wymaga skoordynowania całego zestawu parametrów. Wiarygodność środowiska mobilnego zależy od tego, czy wszystkie te parametry mają sens razem.
Czym różni się mobile od desktopu
Najbardziej oczywista różnica to ekran. Logiczna rozdzielczość i szerokość viewportu urządzeń mobilnych znacząco różnią się od desktopowych, a nawet dla tego samego modelu użyteczny viewport może zmieniać się wraz z wersją systemu. Jeśli ustawienia ekranu się nie zgadzają, dalsze parametry także będą wyglądały niespójnie.
Drugą warstwą są model urządzenia i klasa sprzętu. Platforma może na podstawie modelu oszacować segment urządzenia i zdecydować, jaką wersję strony lub materiału wyświetlić. Model, pixel ratio, pamięć i parametry graficzne powinny do siebie pasować. Połączenie nazwy modelu z wyższej półki z cechami sprzętowymi urządzenia niskiej klasy jest samo w sobie sprzeczne.
Często pomijaną warstwą są sensory i cechy dotyku. Prawdziwe telefony mają żyroskop i akcelerometr, a touch events mogą zawierać informacje o nacisku, powierzchni kontaktu i multi-touch, których przeglądarka desktopowa domyślnie nie oferuje. Jeśli zmieni się tylko UA na mobilny, sprawdzenie touch events może od razu ujawnić rozbieżność. W tej warstwie potrzebne są spójne odczyty sensorów i zachowanie touch events, a nie tylko włączenie kilku opcji.
Typ sieci i operator również są częścią fingerprintu. Urządzenia mobilne zwykle korzystają z sieci komórkowych, a strona może odczytać nazwę operatora, typ połączenia, a czasem także informacje związane z sygnałem. Jeśli środowisko deklaruje konkretnego operatora w danym kraju, ale ruch wychodzący korzysta z IP centrum danych, taka kombinacja jest nietypowa dla realnego urządzenia i warto sprawdzić ją osobno.
Ostatnią warstwą są user agent i identyfikatory urządzenia, a dla wielu osób jest to jedyna warstwa, którą modyfikują. UA powinien pasować do modelu urządzenia, wersji systemu i wersji przeglądarki. Identyfikator WebView w App i zwykły identyfikator przeglądarki to również dwie różne rzeczy; platforma może na ich podstawie określić, czy wejście nastąpiło z App, czy bezpośrednio z przeglądarki. Mieszanie obu typów ujawnia ślady sztucznie złożonego środowiska.
Jak sprawdzać spójność
Po skonfigurowaniu parametrów najlepiej przeprowadzić kontrolę w ustalonej kolejności. Kolejność ma znaczenie, ponieważ problem z wcześniejszej warstwy może wyglądać jak problem z późniejszej.
Najpierw sprawdź tożsamość urządzenia: czy system operacyjny, model urządzenia, rozdzielczość i pixel ratio odczytane przez stronę testową odpowiadają konfiguracji, a model i wersja systemu w UA są zgodne z tymi wartościami. Następnie sprawdź strefę czasową i język. Oba powinny odpowiadać rynkowi docelowemu konta, a geolokalizacja i region wyjściowy powinny znajdować się w tym samym obszarze; sprzeczności między tymi elementami należą do częstych sygnałów. Potem sprawdź sieć: czy IP wyjściowe jest residential czy data-center, czy informacje o operatorze pasują do przypisania IP i czy WebRTC nie ujawnia adresu, który zupełnie nie pasuje do środowiska. Na końcu sprawdź możliwości behawioralne: touch events, odczyty sensorów i zestaw fontów powinny wyglądać tak, jak na urządzeniu mobilnym.
Jeśli kilka elementów jest niezgodnych, najpierw ustal, który parametr koliduje z całością, zamiast wielokrotnie budować środowisko od nowa. Ponowne utworzenie nie usuwa wewnętrznych sprzeczności między parametrami.
Warto też pamiętać, że anomalia pokazana przez zewnętrzną stronę testową nie musi oznaczać problemu z samym środowiskiem. Serwisy testowe zbierają dane na różne sposoby; jedne uruchamiają skrypty odczytujące cechy przeglądarki, inne analizują request headers, dlatego ten sam profil może otrzymać różne wyniki w różnych serwisach. Rozszerzenia przeglądarki mogą zmieniać to, co odczytuje strona, a nieaktualna baza IP może przypisać residential IP do niewłaściwej lokalizacji. Lepiej wybrać jeden regularnie aktualizowany i wiarygodny serwis jako punkt odniesienia niż bez końca porównywać wyniki wielu stron.
Symulacja mobilna nie zastępuje prawdziwego urządzenia
Niektóre scenariusze nadal wymagają fizycznych urządzeń: testy potrzebujące prawdziwych danych z sensorów, kamery lub pełnych możliwości żyroskopu; etapy kontroli ryzyka, w których platforma bardzo rygorystycznie sprawdza autentyczność urządzenia wewnątrz App; oraz weryfikacje obejmujące prawdziwe płatności lub realną sieć operatora. Ponadto część funkcji platform występuje tylko w natywnym kliencie i nie jest dostępna przez web, więc środowisko symulowane ich nie zastąpi.
Praktyczny podział jest prosty: scenariusze mobilne możliwe do obsłużenia przez web można powierzyć środowisku symulowanemu, a walidację sprzętową i na poziomie App wykonywać na prawdziwych urządzeniach. Te dwa podejścia się uzupełniają, a nie zastępują.
Często zadawane pytania
Czy wystarczy zmienić tylko UA, aby przejść kontrolę Zwykle nie. UA należy do parametrów najłatwiejszych do zmiany osobno, ale też najłatwiejszych do sprawdzenia krzyżowo. Jeśli rozdzielczość, fonty, język, strefa czasowa i obsługa dotyku nie pasują, rozbieżność łatwo zauważyć.
Czy jedno konto powinno być stale używane na mobile albo desktopie Lepiej zachować stałość. Częste przełączanie tego samego konta między dwoma typami urządzeń może samo w sobie stanowić nietypowy sygnał. Typ urządzenia w środowisku powinien odpowiadać zwykłemu sposobowi korzystania z konta.
Na co uważać pod kątem zgodności Używaj tego wyłącznie do testów kont, które sam prowadzisz, i własnych procesów biznesowych. Nie używaj do fałszowania tożsamości urządzenia w celu omijania weryfikacji platformy ani do działań oszukańczych.
Podsumowanie
Symulacja mobilnego fingerprintu nie polega na zmianie jednego parametru, lecz na zapewnieniu spójności całego zestawu z tożsamością urządzenia i rynkiem docelowym. Ekran, model, sensory, sieć i UA powinny być wiarygodne osobno i nie mogą sobie przeczyć. Zarządzaj środowiskami mobilnymi i desktopowymi oddzielnie, utrzymuj konto przez dłuższy czas na stabilnym profilu urządzenia i korzystaj z oddzielnego wyjścia zgodnego z regionem. Narzędzia do zarządzania środowiskiem, takie jak PurpleMark, mogą podczas tworzenia środowiska powiązać parametry urządzenia i systemu, proxy i stronę startową, a przy każdym otwarciu przywrócić te same ustawienia, eliminując konieczność ponownej konfiguracji.
