7 bezpiecznych dodatków do Firefoksa z otwartym kodem

Dlaczego w ogóle przejmować się bezpieczeństwem dodatków do Firefoksa

Dodatki jak małe programy z szerokimi uprawnieniami

Dodatki do Firefoksa to nie „naklejki” graficzne ani proste skrypty. To pełnoprawne małe programy, które działają wewnątrz przeglądarki i mogą mieć bardzo szerokie uprawnienia. W praktyce oznacza to możliwość:

• czytania i modyfikowania treści na stronach, które odwiedzasz,
• przechwytywania żądań sieciowych (requests) – czyli tego, dokąd łączy się Twoja przeglądarka,
• zapisywania i odczytywania danych w pamięci lokalnej przeglądarki,
• komunikacji z zewnętrznymi serwerami (API, logowanie błędów, telemetria),
• integracji z innymi rozszerzeniami lub funkcjami Firefoksa.

Przeglądarka to dziś główny punkt dostępu do bankowości, poczty, paneli administracyjnych, narzędzi firmowych i mediów społecznościowych. Rozszerzenie mające dostęp do wszystkich stron, które odwiedzasz, ma w praktyce podgląd na ogromną część Twojego życia cyfrowego. W przypadku dobrze napisanych i przejrzystych projektów open source jest to akceptowalne ryzyko, ale przy losowych dodatkach z nieznanego źródła – to proszenie się o kłopoty.

Realne nadużycia: śledzenie, podmiana treści i wycieki danych

W historii dodatków do Firefoksa i innych przeglądarek pojawiały się regularnie sytuacje, w których niepozorne rozszerzenia okazywały się narzędziami do śledzenia lub nadużyć. Typowe scenariusze obejmują:

• agresywne śledzenie – rozszerzenie wstrzykuje do stron własne skrypty, które wysyłają dane o odwiedzanych stronach na zewnętrzny serwer analityczny,
• podmianę treści – reklamy na stronach są podmieniane na inne, należące do „partnerów” autora dodatku (model zarobku ukryty przed użytkownikiem),
• zbieranie wrażliwych danych – pełen dostęp do stron logowania pozwala technicznie przechwycić hasła, kody 2FA lub dane kart (nawet jeśli twórca twierdzi, że tego nie robi),
• kryptokoparki – rozszerzenie wykorzystuje CPU do kopania kryptowalut, gdy przeglądarka jest otwarta (często bez jasnej informacji o tym),
• sprzedaż historii przeglądania – model „darmowy” oparty na handlu danymi użytkowników, czasem ukryty w niejasnej polityce prywatności.

Największy problem polega na tym, że wielu użytkowników nie ma narzędzi ani wiedzy, by samodzielnie zweryfikować, co dokładnie robi dane rozszerzenie. Dlatego tak istotne staje się poleganie na projektach z otwartym kodem, z przejrzystą historią zmian i zaufaną społecznością, ale także stosowanie własnej procedury „mini-audytu”.

Rekomendacje znajomych vs realna weryfikacja

Rozszerzenia przeglądarki często instalowane są na zasadzie: „kolega polecał”, „ktoś pisał na forum”, „wyskoczyło w TOP dodatków”. Taki sposób wyboru bywa wystarczający przy mało wrażliwych narzędziach (np. zmieniających wygląd nowej karty), ale już przy dodatkach ingerujących w treść stron czy sieć – to zdecydowanie za mało.

Rekomendacje zaufanych osób pomagają, ale trzeba mieć świadomość, że:

• mało kto sprawdza kod źródłowy czy historię projektu,
• popularność nie oznacza bezpieczeństwa – kilka razy zdarzało się, że po przejęciu projektu przez nowego właściciela wprowadzano szkodliwe zmiany,
• recenzje w oficjalnym sklepie są mieszanką opinii bardzo technicznych i zupełnie przypadkowych – trzeba je czytać selektywnie.

Zaufanie do dodatku powinno opierać się na kilku warstwach: źródle instalacji, reputacji autora, przejrzystości kodu, historii zachowania oraz własnej, choćby skróconej, analizie żądanych uprawnień i sposobu działania.

Mit „open source = automatycznie bezpieczne”

Kod otwarty to ogromny plus. Umożliwia audyt bezpieczeństwa, łatwiejsze rozwidlanie (forki) i kontrolę społeczności. Jednak traktowanie go jako gwarancji bezpieczeństwa to złudzenie. Nawet w znanych projektach open source zdarzają się poważne luki, a fakt „dostępności kodu” nie oznacza, że ktoś realnie go przeanalizował.

Rzeczywiste korzyści z open source pojawiają się, gdy:

• projekt ma aktywną społeczność i kontrybutorów,
• dodatki są regularnie aktualizowane i łatają znane problemy,
• kod jest publicznie repozytorium (GitHub, GitLab) z przejrzystą historią zmian,
• pojawiają się niezależne recenzje lub audyty bezpieczeństwa.

Bez tego open source staje się dość teoretyczną etykietą. Kod może leżeć latami nienaruszony, a rozszerzenie będzie miało krytyczne dziury. Dopiero połączenie otwartego kodu z żywą społecznością i transparentnym rozwojem daje rozsądny poziom zaufania.

