Sprawa, którą podchwyciły dwa tygodnie temu Gizmodo, Tom's Guide, Neowin i Android Authority, dotyczy pliku weights.bin o rozmiarze ~4 GB, który Google Chrome zapisuje na dyskach użytkowników bez zgody, bez powiadomienia i z automatycznym ponownym pobieraniem, jeśli zostanie usunięty. Większość publikacji zatrzymała się na poziomie konsumenckim: „znajdź folder, usuń plik, ewentualnie zmień ustawienie".
To nie jest temat konsumencki. To jest temat o architekturze dystrybucji infrastruktury AI w przeglądarce, której używa 64% internetu — i o tym, że ta architektura projektowo omija każdy konsens, każdą zgodę i każde europejskie prawo, które miało takie sytuacje uregulować od 2002 roku.
Schodzimy głębiej. Pokażemy dokładnie:
- jak Chrome to robi (kod źródłowy, identyfikator komponentu, ścieżki URL, format pakietu),
- jak to zostało udowodnione poza wszelką wątpliwość (z poziomu kernela macOS, nie z poziomu Chrome),
- co siedzi w katalogu poza samym modelem (i dlaczego to ważniejsze niż
weights.bin), - dlaczego to złamanie czterech różnych aktów prawnych,
- jak to zablokować definitywnie na każdej platformie i co konkretnie te blokady robią pod spodem.
TL;DR dla osób, które wrócą do tego później
- Plik nazywa się
weights.bin, ma ~4 GB, leży wOptGuideOnDeviceModel/<wersja>/, zawiera wagi modelu Gemini Nano. - Pakiet podpisany jest w formacie CRX-3 i pobierany jest z plain-HTTP CDN
edgedl.me.gvt1.com(TLS nie jest wymagany — podpis Google jest weryfikowany w pakiecie). - Identyfikator komponentu:
{44fc7fe2-65ce-487c-93f4-edee46eeaaab}. - Chrome profiluje sprzęt użytkownika (
performance_class,vram_mb) przed wyświetleniem jakiegokolwiek UI ustawień AI, żeby zdecydować, czy go „wyłonić" do pushu. - Mechanizm uruchamia się przez
LaunchAgent(macOS) / scheduled task (Windows) niezależnie od Chrome. Sam Chrome dorzuca własnyOnDeviceModelComponentInstallerjako drugą ścieżkę. - Najlepiej dokumentowana blokada: klucz polityki
GenAILocalFoundationalModelSettings = 1w rejestrze (Windows) lub przez plist (macOS) lub przezpolicies.json(Linux). Sama edycjachrome://flagsnie jest trwała. - Konsekwencje prawne: bezpośrednie naruszenie art. 5(3) dyrektywy ePrivacy 2002/58/WE, art. 5(1) i 25 RODO, oraz wzorca dark-pattern z Wytycznych EDPB 03/2022.
1. Co dokładnie ląduje na dysku — anatomia katalogu
To nie jest jeden plik. To jest mini-instalacja systemu LLM.
Pełna ścieżka w typowej instalacji:
# Windows
%LOCALAPPDATA%\Google\Chrome\User Data\OptGuideOnDeviceModel\<wersja>\
# macOS
~/Library/Application Support/Google/Chrome/OptGuideOnDeviceModel/<wersja>/
# Linux (jeśli zainstalowany Google Chrome, nie sam Chromium)
~/.config/google-chrome/OptGuideOnDeviceModel/<wersja>/<wersja> w momencie pisania tego tekstu to 2025.8.8.1141 (numerologia: kompilacja modelu z sierpnia 2025, oznaczona w pipeline'ie Chrome jako patch 1141 — zmieni się przy każdym refreshu modelu).
W środku — co odkrył w trakcie audytu na świeżo utworzonym profilu macOS niezależny badacz prywatności Alexander Hanff — siedzi pięć artefaktów:
| Plik | Co to jest | Rozmiar |
|---|---|---|
weights.bin | Wagi modelu Gemini Nano w formacie binarnym, gotowe do załadowania przez runtime ML Chrome | ~4 GB |
adapter_cache.bin | Skompilowany cache adapterów LoRA — gotowy do natychmiastowej inferencji bez recompile | dziesiątki MB |
encoder_cache.bin | Cache tokenizera / encodera tekstu — preprocessing nie potrzebuje świeżej inicjalizacji | dziesiątki MB |
_metadata/verified_contents.json | Manifest CRX-3 — listy plików, ich hashe, łańcuch podpisu | KB |
on_device_model_execution_config.pb | Konfiguracja runtime'u w formacie Protocol Buffers — parametry inferencji, ścieżki feature'ów, polityki bezpieczeństwa modelu | KB |
Plik on_device_model_execution_config.pb jest tym, na co warto patrzeć z punktu widzenia bezpieczeństwa, nie sam model. To jest serwerowy (Google) plan wykonania, który mówi runtime'owi Chrome jakimi parametrami uruchamiać model, w jakich kontekstach, dla jakich funkcji, i z jakimi guardrails. Zmiany w tym pliku — które przychodzą z aktualizacją, bez interakcji użytkownika — modyfikują zachowanie modelu na maszynie użytkownika. To nie jest „Chrome aktualizuje przeglądarkę". To jest „Google zmienia parametry pracy LLM-a działającego na twoim sprzęcie i przetwarzającego twoje dane".
To nie wszystko. Hanff udokumentował, że razem z głównym modelem Chrome rejestruje cztery dodatkowe cele w wewnętrznym katalogu optimization_guide_model_store — numerowane jako 40, 49, 51 i 59 w enumeracji Chrome. To pomocnicze modele text-safety i routingu promptów, które idą w parze z głównym LLM. Żaden z nich nie istniał na profilu przed momentem instalacji.
2. Mechanika instalacji — chronologia z poziomu kernela
Większość raportów z ostatnich dwóch tygodni opierała się na obserwacji „nagle pojawił się 4-gigabajtowy folder". To dowód słaby, bo Google mógłby (i prawdopodobnie spróbuje) potraktować je jako anegdoty. Hanff sięgnął głębiej: do .fseventsd — kernelowego logu zdarzeń filesystem na macOS, którego ani Chrome ani Google nie mogą edytować ani zdalnie wyczyścić.
Stworzył świeży profil Chrome 23 kwietnia 2026. Profil był prowadzony wyłącznie przez Chrome DevTools Protocol w ramach automatycznego audytu prywatności — ładuje stronę, czeka 5 minut, zamyka. Zero kliknięć użytkownika. Zero interakcji z powierzchnią „AI Mode". Zero kliknięć w pasek adresu. Pełna sterylność.
Sześć dni później du -sh na katalogu profilu zwrócił 4 GB. Cofnięcie się do .fseventsd pozwoliło zrekonstruować, kiedy dokładnie te bajty wylądowały na dysku — sekunda po sekundzie:
24 kwietnia 2026, 14:38:54 UTC
→ Chrome tworzy katalog OptGuideOnDeviceModel
→ page file: 0000000003f7f339
24 kwietnia 2026, 14:47:22 UTC (+8 min 28 s)
→ Trzy równoczesne subprocesy unpackera w
/private/var/folders/.../com.google.Chrome.chrome_chrome_Unpacker_BeginUnzipping.*
→ Jeden (5xzqPo) rozpakowuje: weights.bin, manifest.json,
_metadata/verified_contents.json, on_device_model_execution_config.pb
→ Drugi: aktualizacja CRL (certyfikaty)
→ Trzeci: refresh preload-data przeglądarki
→ page file: 00000000040c8855
24 kwietnia 2026, 14:53:22 UTC (+14 min 28 s od startu)
→ Rozpakowane pliki przeniesione do
OptGuideOnDeviceModel/2025.8.8.1141/
→ Razem z adapter_cache.bin i encoder_cache.bin
→ Cztery dodatkowe modele (40, 49, 51, 59) rejestrują się w
optimization_guide_model_store
→ page file: 00000000040d0f9cŁączny czas instalacji: 14 minut, 28 sekund. Łączna aktywność użytkownika w tym oknie: zero.
Najważniejszy szczegół z tej rekonstrukcji nie dotyczy czasu, tylko nazwy. Katalog tymczasowy unpackera nazywa się:
com.google.Chrome.chrome_chrome_Unpacker_BeginUnzipping.5xzqPoPrefix com.google.Chrome.chrome_chrome_* to konwencja nazewnictwa subprocesów samego Google Chrome (bundle ID przeglądarki). Nie com.google.GoogleUpdater.*. Nie com.google.GoogleSoftwareUpdate.*. To oznacza, że writer'em nie jest separowany updater (który użytkownik mógłby zrozumieć jako „obowiązkową aktualizację"), tylko sam proces przeglądarki. Przeglądarka, której zadaniem jest ładowanie stron WWW, sięga do filesystemu użytkownika z własnej inicjatywy i kładzie 4 GB binarki ML, podczas gdy aktywna karta robi coś zupełnie niezwiązanego (czeka na timer pięciominutowy).
I jeszcze jeden element. Chrome batchował w tym samym oknie czasowym:
- aktualizację listy odwołanych certyfikatów (CRL — bezpieczeństwo),
- refresh preload-data (optymalizacja sieci),
- pobranie 4 GB modelu LLM (zupełnie inna kategoria).
Z perspektywy projektu — model LLM został potraktowany jak rutynowy element konserwacji przeglądarki. Z perspektywy prawa — to są trzy zupełnie różne kategorie ingerencji w urządzenie końcowe użytkownika i tylko pierwsze dwie mieszczą się w „strictly necessary" z art. 5(3) ePrivacy.
3. Architektura — co Chromium ma w kodzie
Część rozumowania opiera się na obserwacjach behawioralnych, część bezpośrednio na kodzie źródłowym Chromium. Plik chrome/browser/component_updater/optimization_guide_on_device_model_installer.h w gałęzi main jest publiczny:
cpp
// Copyright 2023 The Chromium Authors
// Base class for on-device model installer policies.
class OptimizationGuideOnDeviceModelInstallerPolicy
: public ComponentInstallerPolicy {
public:
bool SupportsGroupPolicyEnabledComponentUpdates() const final;
bool RequiresNetworkEncryption() const final;
update_client::CrxInstaller::Result OnCustomInstall(
const base::DictValue& manifest,
const base::FilePath& install_dir) final;
bool AllowCachedCopies() const final;
bool AllowUpdatesOnMeteredConnections() const final;
update_client::InstallerAttributes GetInstallerAttributes() const override;
static void UpdateOnDemand(const std::string& id,
OnDemandUpdater::Priority priority);
};
enum class OnDeviceModelType {
kBaseModel,
kClassifierModel,
};Cztery rzeczy do zauważenia w tej deklaracji.
Po pierwsze, RequiresNetworkEncryption(). To metoda zwracająca bool, która decyduje, czy pobranie musi iść przez HTTPS. Spojrzenie w GoogleUpdater logi pokazuje rzeczywisty URL pobrania:
http://edgedl.me.gvt1.com/edgedl/diffgen-puffin/
%7B44fc7fe2-65ce-487c-93f4-edee46eeaaab%7D/...To jest plain HTTP. Nie HTTPS. Integralność pakietu jest weryfikowana podpisem CRX-3 w środku — Chrome ma wbudowane klucze publiczne Google i sprawdza podpis sygnatariusza zanim coś rozpakuje. Z punktu widzenia integralności kryptograficznej to wystarcza. Z punktu widzenia obserwowalności — to katastrofa. Każdy operator sieci między użytkownikiem a CDN widzi, co konkretnie zostało pobrane, kiedy i jak często, włącznie z dokładnym profilem urządzenia w User-Agencie. Na poziomie publicznego Wi-Fi w kawiarni to jest sygnatura, którą można skorelować z konkretnym użytkownikiem na podstawie samego rozmiaru transferu (4 GB pakietu jest dość unikalnym fingerprintem).
Po drugie, AllowUpdatesOnMeteredConnections(). To metoda, która decyduje, czy aktualizacja komponentu (czyli pobranie ~4 GB) może iść przez metered connection — czyli przez 4G/5G, przez mobilne tethering, przez połączenie hotelowe z limitem. W publicznym kodzie sama deklaracja nie pokazuje wartości return, ale obserwacja behawioralna z forów (raporty użytkowników, którym zniknął gigabajtowy limit danych) sugeruje, że dla tego komponentu zwraca true co najmniej w niektórych konfiguracjach. To znaczy — Chrome może pobrać 4 GB przez taryfę mobilną użytkownika bez ostrzeżenia. W krajach, gdzie smartfon jako tethering jest jedynym dostępem do internetu (znaczna część Afryki, Azji Południowej, Ameryki Łacińskiej) to nie jest niedogodność. To jest miesięczny limit transferu wyparowany przez przeglądarkę bez zgody.
Po trzecie, OnDeviceModelType enum z dwiema wartościami: kBaseModel (główny LLM) i kClassifierModel (małe modele klasyfikacyjne). Potwierdza to obserwację, że Chrome instaluje nie jeden model, tylko cały zestaw — głównego dużego LLM-a i mniejsze modele bezpieczeństwa.
Po czwarte, UpdateOnDemand(...) z Priority. Chrome ma wbudowaną zdolność do wyzwalania pobrania na żądanie z dowolnym priorytetem. To nie jest „pasywny komponent, który się aktualizuje, kiedy update'er się zdecyduje". To jest aktywny mechanizm pull, który może być inicjowany z dowolnego punktu w kodzie Chrome.
4. Eligibility — Chrome profiluje twój sprzęt, żeby zdecydować czy się ci „należy"
To jest część, która zostaje zwykle pominięta w prasie konsumenckiej, a jest być może najgorsza z punktu widzenia RODO.
Zanim Chrome zacznie cokolwiek pobierać, profiluje urządzenie. W pliku Local State (JSON w katalogu User Data) Hanff znalazł blok:
json
"optimization_guide": {
"on_device": {
"model_validation_result": {
"attempt_count": 1,
"result": 2,
"component_version": "2025.8.8.1141"
},
"performance_class": 6,
"vram_mb": "36864"
}
}performance_class: 6 to wewnętrzna enumeracja Chrome charakteryzująca klasę wydajności urządzenia (obliczona z klasy CPU, klasy GPU, pamięci RAM i VRAM). vram_mb: 36864 to dokładny rozmiar unified memory zmierzony na maszynie testowej (Apple M1 Ultra z 128 GB unified, z czego 36 GB przeznaczone jako VRAM dla GPU).
Chrome scharakteryzował sprzęt użytkownika — odczytał GPU, odczytał pamięć — przed tym, jak jakakolwiek powierzchnia UI związana z AI została wyświetlona użytkownikowi. Mechanizm profilowania pracuje na poziomie wcześniejszym niż onboarding czy zgoda. Decyzja „push do tego użytkownika czy nie" jest podjęta automatycznie na podstawie odcisku palca sprzętowego.
Z punktu widzenia RODO art. 4(1) — odcisk palca sprzętu skorelowany z profilem przeglądarki to są dane osobowe (umożliwiają identyfikację urządzenia, a przez nie konkretnego użytkownika z dużym prawdopodobieństwem). Z punktu widzenia art. 6 — przetwarzanie tych danych odbywa się bez ważnej podstawy prawnej (nie ma zgody, nie ma niezbędności do umowy z użytkownikiem, nie ma uzasadnionego interesu, który nie byłby przeważony przez interes użytkownika). Z punktu widzenia art. 25 (privacy by design) — pobieranie odcisku palca sprzętowego, żeby zdecydować o pushu 4 GB pliku, jest dokładnym przeciwieństwem minimalizacji.
5. Dwa równoległe kanały dostarczenia — to nie jest awaria, to jest projekt
Chrome ma w sobie dwa niezależne ścieżki, które razem składają się na ten silent install. Hanff udokumentował je oba:
Ścieżka 1: GoogleUpdater (zewnętrzny demon). Na macOS to LaunchAgent, który odpala się raz na godzinę. Pobiera 7 MB skompresowanego control component z identyfikatorem {44fc7fe2-65ce-487c-93f4-edee46eeaaab}. Ten pakiet zawiera tylko manifest — listę aktualnie aktualnych wersji modeli i ścieżki do nich w CDN. Nie zawiera samego modelu.
Ścieżka 2: OnDeviceModelComponentInstaller (wewnątrz Chrome). To jest klasa, której nagłówek przytoczyliśmy wyżej. Kiedy Chrome czyta manifest dostarczony przez ścieżkę 1 i widzi, że jego profil jest „eligible" (klasa wydajności wystarczająca, brak polityki blokującej), uruchamia niezależne pobranie z CDN — i to bezpośrednio z procesu przeglądarki, nie z updatera.
Dlaczego dwie ścieżki? Bo updater jako proces systemowy nie ma dostępu do user data profile Chrome — nie wie, do którego profilu zapisać model. Chrome wie. Więc updater pobiera tylko mapę, a Chrome pobiera ładunek do właściwego miejsca w katalogu profilu.
Architektura jest elegancka inżyniersko. Architektura jest też nie do obrony z punktu widzenia consent: jest profilowanie sprzętu, jest pobieranie metadanych, jest pobieranie głównego ładunku, jest zapis. Cztery oddzielne zdarzenia na maszynie użytkownika, z których ani jedno nie zostało zatwierdzone.
6. Wewnętrzne flagi — instalacja zaczyna się przed włączeniem UI ustawień
W Local State widać dwie flagi rolloutowe Chrome:
OnDeviceModelBackgroundDownload → enabled
ShowOnDeviceAiSettings → enabledPierwsza wyzwala silent download. Druga ujawnia w chrome://settings/ sekcję „On-device AI", w której użytkownik teoretycznie może się czegoś dowiedzieć. Obie są gated tym samym upstream rollout flag.
To znaczy — w czasie t=0 pobieranie się zaczyna. W czasie t=t+ε ustawienia AI w chrome://settings zaczynają być dostępne. Pobieranie i ekspozycja UI są wyzwalane w tej samej kolejności, a użytkownik nawet w teorii nie ma okna czasowego, w którym mógłby się dowiedzieć przed faktem.
To nie jest niedopatrzenie. To jest projekt — ujawnienie istnienia funkcji jest powiązane z tym samym przełącznikiem co rozpoczęcie instalacji. UI nie istnieje, dopóki nie zaczyna się też push.
7. „AI Mode" — pigułka w pasku adresu, która użytkownika wprowadza w błąd
Tu zaczyna się część, którą każdy prawnik specjalizujący się w prawie konsumenckim powinien przeczytać dwa razy.
Chrome 147 — wersja, w której rozpychanie funkcji AI jest najbardziej widoczne — w pasku adresu, na prawo od pola URL, wyświetla pigułkę „AI Mode". To jest najbardziej widoczne miejsce UI w całej przeglądarce.
Użytkownik widząc:
- pigułkę „AI Mode" w pasku adresu,
- wiedząc, że Chrome ma teraz funkcje AI,
- ewentualnie wiedząc, że na jego dysku siedzi 4 GB Gemini Nano (jeśli to odkrył),
naturalnie wnioskuje, że pigułka „AI Mode" używa lokalnego modelu, więc jego zapytania zostają na urządzeniu.
Każda część tego wniosku jest fałszywa.
Pigułka „AI Mode" w pasku adresu Chrome 147 to cloud-backed Search Generative Experience. Każde zapytanie wpisane w to pole jest wysyłane przez sieć na serwery Google i procesowane przez ich hostowane modele. Lokalny Gemini Nano nie jest wywoływany przez ten flow w ogóle. To są zupełnie różne ścieżki kodu.
Funkcje, które faktycznie używają lokalnego modelu — „Help me write" w polach <textarea>, sugestie grup kart, smart paste, podsumowywanie stron — są pochowane w menu kontekstowych elementów formularzy i prawym kliknięciu na grupie kart. Przeciętny użytkownik nie znajdzie ich nigdy.
Konstrukcja jest, w terminologii Wytycznych EDPB 03/2022 (Deceptive design patterns):
- Misleading information — etykieta „AI Mode" sugeruje lokalność, której nie ma; bliskość 4 GB pliku na dysku tę sugestię wzmacnia.
- Skipping — użytkownik nie dostaje momentu wyboru między lokalną a chmurową ścieżką AI. Obie są włączone tym samym upstream switchem.
- Hindering — wyłączenie AI Mode nie wyłącza pobierania lokalnego modelu, a wyłączenie pobierania lokalnego modelu nie wyłącza AI Mode. Trzy oddzielne kontrolki w trzech oddzielnych miejscach (
chrome://flags,chrome://settings/ai, polityka rejestru).
Z punktu widzenia użytkownika: płaci 4 GB dysku i 4 GB transferu, dostaje surface, który mu sugeruje prywatność, której nie ma. Z punktu widzenia Google: lokalny model jest future-options resource — zasobem rozłożonym na urządzeniach na wypadek, gdyby kiedykolwiek Google chciał z niego skorzystać. Koszt dystrybucji ponosi użytkownik.
8. Analogia z Anthropic Claude Desktop
Hanff dwa tygodnie wcześniej opisał analogiczny przypadek: aplikacja Claude Desktop firmy Anthropic, podczas instalacji, rejestruje Native Messaging bridge w siedmiu przeglądarkach opartych na Chromium (Brave, Edge, Arc, Vivaldi, Opera, Chromium, i głównym Chrome) — bez pytania o zgodę w żadnej z nich. Każde uruchomienie Claude Desktop ponownie rejestruje most, nawet jeśli użytkownik go usunął.
Wzorzec jest identyczny:
- Wymuszone bundling przez granice zaufania (Anthropic → cudza przeglądarka; Google → katalog niezależnego runtime'u ML).
- Domyślny default bez opt-in.
- Usunięcie trudniejsze niż instalacja.
- Pre-staging zdolności, której użytkownik nie poprosił.
- Inflacja zakresu przez generyczne nazewnictwo.
- Rejestracja w zasobach nieskonfigurowanych przez użytkownika.
- Brak dokumentacji w miejscu, w którym normalny użytkownik patrzy.
- Automatyczna reinstalacja przy każdym uruchomieniu.
- Brak retrospektywnej legitymizacji.
- Zwykły release channel, nie test build.
Skala jest jednak różna: Claude Desktop to ~3 miliony użytkowników. Chrome to 3,45–3,83 miliarda użytkowników. Wzorzec ten sam, audytowalność też ta sama, konsekwencje rzędy wielkości większe.
Mamy tu nowy wzorzec dystrybucji infrastruktury AI w stos klienta. Nazwijmy go po imieniu: silent client-side AI deployment. Spodziewajmy się więcej.
9. Aspekt prawny — cztery naruszenia jednocześnie
Poniższa analiza jest redakcyjną oceną cyberflux.pl i nie stanowi porady prawnej ani opinii kancelarii — jej celem jest wskazanie potencjalnych obszarów niezgodności, nie rozstrzygnięcie kwestii prawnych. Ocena opiera się na publicznie dostępnych materiałach i kodzie źródłowym Chromium. Nie jest to spór doktrynalny — fakty są udokumentowane, a ich kwalifikacja pod poniższe normy wydaje się badaczom redakcji wyraźna.
Art. 5(3) dyrektywy ePrivacy 2002/58/WE. Norma jednoznaczna: przechowywanie informacji w urządzeniu końcowym subskrybenta lub uzyskiwanie dostępu do informacji już tam przechowywanych jest dopuszczalne tylko za uprzednią, świadomą, dobrowolną i jednoznaczną zgodą, z wyjątkiem przypadków, gdy jest to ściśle niezbędne do świadczenia usługi społeczeństwa informacyjnego wyraźnie zażądanej przez użytkownika. 4 GB modelu LLM, którego użytkownik nie zażądał, dla funkcji których nie aktywował, w przeglądarce, która działa bez tego pliku — nie mieści się w wyjątku. Naruszenie bezpośrednie.
W marcu 2025 niemiecki sąd rozstrzygnął sprawę Google Tag Manager: zapisanie pliku na urządzeniu użytkownika bez uprzedniej zgody narusza § 25(1) TTDSG (transpozycja art. 5(3) ePrivacy do prawa niemieckiego). To bezpośrednio aplikowalny precedens dla weights.bin. W Polsce odpowiednik to art. 173 Prawa Telekomunikacyjnego.
Art. 5(1) RODO. Zasady przejrzystości i legalności przetwarzania. Profil sprzętowy urządzenia (performance_class, vram_mb) jest przetwarzaniem danych osobowych w zakresie, w jakim pozwala na identyfikację urządzenia, a przez to użytkownika. Brak przejrzystości — nie ma informacji w plain language w żadnym miejscu, do którego użytkownik dotrze.
Art. 25 RODO (privacy by design / by default). Pre-staging 4 GB modelu na wypadek, gdyby użytkownik kiedyś z niego skorzystał, jest projektem maksymalizacyjnym, nie minimalizacyjnym. Naruszenie obowiązku domyślnej minimalizacji.
Art. 25 ust. 2 RODO (data protection by default). Wymóg, by domyślne ustawienia przetwarzały tylko dane niezbędne. Domyślne ustawienia Chrome są dokładnie odwrotne.
CSRD (Corporate Sustainability Reporting Directive, dyrektywa 2022/2464). Push 4 GB binarki na hipotetyczne 500 milionów urządzeń (środkowy estymator Hanffa) to według metodologii WebSentinel (energia transferu 0,06 kWh/GB × współczynnik emisyjności 0,25 kg CO2e/kWh):
- ~120 GWh energii rocznie,
- ~30 000 ton CO2e w samej dostawie,
- ~640 000 ton CO2e w embodied carbon SSD-ków, których pojemność idzie na ten model zamiast na dane użytkownika.
Dla porównania: 30 000 ton CO2e to roczna emisja około 6 500 średnich europejskich samochodów osobowych. Dla scenariusza górnego (1 mld urządzeń) — 60 000 ton CO2e, czyli ~13 000 samochodów. To są wartości, które dla podmiotu objętego zakresem CSRD są wartościami raportowalnymi w Scope 3 Category 11.
W żadnym dotychczasowym raporcie zrównoważonego rozwoju Google ta emisja nie pojawia się w wyodrębnionej formie.
10. Jak to faktycznie zablokować — pełny zestaw
Każda z opisanych tu metod działa. Im wyżej na liście, tym trudniej Chrome to zignorować przy następnej aktualizacji.
Windows — polityka grupowa przez rejestr (rekomendowane)
Otwórz regedit jako administrator, przejdź do (utwórz brakujące klucze):
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\ChromeUtwórz wartość DWORD (32-bit):
Name: GenAILocalFoundationalModelSettings
Value: 1Zrestartuj komputer. Po restarcie:
- istniejący
weights.binzostanie usunięty przez sam Chrome, - nowe pobranie nie zostanie wyzwolone,
- wpis będzie respektowany przez wszystkie kanały Chrome (Stable, Beta, Dev, Canary) oraz wszystkie profile użytkownika.
To jest polityka Chrome Enterprise udokumentowana przez Google. Zachowanie zdefiniowane jest w Chrome:
0(lub brak ustawienia) — model pobierany automatycznie, używany do inferencji,1— model nie jest pobierany, a istniejący jest usuwany,2(jeśli zdefiniowane w danej wersji) — pobierany, ale nieaktywny.
Alternatywnie można ustawić ComponentUpdatesEnabled = 0 w tej samej ścieżce — to wyłącza wszystkie komponenty updatera Chrome (w tym pobieranie modelu), ale też wyłącza inne komponenty (np. aktualizację filtra Safe Browsing). Mniej selektywne, nie polecam jako pierwszy wybór.
macOS — plist polityki
Polityki Chrome na macOS są zarządzane przez defaults. W terminalu, jako administrator:
bash
sudo defaults write /Library/Preferences/com.google.Chrome \
GenAILocalFoundationalModelSettings -integer 1Po tym zrestartuj Chrome. Polityka jest stosowana do wszystkich profili użytkownika tej maszyny.
Jeśli chcesz tylko dla swojego konta:
bash
defaults write com.google.Chrome \
GenAILocalFoundationalModelSettings -integer 1Manualnie można też usunąć istniejący katalog:
bash
rm -rf ~/Library/Application\ Support/Google/Chrome/OptGuideOnDeviceModel…ale bez polityki, Chrome go odtworzy.
Linux — JSON polityki
Stwórz plik /etc/opt/chrome/policies/managed/disable_genai_local_model.json (potrzebne sudo):
json
{
"GenAILocalFoundationalModelSettings": 1
}Zrestartuj Chrome. Sprawdź w chrome://policy/ że polityka jest aktywna i poprawna.
Jeśli używasz Chromium z paczki dystrybucyjnej zamiast Google Chrome — w wielu dystrybucjach (Debian, Ubuntu, Arch oparte na chromium-deb) ta funkcjonalność nie jest skompilowana w ogóle. Sprawdź czy katalog OptGuideOnDeviceModel w ogóle istnieje w twoim profilu przed dodawaniem polityki. Jeśli nie istnieje — masz Chromium bez Gemini Nano i nie musisz nic robić.
Weryfikacja, że blokada działa
W Chrome otwórz chrome://policy/ — powinieneś zobaczyć wpis GenAILocalFoundationalModelSettings ze statusem OK i wartością 1.
Otwórz chrome://components/ — Optimization Guide On Device Model powinien pokazać wersję 0.0.0.0 albo nie pojawić się w ogóle. Jeśli widzisz prawidłowy numer wersji — polityka nie zadziałała (sprawdź ścieżkę rejestru / plist / JSON).
Sprawdź katalog OptGuideOnDeviceModel w swoim profilu. Po blokadzie powinien zniknąć w ciągu kilku minut od restartu Chrome.
Co nie jest wystarczające
- Samo usunięcie
weights.bin— Chrome go odtworzy. - Samo ustawienie atrybutu read-only na pliku — Chrome najpierw usunie, potem zapisze świeży.
- Samo wyłączenie flagi
chrome://flags/#optimization-guide-on-device-model— flaga może zostać zresetowana przy aktualizacji. - Wylogowanie się z konta Google — eligibility opiera się na profilu Chrome (lokalny profil), nie na koncie Google.
- Tryb incognito —
OptGuideOnDeviceModeljest współdzielony między profile, w tym incognito.
Pełna alternatywa — usuń Chrome, użyj Ungoogled Chromium / Vivaldi / Brave
Ungoogled Chromium ma usunięte wszystkie binarne komponenty Google z buildu — w tym GoogleUpdater i OnDeviceModelComponentInstaller. To projekt z licencją 3-clause BSD, aktywnie utrzymywany, wersja 146 jest aktualna w czasie pisania.
Vivaldi i Brave w aktualnych wydaniach raportują, że nie pushują lokalnego modelu Google. Mają własne AI surface (Brave Leo, Vivaldi w trakcie integracji) i własne zasady jego dostarczania. To ma swoje implikacje — ale przynajmniej inne implikacje, a nie te same.
11. Co to oznacza dla obrońców infrastruktury
Jeśli zarządzasz flotą endpointów dla organizacji objętej:
- RODO — pchnij politykę przez GPO / MDM dzisiaj. Pre-stage'owany model przetwarzający prompty użytkowników na maszynach pracowników bez DPIA jest ekspozycją compliance. Dokumentuj akcję w rejestrze czynności przetwarzania.
- HIPAA, PCI-DSS, lub inne reżimy regulujące dane wrażliwe na endpoincie — to samo, ale pilniej. „Lokalne przetwarzanie" przez model, którego nie kontrolujesz, na danych regulowanych, jest minimum P1 w twoim register'ze ryzyk.
- Pracownicy zdalni na metered connections — push 4 GB na taryfę mobilną pracownika jest kosztem, który ponosi firma (jeśli faktura idzie do firmy) albo pracownik (jeśli prywatna). W obu przypadkach to koszt, którego nie autoryzowałeś.
- Środowiska air-gapped / restricted — ten komponent odpala się sam co godzinę próbując pobrać manifest z
edgedl.me.gvt1.com. Jeśli twój firewall blokuje, dostaniesz spike'i prób połączeń w logach. Whitelisting Google domain może być wymagany do pracy Chrome, ale konkretne pobieranie modelu da się odciąć osobno przez politykę.
Wszystkie te zalecenia są w skrócie: traktuj domyślną konfigurację Chrome jako niezgodną z compliance, dopóki nie udowodnisz inaczej.
12. Co dalej — wzorzec się powtórzy
Trzy obserwacje, które są warte zapamiętania bardziej niż sam przypadek weights.bin.
Po pierwsze, infrastruktura AI jest dystrybuowana stronie klienta, bo to się opłaca dostawcy. Inferencja na urządzeniu użytkownika to zerowy koszt GPU dla Google. Model na urządzeniu użytkownika to zerowy koszt CDN po pierwszym pobraniu. Vendor ma silny incentive, żeby model jak najszybciej znalazł się na maszynach. Zgoda użytkownika jest dla tego incentive'u tarciem.
Po drugie, mechanizm component updatera w Chrome został zaprojektowany w 2010 dla małych aktualizacji bezpieczeństwa (CRL, listy malware'u, lokalne listy phishingu). Skala wzrosła od kilobajtów do gigabajtów, ale UX i model zaufania pozostały bez zmian. Architektura, która była proporcjonalna do skali, przestała być proporcjonalna. Component updater pobiera teraz LLM-y używając tego samego mechanizmu, którym pobierał listy hashy phishingu.
Po trzecie, granica między „aktualizacją przeglądarki" a „instalacją niezależnego runtime'u ML z własną polityką przetwarzania i własnym fingerprintingiem urządzenia" zniknęła. Z punktu widzenia systemu plików — to są dwie nieodróżnialne operacje. Z punktu widzenia użytkownika — to są dwie zupełnie różne kategorie ingerencji.
Ten sam wzorzec zobaczymy w Edge (z Microsoft Phi), w Firefoxie (z ich lokalnymi modelami tłumaczenia, które już wycieka jako 200 MB), w Safari z Apple Intelligence. Każdy producent przeglądarki będzie dystrybuował lokalne modele tym samym mechanizmem, którym dystrybuował updater. Każdy raz z naruszeniem art. 5(3) ePrivacy. Każdy raz traktując zgodę jako tarcie do zignorowania.
Pytanie nie brzmi „czy Google wycofa się z tej konfiguracji". Pytanie brzmi — kiedy DPA (Data Protection Authority) z dowolnego państwa członkowskiego ruszy ten temat. Bazą prawną jest dyrektywa z 2002 roku. Naruszenia nie są spekulatywne. Skala uzasadnia maksymalne kary z art. 83 RODO.
Tymczasem — jeśli ufasz tej przeglądarce, zablokuj sam. Jeśli zarządzasz flotą, pchnij politykę. I jeśli budujesz aplikację, która ma używać Prompt API w Chrome — zacznij rozmawiać z prawnikiem, bo właśnie wchodzisz na top funkcjonalności, której podstawa instalacji jest nielegalna w UE.
Źródła i materiał techniczny
- Alexander Hanff, Google Chrome silently installs a 4 GB AI model on your device without consent, That Privacy Guy!, 4 maja 2026 — pełna rekonstrukcja z
.fseventsd, analizą Local State, GoogleUpdater logów oraz analizą prawną i ESG. https://www.thatprivacyguy.com/blog/chrome-silent-nano-install - Chromium source:
chrome/browser/component_updater/optimization_guide_on_device_model_installer.hw gałęzi main. https://chromium.googlesource.com/chromium/src/+/main/chrome/browser/component_updater/optimization_guide_on_device_model_installer.h - Chrome Enterprise — polityka
GenAILocalFoundationalModelSettings, oficjalna dokumentacja: wartości 0/1 i ich efekty. https://chromeenterprise.google/policies/gen-ai-local-foundational-model-settings/ - Mauro Huculak, Stop Chrome from silently downloading Gemini Nano AI model on Windows 11, Pureinfotech — kroki rejestrowe dla Windows. https://pureinfotech.com/stop-chrome-gemini-nano-download-windows-11/
- Dyrektywa 2002/58/WE Parlamentu Europejskiego i Rady (ePrivacy), art. 5(3). https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:02002L0058-20091219
- Rozporządzenie (UE) 2016/679 (RODO), art. 5(1), art. 25. https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Wytyczne EDPB 03/2022 w sprawie deceptive design patterns. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-032022-deceptive-design-patterns-social-media_en
- Pärssinen et al., Environmental impact assessment of online advertising, Science of The Total Environment, 2018 — metodologia 0,06 kWh/GB. https://www.sciencedirect.com/science/article/pii/S0195925517303505
- Tannu, Nair, The dirty secret of SSDs: embodied carbon, ACM SIGENERGY 2023 — 0,16 kg CO2e/GB NAND. https://dl.acm.org/doi/10.1145/3630614.3630618
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł