Czy maskowanie w CrispGuard odbywa się lokalnie — i czy samo rozszerzenie może ujawnić to, co przechwytujesz?

CrispGuard rysuje swoje maski w przeglądarce: słowa kluczowe stają się paskiem, obrazy blokiem zastępczym, obszary nakładką — i nic z tego nie potrzebuje serwera. Działa jednak na poziomie strony, nie systemu operacyjnego, więc zrzut, który omija renderowanie przeglądarki, może nie zawierać maski. To nie jest produkt bezpieczeństwa i nie szyfruje ekranu.

Co dokładnie CrispGuard potrafi zasłonić, opisuje strona produktu wraz z trzema rodzajami nakładek. Ta strona jest węższa: gdzie odbywa się maskowanie i co ta lokalizacja chroni — a czego nie.

Ścieżka danych CrispGuard: co zostaje w przeglądarce, a co ją opuszcza

Maskowanie działa w skrypcie treści rozszerzenia, czyli w stronie, którą już masz otwartą. Dopasowywanie tekstu, podmiana obrazów i rysowanie nakładek odbywają się podczas lokalnego renderowania. Żaden etap tej ścieżki nie wysyła strony na serwer.

CrispGuard to rozszerzenie Chrome, a częścią, która wykonuje pracę, jest skrypt treści — kod wstrzykiwany przez przeglądarkę do strony, którą oglądasz. Odczytuje teksty i obrazy już obecne w dokumencie, porównuje je z listą słów kluczowych, którą skonfigurowałeś, i przepisuje to, co przeglądarka zaraz narysuje. Dopasowane słowo kluczowe staje się pełnym paskiem, blokiem koloru albo emoji. Dopasowany obraz staje się blokiem zastępczym. Zaznaczony obszar dostaje nakładkę. Strona pod spodem działa dalej: linki prowadzą, formularze się wysyłają, przewijanie nie jest zaburzone.

Każdy z tych kroków to lokalna operacja na dokumencie, który już został pobrany: porównanie odbywa się z listą przechowywaną razem z rozszerzeniem, nie z modelem na serwerze, i żaden etap tej ścieżki nie musi nigdzie wysyłać strony.

To jednak twierdzenie o ścieżce maskowania i warto dokładnie powiedzieć, czego nie obejmuje. „Maskowanie lokalne” i „zero żądań sieciowych” to dwa różne twierdzenia. Drugie jest mocniejsze i sprawdzalne. Ta strona nie podnosi pierwszego do rangi drugiego. Zgodnie z opisem funkcji na stronie sklepu decyzje o maskowaniu i rysowanie odbywają się na twoim urządzeniu. Z czym rozszerzenie rozmawia przez sieć — weryfikacja licencji, cokolwiek innego — określa jego polityka prywatności, i ten dokument trzeba przeczytać przed podjęciem decyzji. Celem projektu jest trzymanie jak największej części danych w przeglądarce; dokładne zachowanie sieciowe to pytanie do polityki prywatności, nie do strony marketingowej.

Sensowne porównanie to produkt, który deklaruje mocniejszą wersję. Polityka prywatności ContextBlur deklaruje 100% lokalnego przetwarzania i zero żądań sieciowych, mówi, że automatyczne rozmycie uruchamia się tylko po kliknięciu „Run auto-blur now”, i że przechowuje selektory CSS, a nie treść strony. Cokolwiek z tego wyciągniesz, ustala coś użytecznego: w tej kategorii „przetwarzane lokalnie” jest deklaracją, którą dostawca może opublikować i za którą można go rozliczyć. To nie jest argument wyłącznie CrispGuard i nie należy go przyjmować na wiarę od żadnego dostawcy, także tego.

Jeszcze jedna granica należy tutaj. Maskowanie zmienia to, co strona wyświetla. Nie szyfruje strony, nie ukrywa jej przed procesami samej przeglądarki i nie powstrzymuje nikogo, kto ma dostęp do twojego odblokowanego komputera, przed otwarciem narzędzi deweloperskich i odczytaniem DOM bezpośrednio. CrispGuard to udogodnienie prywatnościowe do wspólnych przestrzeni, nie produkt bezpieczeństwa, i nie powinien być tak opisywany.

Co dzieje się z maską, gdy robisz zrzut ekranu albo nagrywasz — co obejmuje, a czego nie

Decyduje wyłącznie ścieżka przechwytywania. Jeśli narzędzie czyta wyrenderowaną stronę przeglądarki, maska zwykle jest częścią tego obrazu. Jeśli czyta bufor ramki systemu operacyjnego albo aparat fotografuje ekran, rozszerzenie nie może tam umieścić maski.