Jak oceniać bezpieczeństwo i jakość dodatku – szybka metoda „5 minut”

Źródło dodatku i podstawowe sygnały ostrzegawcze

Najważniejsza zasada brzmi: instalować dodatki wyłącznie z oficjalnego katalogu Mozilli (addons.mozilla.org – AMO) lub z repozytoriów organizacji, które utrzymują własne, dobrze udokumentowane rozszerzenia i prowadzą do AMO. Bezpośrednie pliki XPI z losowych stron to proszenie się o instalację zmodyfikowanej, zainfekowanej wersji.

Przy wyborze rozszerzenia warto sprawdzić kilka prostych elementów:

• adres strony rozszerzenia – czy to rzeczywiście addons.mozilla.org, bez dziwnych poddomen lub literówek,
• wydawca – nazwisko / nick osoby lub nazwa organizacji; w przypadku znanych projektów (np. uBlock Origin) łatwo to porównać z informacjami z repozytorium,
• opis i zrzuty ekranu – czy wyglądają spójnie, bez rażących błędów językowych, podejrzanie agresywnego marketingu („1000% więcej prywatności!”),
• link do strony domowej – wiele poważnych projektów ma oficjalną stronę lub dokumentację, do której AMO odsyła.

Niepokojące sygnały to m.in. nagła zmiana nazwy dodatku, logo lub wydawcy, zwłaszcza gdy towarzyszy temu skok uprawnień lub brak jasnych informacji o przejęciu projektu. W takim przypadku rozsądniej jest wstrzymać się z aktualizacją, poszukać informacji w społeczności (GitHub, forum Mozilli, Reddit) i ewentualnie przejść na forka utrzymywanego przez społeczność.

Analiza reputacji i aktywności projektu

Szybki przegląd reputacji dodatku w Firefoksie można zrobić w ciągu kilku minut, bez zaawansowanej wiedzy technicznej. Pomagają w tym trzy grupy danych: oceny, aktualizacje oraz aktywność w repozytorium.

• Liczba użytkowników i oceny – rozszerzenie z tysiącami użytkowników i stałymi, dobrymi ocenami jest z reguły mniej ryzykowne niż zupełnie nowe z kilkoma instalacjami. Trzeba jednak czytać recenzje pod kątem konkretnych problemów z prywatnością lub nagłych pogorszeń po update’ach, a nie wyłącznie „działa / nie działa”.
• Data ostatniej aktualizacji – dodatek porzucony kilka lat temu może nie być kompatybilny z aktualnym Firefoksem, ale też może zawierać niezałatane luki bezpieczeństwa. Zbyt częste aktualizacje, bez changeloga, także są warte obserwacji – szczególnie gdy towarzyszy im ciągłe poszerzanie uprawnień.
• Changelog (lista zmian) – przejrzysty opis zmian, zwłaszcza przy wersjach zwiększających uprawnienia, to dobry sygnał. Brak changeloga lub lakoniczne wpisy typu „minor fixes” utrudniają ocenę, co właściwie się zmieniło.

Jeśli projekt jest open source, warto zajrzeć do repozytorium (GitHub, GitLab):

• sprawdzić liczbę kontrybutorów – projekty jednoosobowe nie są złe z definicji, ale trudniej im zapewnić stały audyt i rozwój,
• zobaczyć częstotliwość commitów – brak zmian przez dłuższy czas przy aktywnie rozwijanej przeglądarce może oznaczać porzucenie,
• przejrzeć zakładkę Issues – czy są zgłaszane problemy z prywatnością, i jak szybko autor reaguje.

Nawet użytkownik nietechniczny jest w stanie odróżnić martwe repozytorium od aktywnie rozwijanego projektu. To często wystarcza, by odsiać sporą część potencjalnie problematycznych dodatków.

Uprawnienia i polityka prywatności – szybki filtr ryzyka

Przy instalacji i aktualizacji rozszerzeń Firefox wyświetla listę uprawnień, o które prosi dodatek. Większość osób klika „Dodaj”, nie czytając niczego. To prosty sposób, by oddać rozszerzeniu więcej kontroli, niż jest mu realnie potrzebne.

Podstawowe kroki oceny uprawnień:

• porównanie zakresu działania z listą uprawnień – jeśli dodatek ma tylko zmieniać kolor tła nowej karty, nie potrzebuje odczytu i modyfikacji danych na wszystkich stronach, które odwiedzasz,
• wyczulenie na „Dostęp do danych na wszystkich stronach” – dla niektórych narzędzi (uBlock Origin, NoScript, menedżery haseł) jest to nieuniknione, ale wtedy oczekuje się wyjątkowo przejrzystego kodu i polityki prywatności,
• czy rozszerzenie komunikuje się z serwerem – jeśli tak, powinno to być wyraźnie opisane: po co, jak długo przechowywane są dane, czy są anonimizowane.

Polityka prywatności to kolejny filtr. Nie chodzi o czytanie każdej linijki prawniczego żargonu, ale o wychwycenie kluczowych kwestii:

