Browsergate

Skoro jest strona, to sprawa jest poważna, prawda? Coraz głośniej robi się o aferze ochrzczonej Browsergate. Zaczyna się od LinkedIn Is Illegally Searching Your Computer. Czyli grubo. Ale czy słusznie?

Wydaje mi się, że autorzy trochę wyolbrzymiają. Co się dzieje technicznie? Na stronie LinkedIn jest javascript, którego zadaniem jest zebranie informacji o zainstalowanych rozszerzeniach w Chome[1]. Jest to robione przy pomocy paru technik. Najważniejsza z nich opiera się o predefiniowaną listę rozszerzeń i obecnych w nich plików. Skrypt próbował czytać kolejne pliki i – w przypadku sukcesu – zapamiętywał informację, że dane rozszerzenie jest obecne (i aktywne). Tak zebrane informacje były wysyłane do właściciela LinkedIn, czyli Microsoftu. Nie ma natomiast mowy o przeszukiwaniu komputera, co sugeruje nagłówek autorów znaleziska. Aktywność jest ograniczona do plików rozszerzeń.

Autorzy znaleziska argumentują, że za sprawą rozszerzeń w przeglądarce można określić przekonania polityczne, religijne, zdrowotne i dotyczące zatrudnienia. Jestem w stanie się zgodzić, że w specyficznych przypadkach[2] faktycznie da się określić je z wysokim prawdopodobieństwem. I – ponieważ użytkownik jest zalogowany – skorelować z konkretną osobą.

Zatem oburzenie na Microsoft jest słuszne. Czemu jednak jest ograniczone tylko do tej jednej firmy, a Google i twórcy rozszerzeń są tu pominięci? Cała technika możliwa jest tylko dlatego, że przeglądarka Google, podobnie jak wszystkie pochodne Chromium, stosują stałe lokalne identyfikatory rozszerzeń. Nie jest to żadna tajemnica. Nie jest to też norma wśród przeglądarek. Firefox na przykład stosuje losowe identyfikatory lokalne. Takie działanie uniemożliwia stronie próbę odczytu znanego pliku z rozszerzenia, więc technika nie zadziała.

Dodatkowo, twórcy rozszerzenia muszą w manifeście jawnie zezwolić stronie[3] na dostęp do plików przy pomocy dyrektywy web_accessible_resources. Ładny opis, łącznie z tym, że Chrome nie ma losowych identyfikatorów znajdziemy na stronie Mozilli.

Czemu nie ma oburzenia na twórców Chromium, którzy nie randomizują lokalnych ID rozszerzeń? Ani na samych twórców rozszerzeń pozwalających na ustalenie wrażliwych danych, że pozwalają na czytanie plików rozszerzenia stronom[4]? No i w końcu zastanawia mnie, czy to jedyna strona, która tak działa?

Sama funkcjonalność odczytu plików rozszerzeń nie jest nowa i była znana wielu osobom (tak, znałem). Zastosowanie jest… interesujące. Mi masowe skanowanie rozszerzeń nie przyszło do głowy. Może dlatego, że nie mam zastosowania dla tych danych? Czy za sprawą Browsergate będzie mała rewolucja w świecie rozszerzeń i podejściu do prywatności? Zobaczymy.

[1] Tak naprawdę w pochodnych Chromium.
[2] Wymieniają te przypadki i są to konkretne rozszerzenia, których obecność Microsoft celowo sprawdza.
[3] Lub stronom, możliwe wildcardy.
[4] No dobrze, nie zawsze może dać się uniknąć dostępu do plików, zapewne zależy od tego, co dane rozszerzenie robi.

Podwójne standardy

Przy okazji wchodzącej w wielu zakątkach Internetu weryfikacji wieku i protestów z nią związanych, zauważyłem występowanie podwójnych standardów. Chodzi o to, że w świecie fizycznym raczej nikt nie ma problemu z tym, że wiek jest weryfikowany i istnieją ograniczenia wiekowe, a pewne rzeczy dostępne są tylko dla osób pełnoletnich.