Mechanizm wyjaśnia wynik. Rozszerzenie przeglądarki żyje w potoku renderowania strony: edytuje DOM i zastosowane do niego style, a przeglądarka maluje wynik. Narzędzia przechwytujące dzielą się na dwie rodziny. Jedne pytają przeglądarkę, co aktualnie wyświetla — czytają tę samą wyrenderowaną stronę, którą rozszerzenie już zmieniło. Drugie czytają bufor ramki systemu operacyjnego, złożony obraz całego ekranu, i w ogóle nie pytają strony.

Platformy mobilne pokazują, co potrafi druga rodzina, gdy platforma współpracuje. FLAG_SECURE w Androidzie blokuje zrzuty ekranu na warstwie bezpieczeństwa platformy, więc system po prostu odmawia przechwycenia. Rozszerzenia Chrome nie mają odpowiedniej warstwy — nie istnieje API, które pozwoliłoby rozszerzeniu nakazać Windowsowi, macOS-owi albo urządzeniu przechwytującemu odrzucenie ramki.

Maskowanie w CrispGuard to kontrola widoczności na poziomie strony, a nie blokowanie zrzutów ekranu. Jeśli musisz uniemożliwić przechwytywanie na poziomie sprzętowym, użyj mechanizmu bezpiecznego wyświetlania oferowanego przez system operacyjny lub platformę, a nie rozszerzenia przeglądarki.

Wynikają z tego dwie praktyczne konsekwencje. Pierwsza: przyjmuj, że maski nie ma w każdym zrzucie, którego nie przetestowałeś. Druga: test jest tani — zrób jeden zrzut narzędziem, którego naprawdę używasz, na stronie, którą naprawdę zamaskowałeś, i popatrz na wynik.

Jak przechowywany jest PIN blokady witryny — sygnał zaufania, który możesz sprawdzić

PIN blokady witryny jest przechowywany jako hash z solą, nigdy jako czysty tekst. Kto odczyta lokalny magazyn rozszerzenia, dostanie wartość, której nie wpisze w pole odblokowania. Ustawienia pozostają zwykłym interfejsem; PIN jest pytany dopiero przy odblokowaniu.

Blokada witryny to funkcja PRO: pyta o PIN, zanim zdejmie ochronę z zablokowanej witryny. Rozszerzenie przechowuje hash z solą tego PIN-u — PIN przepuszczony przez funkcję jednokierunkową razem z losową wartością — a nie sam PIN. Odczyt lokalnego magazynu nie przekazuje więc gotowego do użycia sekretu. Sól też ma znaczenie: dwie instalacje z tym samym PIN-em tworzą różne wartości, więc dane nie zdradzają, że PIN-y są takie same.

Tę drobną decyzję warto rozważyć, bo jest sprawdzalna. Produkt przechowujący PIN czystym tekstem mówi coś o tym, jak myśli o przechowywaniu; ten, który przechowuje hash, mówi, że zakładał, iż ktoś w końcu ten magazyn odczyta. Żadna z tych decyzji sama nie czyni produktu godnym zaufania, ale w narzędziu siedzącym na każdej otwieranej stronie chcesz widzieć tę drugą.

To, czego hash nie robi, jest równie ważne. Chroni przechowywaną wartość, a nie stan odblokowania: jeśli witryna jest już odblokowana i ktoś stoi za tobą, czyta stronę, nie hash. Krótki numeryczny PIN da się też odgadnąć przy dostatecznej liczbie prób, a hash nic nie mówi o tym, ile prób jest dozwolonych. Hash odpowiada dokładnie na jedno pytanie — czego dowiaduje się atakujący, czytając ten plik — i odpowiada na nie dobrze.

Jeśli zastanawiasz się, czy zaufać rozszerzeniu dbającemu o prywatność ekranu, co powinieneś sprawdzić?

Pięć kontroli rozstrzyga większość: co polityka prywatności mówi o przesyłaniu treści stron, gdzie naprawdę odbywa się maskowanie, o jakie uprawnienia poproszono, czy automatyczne wykrywanie czeka na kliknięcie i czy produkt przyznaje się do swoich ograniczeń.

Żadna nie wymaga wiedzy technicznej. Wymagają przeczytania polityki i listy uprawnień — rozsądny nakład pracy, zanim dasz narzędziu możliwość czytania każdej otwieranej strony.