• czy zbierane są dane o odwiedzanych stronach,
• czy dane są przekazywane podmiotom trzecim (partnerom, reklamodawcom),
• czy użytkownik ma możliwość wyłączenia zbierania danych,
• jak długo są przechowywane i w jakiej formie.

Czerwone flagi to m.in. bardzo ogólne sformułowania („zbieramy pewne informacje w celu ulepszenia usługi”) bez konkretów, brak polityki prywatności przy rozszerzeniach mających pełny dostęp do danych ze stron, a także przenoszenie odpowiedzialności wyłącznie na użytkownika. W takich przypadkach bezpieczniej poszukać alternatywy.

Kryteria wyboru dodatków open source – czego szukać, czego unikać

Licencje open source i co z nich wynika

Nie każdy projekt „dostępny na GitHubie” jest automatycznie open source. O tym decyduje konkretna licencja. Najczęściej spotykane przy rozszerzeniach do Firefoksa to:

• MIT – bardzo liberalna licencja; pozwala na praktycznie dowolne wykorzystanie kodu (w tym w projektach zamkniętych), pod warunkiem zachowania informacji o autorze,
• GPL (np. GPLv3) – licencja copyleft; modyfikacje i projekty pochodne również muszą pozostać open source,
• MPL (Mozilla Public License) – wywodzi się bezpośrednio z ekosystemu Mozilli; wymaga upublicznienia modyfikacji w obrębie plików objętych licencją, ale umożliwia łączenie z kodem na innych licencjach.

Dla użytkownika końcowego licencja nie zmienia codziennego korzystania z dodatku, ale ma znaczenie przy modelu rozwoju. GPL i pokrewne licencje utrudniają przejęcie projektu i zamknięcie go „po cichu”, bo wymuszają utrzymanie otwartości. MIT/MPL ułatwiają z kolei adopcję kodu w innych narzędziach. Kluczowe jest, by licencja była jasno określona, a autor nie zastrzegał sobie praw sprzecznych z koncepcją otwartego oprogramowania.

Audyty społecznościowe i niezależne rekomendacje

Sam fakt, że dodatek jest open source, nie wystarcza. Potrzebna jest choćby szczątkowa forma audytu: przez społeczność, organizacje branżowe lub niezależnych ekspertów. Nie musi to być formalny „pentest” za ogromne pieniądze. Czasem wystarczy:

• ciąg komentarzy na GitHubie, gdzie użytkownicy wskazują potencjalne problemy, a autorzy na nie reagują,
• recenzje na blogach/portalach poświęconych bezpieczeństwu i prywatności (nie reklamowe artykuły sponsorowane),
• obecność na listach rekomendacji organizacji takich jak EFF (Electronic Frontier Foundation) czy w programie Mozilla Recommended Extensions.

Rekomendacja Mozilli w ramach programu „Recommended” oznacza, że rozszerzenie przeszło dodatkową weryfikację, w tym ręczny przegląd kodu i polityki. To nie jest stuprocentowa gwarancja, ale znacząco podnosi poprzeczkę w porównaniu z „zwykłymi” dodatkami.

Jasno określony cel zamiast „kombajnu do wszystkiego”

Rozszerzenia, które „robią wszystko”, rzadko robią wszystko dobrze. Im szerszy zakres funkcji, tym więcej uprawnień, punktów potencjalnych błędów i miejsc, gdzie może pojawić się zbieranie danych „przy okazji”. Bezpieczniej jest używać kilku wyspecjalizowanych dodatków niż jednego „magicznego pakietu bezpieczeństwa”.

Praktyczny filtr: opis rozszerzenia powinien jasno odpowiadać na pytanie: do czego to służy? Jeżeli pojawia się marketingowa papka („zwiększa bezpieczeństwo, przyspiesza internet, optymalizuje pracę przeglądarki, blokuje wirusy i zapewnia prywatność”), zwykle kryje się za tym albo przesada, albo zbyt szeroki zakres ingerencji w przeglądarkę.

Zazwyczaj bezpieczniejszy jest dodatek, który:

• ma 1–2 główne funkcje opisane konkretnym językiem,
• posiada konfigurowalne opcje, ale nie próbuje dublować funkcji innych, uznanych rozszerzeń (np. własny menedżer haseł w dodatku do notatek),
• nie wymaga uprawnień znacznie wykraczających poza deklarowany cel.

Łączenie zadań ma sens w pewnych granicach (np. blokada reklam + filtr antytrackingowy w jednym dodatku), ale „antywirus w przeglądarce”, który przy okazji manipuluje wynikami wyszukiwania i wstrzykuje własne reklamy, to klasyczny przykład rozwiązań, których lepiej unikać.

Konsekwencja w rozwoju i komunikacji z użytkownikami

Bezpieczeństwo addonów open source to nie jednorazowa decyzja, lecz ciągły proces. Projekty, które traktują użytkowników poważnie, mają kilka wspólnych cech:

• czytelny changelog przy każdej większej wersji, najlepiej linkowany z AMO,
• informowanie o zmianach uprawnień – np. wpis w changelogu: „dodano dostęp do kart z powodu funkcji X, szczegóły w issue #123”,
• reagowanie na zgłoszenia – nawet krótkie „sprawdzimy to” jest lepsze niż lata ciszy przy otwartych zgłoszeniach.