Chodzi o możliwość zakupu alkoholu, wyrobów tytoniowych, ostatnio do towarów dostępnych tylko dla pełnoletnich zostały dodane energetyki. Podobnie jest z głosowaniem – czynne prawo wyborcze przysługuje od ukończenia 18 lat. Bierne – jeszcze później.

Tymczasem podnoszony jest argument, że tak nie można, bo prywatność, bo anonimowość, bo wolność. Zastanawiam się jednak, czy anonimowość – czy też: przyzwolenie na nią – mieliśmy do tej pory. Czy możliwość względnej anonimowości pojawiła się dopiero wraz z pojawieniem się Internetu. Przecież idąc do sklepu czy lokalu wyborczego nie jesteśmy anonimowi. Widać, kto kupuje (nawet niekoniecznie towary dostępne od 18 roku życia). W lokalu wyborczym sprawdzana jest tożsamość (i pośrednio wiek) osoby głosującej.

Co więcej, zakaz utrudniania (nawet nie: uniemożliwiania) identyfikacji osoby występuje – już teraz – także w miejscach, gdzie w przypadku uczestnictwa nie ma wymogu ukończenia określonego wieku. Na przykład ustawa o bezpieczeństwie imprez masowych mówi:

Art. 57a. Kto w miejscu i w czasie trwania masowej imprezy sportowej używa
elementu odzieży lub przedmiotu w celu uniemożliwienia lub istotnego utrudnienia rozpoznania osoby, podlega karze ograniczenia wolności albo grzywny nie niższej niż 2000 zł.

Czyli nie można anonimowo kibicować drużynie sportowej. I jakoś nikt nie robi o to afery, prawda?

Podobnie jest z rejestracją kart SIM. Obowiązek rejestracji mamy od około dekady. Jest to ograniczenie anonimowego dostępu do komunikacji telefonicznej, internetu oraz SMSów. Oraz niejawny wymóg weryfikacji wieku. Osoba poniżej 18 roku życia może zarejestrować kartę SIM, o ile ukończyła 13 lat i posiada dowód osobisty. Ten uprawniający do rejestracji karty SIM można mieć po ukończeniu 13 roku życia ale… za zgodą rodziców.

Realny, odczuwalny wpływ w przypadku kart SIM? Dla przytłaczającej większości obywateli żaden. Anegdotycznie, słyszałem, że po wprowadzeniu obowiązku rejestracji kart SIM, osoba zarządzająca w branży budowlanej przestała dostawać telefony z pogróżkami w weekendy od niekoniecznie trzeźwych expracowników.

Dyskusja nt. weryfikacji wieku online mogłaby być znacznie bardziej konstruktywna, gdybyśmy przestali stosować podwójne standardy…

GitHub backup

Od dłuższego czasu poruszany jest w różnych miejscach temat niezależności technologicznej od firm z… innych obszarów prawnych, że tak to ujmę. W szczególności chodzi o firmy spoza Europy. Jest też – nieco niezależny, choć w praktyce często zbieżny – temat uniezależnienia się do wielkich korporacji. Bo jakoś tak się złożyło, że wielkie korporacje nie są europejskie.

Przyznaję, że kibicuję obu tematom. I o ile nie czuję, że muszę koniecznie już teraz przenieść wszystkie zabawki do Europy, to… chcę mieć w razie czego taką możliwość. Pomału się rozglądam, wykonuję pewne drobne – póki co – ruchy. W szczególności jeśli z jakiegoś powodu rezygnuję z jakiejś usługi, to szukam alternatywy w Europie.

Tyle kontekstu, ale przecież miało być o backupie GitHub. Jak powszechnie wiadomo, jest to usługa Microsoftu, czyli podlegająca prawu USA. I w dodatku należąca do jednej z największych korporacji na świecie. Znaczy mogą zrobić z kodem co chcą, w tym… zniknąć go. Zamknąć dowolne konto. Usunąć dowolne repozytorium (i wszystkie jego forki). Bo tak.

