Nitter i prywatność. Co widzi operator instancji?

Nitter pobiera treści z X po stronie swojego serwera. Według dokumentacji projektu przeglądarka czytelnika nie musi w tym celu łączyć się bezpośrednio z X. To sensowna zmiana. Nie mówi jednak, co z żądaniem robi serwer stojący pośrodku.

Po tekstach o zamknięciu i powrocie projektu, zebranych w dossier Nitter i XCancel, zostaje właśnie to pytanie. Wybieramy inny adres, bo mniej ufamy X. Zaufanie do operatora tego adresu często przechodzi już bez dyskusji.

Kto odbiera twoje żądanie

Przy zwykłym otwarciu profilu przez instancję Nittera żądanie najpierw dociera do infrastruktury tej instancji. Operator może znać adres IP połączenia, żądaną ścieżkę i czas odczytu. Jeżeli korzystasz z pośrednika sieciowego, nie musi to być adres twojego domowego łącza. Nadal jednak ktoś obsługuje żądanie dotyczące konkretnego profilu.

Nie trzeba do tego ciasteczka reklamowego. Dokumentacja Nginxa pokazuje standardowy format logów obejmujący między innymi adres klienta, czas, żądanie i nagłówek przeglądarki. Pozwala też wyłączyć zapisywanie logów. Możliwość zapisania danych nie dowodzi, że konkretna instancja je zapisuje. Bez sprawdzenia jej konfiguracji i infrastruktury nie rozstrzygniemy tego z wyglądu strony.

Dokumentacja Nittera wspomina o ograniczonym logowaniu samej aplikacji i zaleca ustawienie jej za reverse proxy, takim jak Nginx. Te dwie informacje trzeba czytać razem. Aplikacja może nie prowadzić historii odwiedzin, podczas gdy warstwa przyjmująca połączenia prowadzi własny dziennik. Osobną warstwą może być dostawca ochrony lub hostingu.

Kłódka nie ukrywa pytania przed serwerem

HTTPS chroni transmisję między przeglądarką a punktem, w którym kończy się szyfrowane połączenie. Utrudnia podglądanie treści po drodze. Serwer musi jednak odczytać żądanie, żeby odpowiedzieć właściwą stroną. Takie jest zadanie TLS, opisane w dokumentacji MDN; szyfrowanie transportu nie jest obietnicą anonimowości wobec usługi.

Wyobraź sobie więc odczytywanie publicznego profilu raz w miesiącu oraz regularne sprawdzanie kilku osób podczas pracy nad wrażliwym tematem. Treści są publiczne w obu przypadkach. Znaczenie informacji o tym, kto i kiedy je czyta, jest zupełnie inne. To mój powód, żeby rozdzielać prywatność treści od prywatności zainteresowań.

Kod projektu nie jest audytem instancji

Nitter deklaruje brak reklam i JavaScriptu oraz pośredniczenie w żądaniach do X. To opis projektu. Operator konkretnej domeny może zmienić kod, konfigurację albo dołożyć dodatkowe elementy. Nie przeprowadziłem audytu serwera XCancel ani innych publicznych instancji, więc nie przypisuję im tutaj praktyk, których nie sprawdziłem.

Przed użyciem do wrażliwej pracy sprawdziłbym, czy operator w ogóle opisuje logowanie i czas przechowywania danych. Brak takiej informacji zostawiłbym jako niewiadomą, zamiast tłumaczyć go sobie na korzyść serwisu. Osobno warto uważać na linki prowadzące poza instancję: po przejściu pod inny adres korzystasz już z innej usługi i jej zasad.

Do czytania publicznych wpisów bez interfejsu X taki pośrednik może być wygodny. Przy obserwowaniu wrażliwego tematu nie wystarcza mi jednak sama obietnica, że przeglądarka nie odzywa się do X. Chcę wiedzieć także, komu pokazuję listę rzeczy, które czytam.

Źródła

• Nitter: dokumentacja projektu i wdrożenia
• Nginx: moduł logowania żądań HTTP
• MDN: Transport Layer Security

Zdjęcie ilustracyjne: Kelly Sikkema / Unsplash.