Dobrym znakiem jest też jasna polityka dotycząca monetyzacji. Jeśli autor musi zarabiać na czasie poświęconym projektowi (patronite, sponsorzy GitHub, opcjonalne darowizny) i robi to wprost, najczęściej jest to zdrowszy model niż „darmowy” dodatek utrzymujący się z niejasnego zbierania danych analitycznych.

uBlock Origin – otwarty standard ochrony przed reklamami i trackerami

Dlaczego właśnie uBlock Origin, a nie „jakiś adblock”

Blokery reklam to szczególnie wrażliwa kategoria dodatków: widzą praktycznie cały ruch HTTP, mogą manipulować zawartością stron i często mają pełny dostęp do zakładek i historii. Wybór pierwszego z brzegu „adblocka” z ładną ikonką jest prostym sposobem na oddanie komuś bardzo szerokiej kontroli nad tym, co przeglądarka ładuje.

uBlock Origin wyróżnia się na tle innych rozwiązań kilkoma elementami:

• jest projektem non-profit – autor konsekwentnie odcina się od płatnych „białych list” reklam i podobnych układów biznesowych,
• kod jest w pełni otwarty i od lat poddawany intensywnemu audytowi społeczności,
• stosuje własny, wydajny silnik filtrów, który przy rozsądnej konfiguracji ma mniejszy narzut na zasoby niż wiele konkurencyjnych dodatków,
• ma status Mozilla Recommended, co oznacza dodatkowe przeglądy kodu po stronie Mozilli.

Na AMO istnieje kilka rozszerzeń o podobnych nazwach („uBlock”, „uBlocker” itd.). Warto zwrócić uwagę, aby instalować „uBlock Origin” autorstwa Raymond Hill (gorhill), a nie klony bazujące na starym kodzie lub z niejasnymi modyfikacjami.

Model działania: filtry zamiast „magii”

uBlock Origin nie „zgaduje”, co jest reklamą, lecz opiera się na zestawach filtrów – listach reguł tworzonych przez społeczność (EasyList, EasyPrivacy, polskie listy antyreklamowe i inne). Dodatek porównuje każdy element ładowanej strony (żądania sieciowe, skrypty, ramki iframe) z tymi listami i blokuje pasujące wpisy.

Konsekwencją takiego podejścia jest pełna przejrzystość: można sprawdzić, które listy są włączone, podejrzeć pojedyncze reguły, a nawet dodać własne. Nie ma tu „inteligentnego” profilowania użytkownika ani wysyłania danych o stronach do zewnętrznego serwera w celu analizy. Działa to lokalnie, w przeglądarce.

Dla użytkownika nietechnicznego domyślne ustawienia są zwykle wystarczające. Bardziej zaawansowani mogą korzystać z trybu zaawansowanego z siatką (matrix), który pozwala blokować skrypty i żądania z konkretnych domen na poszczególnych stronach. To narzędzie potężne, ale wymaga odrobiny cierpliwości – w zamian zapewnia wyjątkowo precyzyjną kontrolę nad tym, co się ładuje.

Prywatność i minimalizacja danych

uBlock Origin nie działa w modelu „zaufaj nam, wiemy co robimy”, tylko pokazuje mechanikę wprost. Kilka praktycznych aspektów:

• brak telemetrii – rozszerzenie nie wysyła statystyk użycia do autora; aktualizacja list filtrów odbywa się przez pobieranie statycznych plików z serwerów projektów list,
• brak „akceptowanych reklam” domyślnie – w przeciwieństwie do części konkurencyjnych rozwiązań, które przepuszczają wybrane reklamy w ramach programów partnerskich,
• możliwość eksportu/ importu konfiguracji – ustawienia (w tym własne reguły) można łatwo przenieść między profilami lub urządzeniami, bez konieczności logowania do jakiejkolwiek usługi w chmurze.

Dla osób szczególnie wrażliwych na prywatność dobrym kompromisem jest połączenie uBlock Origin z odrębnym narzędziem do zarządzania skryptami (np. NoScript lub obejściami opartymi na politykach Firefoksa) i minimalizowanie liczby innych dodatków, które mają dostęp do treści stron.

Przykładowa bezpieczna konfiguracja uBlock Origin

W praktyce wiele osób instaluje uBlock Origin i nie zagląda do opcji. Domyślne ustawienia są rozsądne, ale kilka prostych kroków potrafi wyraźnie podnieść poziom ochrony, bez rozbijania większości stron:

1. W zakładce „Filtry zewnętrzne” aktywować sprawdzone listy regionalne (np. polskie listy antyreklamowe i antytrackingowe), zamiast instalować oddzielne dodatki tylko dla danego kraju.
2. Rozważyć włączenie list nastawionych na prywatność (np. EasyPrivacy), tak aby blokować nie tylko banery, ale też trackery analityczne. Trzeba liczyć się z tym, że niektóre strony wymagają wtedy ręcznego dodania wyjątków.
3. Zabezpieczyć się przed przypadkową utratą ustawień – raz skonfigurowany profil warto wyeksportować do pliku i trzymać w bezpiecznym miejscu.

