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.

Gdzie się kończy sieć tekstowa?

Dawno czytałem wpis o powrocie do sieci tekstowej. Już w komentarzach zaczęła się dyskusja, czym jest sieć tekstowa. Zacząłem pisać ten wpis i – niespodzianki dla stałych czytelników nie będzie – trafił do szkiców i tam sobie leżakował. Wpis miał być o tym, jak rozumiem sieć tekstowa i jak widzę poziomy utekstowienia sieci.

Sieć tekstowa bez formatowania

Sieć tekstowa bez formatowania, czyli autor treści ma do dyspozycji wyłącznie tekst. Wszelkiego typu ozdobniki są możliwe jedynie poprzez wykorzystanie znaków tekstowych, w stylu ascii-art. Bez gwarancji, że będzie to widoczne zgodnie z zamierzeniem przez odbiorcę. Przykłady: IRC, mail w trybie tekstowym, newsgroups (NNTP). Trochę odpowiednik nadawania alfabetem Morse’a czy telegramów. Albo notatek odręcznych. Idealnym analogowym przykładem, który wyniknął podczas dyskusji jest… maszynopis.

Sieć tekstowa z formatowaniem

Sieć tekstowa z formatowaniem i… ilustracjami. Jest to odpowiednik książek, gazet czy nawet magazynów ilustrowanych. Autor określa zarówno treść, jak i sposób jej prezentacji. Przynajmniej sugerowany sposób. Ma możliwość stosowania krojów pisma, fontów, styli w dokumencie. Ma zatem pewną – choć niekoniecznie pełną – kontrolę nad prezentacją treści. Użytkownik będący odbiorcą może dowolnie modyfikować wygląd styli na swoim urządzeniu.

Typowym przykładem jest zwykła strona WWW, z wykorzystaniem HTML. Na przykład ten blog. Zaliczam też tu różnego rodzaju social media typu Facebook, Twitter/X, czy Mastodon. Oraz maila w HTML. Zamiast HTML może być dowolny inny sposób formatowania dokumentów, np. Markdown. Ważny jest fakt formatowania, nie technologia.

Pewnym nietypowym wariantem będzie tu strona z osadzonym dźwiękiem czy filmami. Taki powiedzmy odpowiednik książki lub czasopisma z dołączoną płytą CD czy DVD.

Sieciowy komiks

Sieciowy komiks, czyli sieć, gdzie tekst jest nierozerwalnie związany z grafiką, a grafika pełni pierwszoplanową rolę. Tekst istnieje i jest niezbędny, ale zwykle jest krótki i nie jest samodzielnym przekazem. Autor określa treść, sposób prezentacji i ma pełną kontrolę nad tym ostatnim. Możliwość zmiany przez odbiorcę ogranicza się do powiększenia. Przykłady to różnego rodzaju memy czy serwisy typu demotywatory.pl. Tekst – niekiedy szczątkowy – jest osadzony na stałe w grafice.

Sieć multimedialna

Sieć multimedialna, czyli sieć, gdzie tekst w zasadzie nie istnieje. Jeśli nawet istnieje, to jedynie jako dodatek, nie jest obowiązkowy. Przekaz treści następuje głównie – albo nawet wyłącznie – poprzez obrazy i dźwięk. Jest to odpowiednik słuchowisk radiowych, audycji telewizyjnych, audiobooków, czy filmów. Przykładem mogą być różnego rodzaju podcasty, filmy na YouTube czy TikTok.

Wracając do odpowiedzi na pytanie: gdzie się kończy sieć tekstowa? Jak dla mnie kończy się ona na sieciowym komiksie. Podobnie jak zwykłego komiksu już nie uważam za książkę, tak sieciowego komiksu nie uważam już za sieć tekstową. Może, w pewnych okolicznościach, uznam je za szczątkowe czy też wyjątkowe formy.

UPDATE Dodany maszynopis jako przykład.

Optymalizacja strony

Kolejny wpis, który przeleżał wiele czasu jako szkic. Nie znalazłem na niego czasu, a teraz sprawdziłem i dobrze się zestarzał, więc opublikuję to, co mam, choć nie pociągnąłem do końca tematu, którym jest optymalizacja stron WWW, tym razem bardziej od strony serwera, niż WordPressa, o którym wtedy napisałem.