Zapewne się to nie wydarzy, jeśli chodzi o moje repozytoria ale… Nie wiadomo. Bo już różne rzeczy były z GitHub usuwane. Więc ktoś kiedyś może wpaść na pomysł, że np. bruteforce PESELi to groźne narzędzie i trzeba repozytorium – albo i całe konto – usunąć. Wolę więc mieć możliwość przywrócenia swojego kodu z backupu. Backup serwerów i tak robię, wiele własnego kodu nie mam. Więc zrobienie kopii repozytoriów do katalogu, który jest objęty backupem wygląda jak proste, lekkie rozwiązanie.

Jeśli chodzi o ewentualne zastępstwo dla GitHuba, wybrałem popularną alternatywę w postaci europejskiego Codeberg.org[1]. Na którym i tak założyłem już wcześniej konto z uwagi na pewien pull request, który chciałem zrobić.

Repozytoriów trochę mam, są one publiczne, więc postanowiłem zautomatyzować robienie backupu, żeby nie musieć pamiętać o dodaniu każdego nowego repozytorium do skryptu robiącego backup. Po prostu robię backup wszystkich publicznych repozytoriów należących do danego użytkownika GitHub. Oczywista konsekwencja – i wada rozwiązania – jest taka, że jeśli zrobię fork jakiegoś większego projektu, to także on trafi do backupu. Jednak nie jest to częsta sytuacja, a nawet te większe projekty nie są aż tak duże, żeby mi to przeszkadzało.

Skrypt github-backup jest – jak widać – bardzo prosty. Wymaga zewnętrznego programu git i tylko jednej biblioteki – requests. Zasada działania skryptu github-backup jest prosta. Przechodzimy do katalogu ze skryptem. Podajemy usera jako parametr. W katalogu, w którym jest uruchamiany skrypt, najpierw tworzony jest katalog o takiej nazwie, jak nazwa użytkownika[2]. Następnie pobierana jest lista publicznych repozytoriów użytkownika. A w końcu dla każdego z nich tworzona jest kopia przy pomocy zewnętrznego polecenia git clone –mirror. I tyle. Tak utworzone kopie można przywrócić na innym serwerze przy pomocy git push –mirror. Przykład w readme.

Skrypt ma wady, których nie potrzebowałem poprawiać. Po pierwsze, robi mirror do bieżącej lokalizacji. Nie jest to problem przy planowanym użyciu, czyli z użyciem cron – po prostu wcześniej trzeba zmienić katalog. Po drugie, nie obsługuje prywatnych repozytoriów. Cóż, trochę nie miałem takiej potrzeby. Poza tym, o ile dodanie klucza, który ma do nich dostęp w trybie odczyt nie jest problemem, to nad listowaniem musiałbym się zastanowić[3]. Może kiedyś, bo jak wspomniałem, obecnie nie mam takiej potrzeby.

Plany rozwoju skryptu? Dodanie obsługi innych platform przydało by się najbardziej, bo żaden dostawca ani jurysdykcja nie dają gwarancji, że konto czy repozytorium nie zniknie. Przy czym pewnie w najbliższej przyszłości skończy się na Codeberg, bo tylko tego aktualnie używam i będę miał jak przetestować. Może jednak dodanie obsługi prywatnych repozytoriów?

W każdym razie jeśli rozwiązanie komuś się przyda, to zachęcam do używania. I oczywiście robienia backupów, w tym przypadku własnego kodu. Niezależnie od metody.

UPDATE: To naprawdę prosty skrypt i główną zaletą jest brak potrzeby jakiegokolwiek uwierzytelniania, jeśli ktoś potrzebuje więcej, to istnieje np. ghorg.

[1] Ogólnie jest to serwis godny rozważenia, choć community o wiele mniejsze.
[2] Uwaga, najpierw jest usuwana cała zawartość katalogu o takiej nazwie, jeśli istnieje!
[3] No dobra, sprawdziłem, wystarczy dodać obsługę PAT (personal access token) i stosownie skonfigurować ich uprawnienia.