Osoby mniej techniczne mogą pozostać przy profilu domyślnym, ale sensownie jest chociaż raz przejrzeć listy filtrów i odznaczyć wszystko, co wydaje się niepotrzebne (np. filtry dla egzotycznych języków, których się nie używa).

Firefox Multi-Account Containers – kontenery zamiast dwudziestu przeglądarek

Na czym polegają kontenery i co realnie dają

Firefox Multi-Account Containers to oficjalne rozszerzenie Mozilli, które wprowadza koncepcję kontenerów – odseparowanych przestrzeni ciasteczek i danych stron w obrębie jednej przeglądarki. Każda karta może należeć do określonego kontenera (np. „Praca”, „Prywatne”, „Bankowość”, „Social”) i ma osobny zestaw:

• ciasteczek,
• danych logowania,
• danych lokalnych przechowywanych przez przeglądarkę (localStorage itp.).

Efekt jest podobny jak używanie kilku profili Firefoksa lub kilku przeglądarek, ale w wygodniejszej formie: jedna instancja, różne „światy” odseparowane na poziomie sesji. Dzięki temu:

• można być zalogowanym na to samo serwisu w kilku kontach naraz (np. dwa konta w tej samej poczcie),
• serwisy społecznościowe trudniej łączą aktywność między kontenerami (np. Facebook w kontenerze „Social” ma utrudnione śledzenie aktywności z kontenera „Zakupy”),
• zadania służbowe i prywatne są od siebie technicznie oddzielone – przypadkowe kliknięcie w link z maila służbowego nie zaciąga od razu całej historii prywatnego surfowania.

Bezpieczeństwo a wygoda – gdzie są granice kontenerów

Kontenery nie są „piaskownicą bezpieczeństwa” w sensie systemowym. Nie chronią przed złośliwym kodem wtyczek ani przed lukami w samym silniku przeglądarki. Ich rola jest inna: separacja tożsamości i sesji, a nie pełna izolacja procesów.

Mają jednak kilka wymiernych skutków z punktu widzenia prywatności:

• ciasteczka śledzące z jednego kontenera nie działają w innych, co zmniejsza powierzchnię profilowania,
• jeśli do określonych serwisów (np. bankowości) przydzieli się osobny kontener, można znacznie ograniczyć liczbę dodatków instalowanych dla tego środowiska,
• łatwiej uniknąć „przecieków kontekstu” – np. kliknięcia w link z prywatnego maila podczas pracy służbowej.

Nadal pozostają jednak mechanizmy fingerprintingu (np. rozdzielczość ekranu, czcionki, parametry przeglądarki), których same kontenery nie eliminują. Dlatego rozsądnie jest łączyć je z innymi narzędziami ograniczającymi ten typ identyfikacji (np. wbudowane w Firefoksa ustawienia „Wzmocniona ochrona przed śledzeniem”, a dopiero potem dodatkowe dodatki, jeśli to konieczne).

Konfiguracja kontenerów w praktyce

Podstawowe użycie Multi-Account Containers nie wymaga skomplikowanej konfiguracji, ale kilka prostych zasad czyni je znacznie skuteczniejszym narzędziem.

Jedna z sensownych strategii to podział na 3–5 podstawowych profili:

• „Praca” – wszystkie narzędzia służbowe, poczta firmowa, komunikatory, panele administracyjne,
• „Prywatne” – poczta prywatna, portale informacyjne, fora,
• „Social” – media społecznościowe, komunikatory konsumenckie,
• „Bankowość / Finanse” – banki, kantor, giełdy; najlepiej jak najmniej dodatków aktywnych w tym kontenerze,
• „Zakupy” – sklepy i porównywarki, szczególnie te agresywnie śledzące.

Multi-Account Containers umożliwia przypisywanie domen do konkretnego kontenera. Po skonfigurowaniu, wejście na określony adres (np. facebook.com) zawsze otworzy się w dedykowanym kontenerze. Ogranicza to liczbę „pomyłek” i przypadkowe mieszanie kontekstów.

Połączenie z innymi narzędziami – kiedy to ma sens

Kontenery zyskują na sile, gdy powiąże się je z rozsądną polityką dodatków i ciasteczek. Przykładowe praktyczne połączenia:

• w kontenerze „Bankowość” pozostawia się wyłącznie podstawowe, zaufane dodatki (np. uBlock Origin), wyłączając wszelkie zbędne rozszerzenia, które mogłyby mieć dostęp do formularzy lub zawartości strony,
• w kontenerze „Social” można zezwolić na niektóre skrypty wymagane do działania serwisów społecznościowych, jednocześnie blokując je w innych kontenerach (np. przez uBlock Origin),
• w połączeniu z rozszerzeniem typu Temporary Containers (dla bardziej zaawansowanych użytkowników) można wymusić otwieranie większości anonimowych linków w tymczasowych kontenerach, które są usuwane po zamknięciu kart.

