Wprowadzenie do problemu / definicja luki
Google rozwija w Chrome dodatkową warstwę ochrony przed oszustwami (scamami) w ramach Safe Browsing → Enhanced Protection. Kluczowym elementem stał się lokalny (on-device) model AI, który ma szybciej rozpoznawać podejrzane strony i zachowania — w tym takie, które „żyją” zaledwie kilka minut i nie zdążą trafić na klasyczne listy blokad.
Nowość opisana 17 stycznia 2026 r. dotyczy kontroli użytkownika: w Chrome pojawiła się opcja pozwalająca wyłączyć „On-device GenAI” i tym samym usunąć lokalne modele AI wykorzystywane m.in. do mechanizmów anty-scam w Enhanced Protection (na razie w kanale Canary).
W skrócie
- W Chrome (Canary) dodano przełącznik Settings → System → “On-device GenAI”, który pozwala wyłączyć i usunąć lokalny model AI używany przez Enhanced Protection.
- Ochrona anty-scam w Chrome korzysta z podejścia on-device (Gemini Nano) do wyciągania sygnałów bezpieczeństwa ze strony, po czym Safe Browsing może wystawić „ostateczny werdykt”.
- Funkcja (i wysyłanie streszczonych sygnałów) działa dla użytkowników, którzy świadomie włączyli Enhanced Protection.
- W środowiskach firmowych poziom Safe Browsing można kontrolować polityką SafeBrowsingProtectionLevel.
Kontekst / historia / powiązania
- Enhanced Protection istnieje od lat jako „mocniejszy” tryb Safe Browsing, ale w 2025 r. został istotnie rozbudowany o komponenty AI do ochrony „w czasie rzeczywistym”, szczególnie przeciw scamom typu tech support scam (fałszywe alerty o wirusach, blokowanie wyjścia ze strony, wymuszanie kontaktu telefonicznego itd.).
- Google opisywało, iż dzięki analizie on-device można reagować na zagrożenia szybciej — m.in. dlatego, iż przeciętnie złośliwa strona potrafi istnieć bardzo krótko (rzędu minut).
- Równolegle Google rozwija „wbudowane AI” w Chrome (Gemini Nano), poszerzając kompatybilność sprzętową (np. wsparcie inferencji także na CPU w wybranych konfiguracjach).
Analiza techniczna / szczegóły luki
Jak działa anty-scam z modelem on-device
Z perspektywy architektury bezpieczeństwa Chrome wygląda to (w uproszczeniu) tak:
- Trigger / sygnał uruchamiający: Chrome obserwuje zachowania typowe dla tech support scam (np. użycie Keyboard Lock API do utrudnienia zamknięcia karty/ucieczki).
- Analiza lokalna (on-device): treść bieżącej strony jest oceniana przez Gemini Nano w celu wyciągnięcia sygnałów bezpieczeństwa (np. „intencja strony”, wzorce socjotechniczne).
- Werdykt Safe Browsing: streszczone sygnały trafiają do Safe Browsing, który podejmuje decyzję o ostrzeżeniu/interstitialu.
- Ograniczenia wydajności i prywatności: Google deklaruje mechanizmy ograniczające koszty (rzadkie uruchamianie, limity, throttling, kontrola zasobów), a wysyłanie sygnałów ma dotyczyć użytkowników, którzy opt-in w Enhanced Protection.
Co zmienia przełącznik „On-device GenAI”
Według opisu BleepingComputer, aby usunąć lokalny model AI, użytkownik ma wejść w:
Chrome → Settings → System → wyłączyć “On-device GenAI”.
Ważne: wygląda na to, iż „On-device GenAI” może docelowo zasilać więcej funkcji niż tylko scam detection, więc wyłączenie może mieć szerszy wpływ na przyszłe mechanizmy bezpieczeństwa/AI w Chrome.
Kontekst enterprise / Android
W notatkach dla Chrome Enterprise pojawia się opis, iż np. w Chrome 145 na Androidzie wykrycie scam „on-device” może skutkować zapytaniem do Safe Browsing o końcowy werdykt, a funkcja ma być aktywna tylko przy Enhanced Protection; administratorzy mogą sterować poziomem ochrony polityką.
Praktyczne konsekwencje / ryzyko
Dla użytkowników indywidualnych
- Wyłączenie/usuń model może oznaczać utratę dodatkowej warstwy ochrony przed scamami, zwłaszcza tymi gwałtownie zmieniającymi domeny i treści (typowe dla kampanii krótkotrwałych). Logika on-device była właśnie odpowiedzią na ten problem.
- Pojawia się „trade-off” kontrola i zasoby vs. bezpieczeństwo: niektórzy będą chcieli ograniczyć lokalne AI (np. zasoby, polityka prywatności), ale trzeba to świadomie zbilansować z ryzykiem.
Dla organizacji (IT/SOC)
- Jeśli pracownicy mogą samodzielnie wyłączać komponent on-device, rośnie znaczenie:
- standaryzacji ustawień Safe Browsing,
- monitoringu zgodności,
- oraz edukacji o skutkach „odchudzania” ochrony w przeglądarce.
- W środowiskach enterprise warto traktować przeglądarkę jak element kontroli dostępu do SaaS, a nie tylko „aplikację użytkownika” — szczególnie gdy scam pages próbują wymuszać działania (płatności, zdalny dostęp, instalacje).
Rekomendacje operacyjne / co zrobić teraz
Dla zespołów bezpieczeństwa (firmy)
- Wymuś poziom ochrony Safe Browsing tam, gdzie to uzasadnione ryzykiem (np. grupy o podwyższonej ekspozycji: finanse, HR, support). W ekosystemie Chrome Enterprise kluczowa jest polityka SafeBrowsingProtectionLevel.
- Zdefiniuj politykę dot. funkcji AI w przeglądarce: czy dopuszczasz on-device AI w ramach ochrony (zwykle tak), czy wymagasz określonych ustawień — i dlaczego.
- Komunikacja do użytkowników: krótka instrukcja „co daje Enhanced Protection” i jakie są skutki wyłączania „On-device GenAI” (mniej ochrony przed scamami).
- Testy kompatybilności i wpływu: jeżeli organizacja wykorzystuje kanały Canary/Dev do testów, sprawdź, czy przełącznik nie wpływa na inne elementy (bo według obserwacji może dotyczyć szerszego zestawu funkcji).
Dla użytkowników indywidualnych
- Jeśli zależy Ci na ochronie anty-scam: upewnij się, iż masz włączone Safe Browsing → Enhanced Protection, a wyłączanie „On-device GenAI” rób tylko świadomie (np. do testów). Mechanizm AI był projektowany do wykrywania m.in. technik wymuszających działania na stronie.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Enhanced Protection vs Standard Protection
- Enhanced Protection: dodatkowe sygnały i mechanizmy, w tym warstwa AI on-device oraz przesyłanie streszczonych sygnałów do Safe Browsing (opt-in).
- Standard Protection: bardziej „klasyczny” model ochrony; użytkownicy mogą korzystać pośrednio, bo nowe zidentyfikowane domeny/scamy trafiają potem na bloklisty.
On-device AI vs klasyczne bloklisty
- On-device AI ma wykrywać „wzorce i intencje” choćby wtedy, gdy domena/kreacja jest nowa.
- Bloklisty są skuteczne, ale wymagają czasu w obserwację, klasyfikację i dystrybucję — co przy „życiu” stron scam bywa zbyt wolne.
Podsumowanie / najważniejsze wnioski
Dodanie w Chrome opcji wyłączenia „On-device GenAI” to sygnał większej transparentności i kontroli użytkownika nad lokalnymi modelami AI — ale jednocześnie otwiera dyskusję o tym, czy i gdzie warto wyłączać warstwy ochronne.
Dla bezpieczeństwa praktyczny wniosek jest prosty: jeżeli Enhanced Protection ma realnie łapać krótkotrwałe scamy, to usunięcie lokalnego modelu AI może osłabić ten scenariusz ochrony. W organizacjach warto przygotować polityki i komunikację, zanim funkcja trafi szerzej ze środowisk testowych do stabilnych wydań.
Źródła / bibliografia
- BleepingComputer – „Google Chrome now lets you turn off on-device AI model powering scam detection” (17 stycznia 2026). (BleepingComputer)
- Google Online Security Blog – „Using AI to stop tech support scams in Chrome” (8 maja 2025). (Google Online Security Blog)
- Chrome Enterprise and Education release notes – wzmianka o „On-device scam detection on Android” i kontroli polityką. (Google Help)
- Malwarebytes – omówienie wdrożenia Gemini Nano w Chrome 137 i kontekstu tech support scams. (Malwarebytes)
- Chrome for Developers – „Expanding built-in AI to more devices with Chrome” (1 października 2025). (Chrome for Developers)