Na początek polecam wpis Yzoji o optymalizacji bloga. I komentarze do niego. Tak, wpis jest sprzed trzech lat. Tak, jest aktualny, a wszystko co tu znajdziesz powstało właśnie wtedy. Raczej postaram się napisać uzupełnienie, niż powtarzać rady z tamtego wpisu.

Efekty

Nie mam niestety porównania sprzed wprowadzania zmian, ale żeby było wiadomo o czym rozmawiamy. Efekty optymalizacji strony bloga, wg PageSpeed Insights, przedstawiają się następująco:

Wynik optymalizacji strony wg PageSpeed dla desktop - performance 100%
Wynik dla desktop
Wynik optymalizacji strony wg PageSpeed wynik dla mobile - performance 9%
Wynik dla mobile

Kompresja

Na przyspieszenie działania bloga pomogło zmniejszenie poziomu kompresji w nginx. Tak, dobrze czytacie, zmniejszenie, nie zwiększenie. Dlaczego? Otóż tekst kompresuje się dobrze tak czy inaczej. A różnice w szybkości działania kompresji gzip są znaczne. Czyli mamy mininalnie większą ilość przesyłanych danych, ale odpowiedź jest wysyłana znacznie szybciej! Być może to kwestia relatywnie słabego VPSa, ale skoro nie widać różnicy, po co przepłacać? W każdym razie w konfiguracji nginx mam:

gzip_comp_level 1;

Lazy loading

Kolejną rzeczą, która przyspieszyła działanie tego bloga było wyłączenie lazy loading. Było o tym u Yzoji, ale warto powtórzyć, bo znowu, jest to nieintuicyjne. W dodatku wszyscy mantrują, że włączenie lazy loadingu jest dobre dla szybkości ładowania. No i teoretycznie mają rację. Ale nie jest to prawdą na stronach, gdzie ilość załączanych grafik jest niewielka. Więc jak mam jedną czy w porywach dwie skromne grafiki na wpis, to lazy loading tylko spowolni ładowanie. Gdyby grafik było więcej lub były większe – pewnie włączenie lazy loadingu mógłoby pomagać.

Google

Wyłączenie zabawek Google. Firma ta prezentuje pewną dwumyślność. Z jednej strony chce, by strona działała szybko. Z drugiej strony, sama dostarcza rozwiązania, które fatalnie wpływają na wydajność strony i stwarzają problemy w ich własnym scoringu! Google Analytics – wydajnościowe zło. Fonty Google – kolejne wydajnościowe zło. Google AdSense też drastycznie pogorszy szybkość działania strony.

Rozwiązanie, jeśli nie chcemy całkiem pozbywać się Google? W przypadku AdSense można zrezygnować z wyświetlania reklam wszędzie i ograniczyć ich obecność do wpisów, na których jest największy ruch. Taki kompromis – strony z reklamami będą ładować się dłużej, ale większość stron będzie działać szybko. Oczywiście wiąże się to z rezygnacją z reklam na głównej. Nieco upierdliwe, bo oznacza to ręczne zarządzanie kodem JS odpowiedzialnym za wyświetlanie reklam na poziomie konkretnych wpisów, ale dla mnie OK. Zamiast Google Analytics polecam Matomo. Z fontów Google zrezygnowałem, zamiast tego pewnie można serwować je lokalnie.

Klucz RSA

Kolejna nieoczywista sprawa – rozmiar klucza wykorzystywanego przy SSL/TLS. Miałem podejście security is our priority i klucz RSA o długości 4096 bitów. Tyle tylko, że póki co 2048 bity są także uznawane za bezpieczne. No i na tym blogu nie ma nic wrażliwego. Najbardziej wrażliwe jest hasło, które przesyłam przy logowaniu, więc zmniejszyłem rozmiar klucza i… Pomogło to skrócić czas nawiązywania połączenia z serwerem. Znowu, może kwestia stosunkowo słabego VPSa. Przy tej okazji polecę jeszcze wpis o tym jak zrobić sobie certyfikat SSL/TLS z oceną A+ na nginx.

Jak widać, optymalizacja stron WWW nie jest oczywista i warto do tematu podejść kompleksowo.