W firmowym środowisku kontenery pozwalają też lepiej oddzielić loginy administracyjne od zwykłych użytkowych. Administrator może mieć osobny kontener tylko dla kont z podwyższonymi uprawnieniami i używać go wyłącznie do konkretnych zadań, co zmniejsza ryzyko przypadkowego wykonania ryzykownych operacji „nie tym kontem”.

Ograniczenia i typowe nieporozumienia

Kontenery bywają przeceniane. Kilka rzeczy, których nie robi Firefox Multi-Account Containers:

• nie szyfruje dodatkowo ruchu – za to odpowiada protokół HTTPS i ewentualnie VPN/Tor,
• nie zastępuje oddzielnych profili Firefoksa w sytuacjach, gdy wymagana jest naprawdę twarda izolacja (np. testowanie potencjalnie złośliwych stron),
• nie chroni przed złośliwym dodatkiem, który ma dostęp do wszystkich kart we wszystkich kontenerach.

Bitwarden – menedżer haseł, który da się zweryfikować

Dlaczego menedżer haseł w ogóle jako dodatek do przeglądarki

Menedżery haseł są jednym z najbardziej wrażliwych typów rozszerzeń. Mają dostęp do pól logowania, często do całej treści stron, a do tego przechowują klucze do naszego cyfrowego życia. Jeśli coś ma być audytowalne i przewidywalne, to właśnie one.

Bitwarden jest przykładem projektu, który łączy otwarte komponenty z modelem SaaS. Kod klienta (w tym dodatek do Firefoksa) jest publicznie dostępny, a komunikacja z serwerem odbywa się na podstawie opublikowanego protokołu. To istotne z kilku powodów:

• można przeanalizować sposób szyfrowania i logikę po stronie klienta (co dokładnie dzieje się w przeglądarce),
• istnieją niezależne audyty bezpieczeństwa, do których da się sięgnąć zamiast ufać marketingowi,
• pojawiające się luki są szybciej wyłapywane przez społeczność, która faktycznie ma do czego zajrzeć.

Nie oznacza to automatycznie, że Bitwarden jest „idealny”. Otwarty kod eliminuje jedną kategorię ryzyka (ukryte funkcje, backdoory), ale nie zastępuje zdrowego rozsądku: nadal trzeba patrzeć na model biznesowy, transparentność komunikacji i tempo łatania błędów.

Model bezpieczeństwa i gdzie faktycznie leżą granice zaufania

Bitwarden stosuje model „zero-knowledge” – serwer nie powinien mieć dostępu do treści sejfu haseł. Szyfrowanie odbywa się lokalnie u użytkownika, a do chmury trafiają zaszyfrowane blob-y danych. Weryfikując rozszerzenie, warto sprawdzić kilka elementów:

• jak generowany jest klucz główny (master key) i czy można skonfigurować sensowną politykę hasła głównego,
• jak wygląda integracja z przeglądarką – czy dodatek wymaga uprawnień do wszystkich stron, czy korzysta z mechanizmów auto-uzupełniania w sposób kontrolowalny,
• jak rozwiązano logowanie biometryczne (jeśli jest używane) i czy przypadkiem nie zamienia się ono w wygodny, ale słaby punkt.

Kluczowy punkt: w przypadku menedżera haseł zawsze istnieje poziom zaufania do infrastruktury serwera i procesów wewnętrznych firmy, bo nie wszystko da się wyczytać z repozytorium Git. Otwartość klienta utrudnia wprowadzenie cichych zmian po stronie przeglądarki, ale nie daje pełnej kontroli nad środowiskiem serwerowym.

Bezpieczne użycie Bitwardena w Firefoksie

Kilka praktycznych zasad ogranicza ryzyko, bez utrudniania sobie życia bardziej niż to konieczne:

• rozsądna długość i złożoność hasła głównego – bez tego całe szyfrowanie traci sens; passphrase z kilku losowych słów jest zwykle lepsza niż „kreatywne” zastępowanie liter cyframi,
• wyłączenie automatycznego logowania do sejfu – ręczne odblokowanie po starcie przeglądarki kosztuje kilka sekund, a ogranicza skutki kradzieży sesji lub fizycznego dostępu do komputera,
• ostrożne używanie auto-uzupełniania – lepiej wymusić kliknięcie w ikonę Bitwardena w polu hasła niż pozwolić na automatyczne wypełnianie wszystkiego wszędzie,
• segmentacja przy użyciu kontenerów – w kontenerze „Bankowość” można mieć Bitwardena odblokowanego tylko na czas konkretnych operacji, zamiast trzymać sejf stale otwarty dla wszystkich kart.

Bitwarden pozwala również na własny serwer (self-hosted). To sensowna opcja dopiero wtedy, gdy ktoś faktycznie ma zasoby, aby taki serwer aktualizować, monitorować i twardo zabezpieczyć. W przeciwnym razie ryzyko „zrób to sam” bywa większe niż korzystanie z dobrze utrzymanej instancji chmurowej.

Decentraleyes – lokalne zasoby zamiast zewnętrznych CDN

Jak działa „odcinanie” od popularnych CDN-ów