1. Czy polityka prywatności mówi wprost, że treść stron, zrzuty ekranu i historia przeglądania nie są przesyłane? Polityka, która wymienia te trzy kategorie, składa twierdzenie podlegające obaleniu; ta, która mówi tylko „szanujemy twoją prywatność”, nie — a tego, czego nie da się obalić, nie da się później sprawdzić.
2. Czy maskowanie odbywa się w skrypcie treści lub na poziomie strony, czy treść musi najpierw dotrzeć do serwera? Odpowiedź rozstrzyga, czy „lokalnie” jest właściwością architektury, czy tylko słowem w opisie — i tylko ta pierwsza przetrwa awarię sieci.
3. Czy rozszerzenie prosi o uprawnienia niezwiązane z maskowaniem — schowek, przechwytywanie żądań, dostęp do witryn znacznie wykraczający poza potrzebę? Każde uprawnienie to zdolność, która istnieje niezależnie od tego, czy obecna wersja jej używa, więc lista mówi o tym, co mogłoby się stać, a nie tylko o tym, co się dzieje.
4. Czy automatyczne wykrywanie działa tylko wtedy, gdy je uruchomisz? Funkcja skanująca domyślnie każdą stronę ma inną postawę prywatnościową niż ta, która czeka na kliknięcie, nawet gdy obie dają ten sam efekt na ekranie.
5. Czy produkt nazywa swoje granice („to nie produkt bezpieczeństwa”, „nie zatrzymuje zrzutów na poziomie systemu”), czy obiecuje blokowanie przechwytywania? Dostawca, który nazywa granicę, zwykle zastanawiał się, gdzie ona jest; ten, który obiecuje wszystko, albo się myli, albo coś sprzedaje.

To nie jest karta punktowa i ta strona nie wypełni jej w imieniu CrispGuard. Gdy punktu nie da się potwierdzić w publicznej dokumentacji, traktuj go jako niepotwierdzony i przeczytaj politykę prywatności. To uczciwa wersja odpowiedzi — i jedyna, która pozostaje prawdziwa po kolejnym wydaniu.

Najczęstsze pytania

Czy CrispGuard wysyła treść moich stron na serwer?

Ścieżka maskowania tego nie wymaga. Porównanie odbywa się w skrypcie treści wobec listy słów kluczowych przechowywanej z rozszerzeniem, a podmiana jest rysowana w samej stronie, więc żaden etap tej ścieżki nie wysyła strony. Czy rozszerzenie wykonuje inne żądania sieciowe — na przykład weryfikację licencji — określa jego polityka prywatności, i ten dokument trzeba sprawdzić.

Zrobiłem zrzut narzędziem systemowym — czy maska nadal jest?

Nie jest to gwarantowane. Zrzut systemowy czyta bufor ramki systemu operacyjnego, a rozszerzenie zmienia tylko to, co renderuje przeglądarka, więc obecność maski zależy od ścieżki przechwytywania, a nie od tego, czy jest włączona. Jeśli przechwycenie idzie przez wyrenderowane wyjście przeglądarki, maska zwykle się w nim znajduje.

Czy nagrywarka ekranu uchwyci maskę?

To zależy od trybu przechwytywania nagrywarki. Narzędzia czytające wyrenderowaną stronę lub kompozytor przeglądarki zwykle zawierają nakładkę; narzędzia pobierające ekran na poziomie systemu operacyjnego mogą ją całkowicie ominąć. Żadne ustawienie CrispGuard tego nie zmienia, bo ograniczenie leży w ścieżce przechwytywania, a nie w rozszerzeniu.

Jeśli zapomnę PIN blokady witryny, czy rozszerzenie pokaże go jawnie?

Nie — przechowywany jest tylko hash z solą, więc odczyt lokalnego magazynu rozszerzenia nie ujawnia PIN-u. To chroni to, co zapisane, a nie to, co ktoś może zobaczyć: jeśli witryna jest już odblokowana i ktoś patrzy na twój ekran, PIN nie ma znaczenia.

Czy rozszerzenie dbające o prywatność ekranu zastąpi filtr prywatności?

Nie. Filtr prywatności zawęża kąt widzenia fizycznego ekranu, więc osoba obok w ogóle nie może go odczytać, podczas gdy rozszerzenie zmienia tylko piksele wewnątrz przeglądarki. Filtr zasłania też wszystko na ekranie — inne aplikacje, powiadomienia, rozmowę wideo — a rozszerzenie przeglądarki tam nie sięga. Właśnie to mówi powyższa granica: kontrola na poziomie strony to nie blokowanie zrzutów.

Jeśli naprawdę muszę uniemożliwić zrzuty ekranu, czego powinienem użyć?

Mechanizmu platformy, a nie rozszerzenia przeglądarki. FLAG_SECURE w Androidzie, ścieżki odtwarzania chronione DRM i polityki zarządzanych urządzeń wyłączające przechwytywanie działają na poziomie systemu operacyjnego lub platformy, czyli tam, gdzie zrzut ekranu rzeczywiście przechodzi. W większości sytuacji we wspólnej przestrzeni praktyczną odpowiedzią jest filtr prywatności i odwrócenie ekranu.

← Wszystkie artykuły