Wiele stron korzysta z tzw. publicznych CDN-ów (Content Delivery Network) do ładowania popularnych bibliotek JavaScript, takich jak jQuery, React czy moment.js. Dla wydajności to wygodne, ale z punktu widzenia prywatności oznacza przekazywanie metadanych o każdej wizycie do podmiotów trzecich.

Decentraleyes działa w prosty sposób: przechwytuje żądania do wybranych znanych CDN-ów i podstawia lokalną kopię biblioteki. Strona myśli, że pobrała skrypt z zewnętrznego serwera, a w rzeczywistości nic do niego nie poleciało.

Podstawowe korzyści:

• mniej zewnętrznych połączeń przy ładowaniu stron,
• ograniczenie pasywnego śledzenia przez infrastrukturę CDN,
• czasami szybsze ładowanie stron, bo skrypty biorą się z lokalnego magazynu dodatku.

Ograniczenia i realistyczne oczekiwania

Zasięg działania Decentraleyes jest z natury ograniczony. Obsługuje jedynie te biblioteki i adresy, które ma wpisane na listę. Nowe CDN-y i niestandardowe ścieżki nie będą automatycznie przechwytywane.

Do tego dochodzi kilka typowych nieporozumień:

• Decentraleyes nie zastępuje klasycznego blokera reklam czy narzędzi antytrackingowych,
• nie ukrywa adresu IP przed właścicielem odwiedzanej strony – zastępuje tylko zewnętrzne połączenia do CDN-ów,
• może wchodzić w konflikt z filtrami w uBlock Origin, jeśli obie wtyczki próbują modyfikować te same żądania.

W praktyce najlepiej sprawdza się w konfiguracji, w której uBlock Origin kontroluje ogólny ruch, a Decentraleyes uzupełnia go o lokalne podmiany konkretnych bibliotek. Przy problemach z działaniem niektórych stron warto przetestować, co się dzieje po czasowym wyłączeniu jednego z tych narzędzi – diagnoza „na czuja” często prowadzi do błędnych wniosków.

Konfiguracja minimalna i kiedy w ogóle ma sens instalacja

Decentraleyes po instalacji działa domyślnie w sposób dość bezobsługowy. Z punktu widzenia bezpieczeństwa i prywatności wystarczy kilka decyzji:

• zostawić domyślną listę obsługiwanych CDN-ów,
• włączyć logowanie żądań tylko na czas diagnozowania problemów (ciągłe logowanie bywa nadmierne i mało potrzebne),
• ustawić w uBlock Origin wyjątki dla żądań, które Decentraleyes ma przechwytywać, jeśli pojawią się konflikty.

Dodatek ma sens głównie w przypadku osób, które nie korzystają z mocno „pancernej” konfiguracji (np. Tor Browser) i chcą po cichu zredukować ilość pasywnego śledzenia, nie rozbijając przy tym stron zależnych od zewnętrznych bibliotek. W środowiskach już mocno zablokowanych (dużo agresywnych filtrów, NoScript itp.) przyrost korzyści może być marginalny.

ClearURLs – czyszczenie adresów z „śmieci śledzących”

Na czym polega usuwanie parametrów śledzących

Wiele linków zawiera całe tasiemce parametrów – od utm_source po rozbudowane identyfikatory kampanii i kliknięć. Część z nich jest wykorzystywana wyłącznie do analityki i profilowania, a dla użytkownika nie ma żadnej wartości. ClearURLs automatycznie usuwa znane parametry śledzące z adresów URL przed ich wysłaniem.

Mechanizm jest prosty, ale dość skuteczny:

• dodatek posiada listę wzorców (reguł), które opisują niechciane parametry dla różnych serwisów,
• przed otwarciem linku modyfikuje go, usuwając zbędne elementy,
• w logach można później podejrzeć, co zostało obcięte i gdzie.

Efekt uboczny jest pozytywny: skracają się również adresy, co ułatwia ich kopiowanie czy zapisywanie w notatkach bez generowania nieczytelnych potworków.

Korzyści z perspektywy prywatności i bezpieczeństwa

ClearURLs nie jest narzędziem „twardego bezpieczeństwa”, ale domyka pewną lukę, której zwykłe blokery reklam nie zawsze dotykają:

• ogranicza możliwość śledzenia użytkownika między różnymi kampaniami i kanałami marketingowymi,
• utrudnia powiązanie kliknięcia w link (np. z newslettera) z konkretną sesją przeglądania,
• w niektórych przypadkach redukuje też „wylewanie się” wrażliwych informacji w logach serwerów pośredniczących, jeśli parametry zawierają elementy identyfikujące.

Warto jednak mieć świadomość, że część serwisów opiera się na parametrach w sposób uzasadniony technicznie (np. linki jednorazowe). ClearURLs próbuje to uwzględniać w regułach, ale nie da się zagwarantować braku incydentalnych problemów.

Typowe problemy i jak je diagnozować

Czasami po kliknięciu w link po „oczyszczeniu” użytkownik trafia nie tam, gdzie się spodziewał, albo serwis odmawia działania. W takiej sytuacji podejście krok po kroku jest sensowniejsze niż dramatyczne wnioski o „psuciu internetu przez dodatki”:

1. W logach ClearURLs sprawdzić, które parametry zostały usunięte.
2. Spróbować otworzyć ten sam link z dodatkiem tymczasowo wyłączonym.
3. Jeśli problem znika, rozważyć dodanie wyjątku dla danego serwisu lub zgłoszenie błędu autorom reguł.

Rozsądne jest połączenie ClearURLs z kontenerami: np. ruch do narzędzi analitycznych lub marketingowych trzymać w osobnym kontenerze, a w kontenerze „prywatnym” agresywniej czyścić linki. Nie każdy potrzebuje tej samej równowagi między wygodą (działające linki śledzące w kampaniach) a prywatnością.

Cookie AutoDelete – automatyczne sprzątanie po sesjach

Dlaczego samo „blokuj ciasteczka” to za mało

Ręczne zarządzanie ciasteczkami w przeglądarce jest w praktyce niewykonalne. Strony używają ich w różnych celach – od sesji logowania po przechowywanie preferencji. Całkowite blokowanie kończy się często niedziałającymi formularzami i wymuszonym logowaniem przy każdej akcji.

Cookie AutoDelete proponuje inne podejście: pozwala na ciasteczka, ale sprząta je automatycznie, gdy karta z daną domeną zostanie zamknięta (chyba że domena jest na białej liście). To kompromis pomiędzy wygodą a kontrolą nad śladami, które przeglądarka zostawia.

Jak działa automatyczne usuwanie i na co uważać

Logika Cookie AutoDelete opiera się na kilku prostych zasadach:

• dla domen na „białej liście” ciasteczka pozostają,
• dla pozostałych są usuwane po zamknięciu ostatniej karty, która odwoływała się do tej domeny,
• można dodatkowo czyścić pamięć lokalną (localStorage) i inne mechanizmy przechowywania danych.

To działa zaskakująco dobrze, ale tylko jeśli użytkownik jest w stanie utrzymać rozsądną listę wyjątków. Przykład z praktyki: ktoś dodaje na białą listę pocztę i bank, ale zapomina o serwisie do uwierzytelniania wieloskładnikowego, przez co co chwilę musi przechodzić cały proces logowania od zera. Frustracja szybko prowadzi do wyłączania dodatku.

Dobrym nawykiem jest zaczęcie od trybu „manualnego”, w którym Cookie AutoDelete jedynie podpowiada, co mogłoby zostać usunięte, zamiast robić to automatycznie. Po kilku dniach widać, które domeny rzeczywiście wymagają trwałych ciasteczek, a które są wyłącznie „wszędobylskimi trackerami”.

Integracja z kontenerami i innymi dodatkami

Cookie AutoDelete współpracuje z Multi-Account Containers, ale trzeba mieć świadomość, z którego poziomu kontroluje się politykę ciasteczek:

• w niektórych scenariuszach lepiej dopuścić ciasteczka w konkretnym kontenerze (np. „Praca”), ale agresywnie je czyścić w „Zakupach” i „Social”,
• uBlock Origin może blokować część skryptów odpowiedzialnych za śledzenie, co zmniejsza ilość „śmieci” do sprzątnięcia i upraszcza konfigurację Cookie AutoDelete,
• kombinacja z ClearURLs dodatkowo ogranicza zakres parametrów, które w ogóle zamieniają się w ciasteczka lub dane lokalne.

Jeśli w konfiguracji pojawiają się tajemnicze „wylogowania znikąd”, pierwszym podejrzanym jest zwykle właśnie nadgorliwe czyszczenie ciasteczek lub pamięci lokalnej. Diagnostyka polega wtedy na czasowym zablokowaniu automatycznego usuwania i obserwacji, czy problem ustępuje.

LocalCDN – rozszerzona osłona przed zewnętrznymi zależnościami

Rozszerzenie idei Decentraleyes

LocalCDN idzie krok dalej niż Decentraleyes. Zamiast skupiać się na kilku znanych bibliotekach, stara się przechwytywać możliwie wiele zewnętrznych zasobów (JS, CSS, czcionki) z popularnych CDN-ów i serwować je lokalnie z dodatku.

W założeniu:

• zmniejsza liczbę połączeń do podmiotów trzecich,

Opracowano na podstawie

• Firefox Extension Workshop: Browser Extensions. Mozilla – Oficjalna dokumentacja tworzenia dodatków i ich uprawnień
• Firefox Add-ons Policies. Mozilla – Zasady dotyczące dodatków, w tym bezpieczeństwa i prywatności
• uBlock Origin – project documentation. uBlock Origin Project – Przykład znanego dodatku open source, repozytorium i praktyki bezpieczeństwa
• OWASP Top 10 Privacy Risks for Web Applications. OWASP – Ryzyka prywatności związane z aplikacjami webowymi i skryptami
• NIST Special Publication 800-53: Security and Privacy Controls. NIST – Kontrole bezpieczeństwa i prywatności istotne dla oprogramowania klienckiego
• ENISA Threat Landscape for Browser Extensions. ENISA – Analiza zagrożeń związanych z rozszerzeniami przeglądarek
• Google Chrome Web Store: Developer Program Policies. Google – Polityki dla rozszerzeń, przykłady nadużyć i wymogów prywatności