Staś Małolepszy Mozilla, l10n and web services.

“Firefox wysyła dane o użytkownikach do Google” – nieprawda.

Pewien niemiecki portal napisał, że Firefox wysyła dane o użytkownikach do Google. Tłumaczenia artykułu ukazały się na heise-online.pl oraz na media2.pl. Nie znam niemieckiego, więc odniosę się do artykułów po polsku:

Jest to nieprawda.

Wydaje się, że ktoś miał na początku ochotę na prowokacyjny nagłówek:

Organizacja SuMa-eV podała, że również Firefox wysyła dane o użytkownikach do Google.

Szybko jednak się poprawiono (za co dziękuję), bo w uzupełneniu czytamy (choć to wciąż nieprawda):

Organizacja dodała również, ze w żadnym wypadku Firefox nie wysyła informacji o odwiedzanych serwisach do Google. Dopiero jeśli znajdzie wśród nich adres znajdujący się na liście, odpytuje Google’a, czy ten wpis jest jeszcze aktualny. W skrócie można powiedzieć, że adres URL jest przekazywany wtedy, gdy uważąny jest za szkodliwy.

To jaka jest prawda? Prawdą jest, że co 30 minut Firefox pobiera aktualizacje listy podejrzanych stron, a więc dane o odwiedzonych stronach nie są wysyłane do Google. To Google wysyła użytkownikom Firefoksa listę podejrzanych stron, a Firefox (lokalnie, na komputerze użytkownika) sprawdza, czy odwiedzane strony nie znajdują się na tej liście. Choć też nie do końca – aby zrozumieć, jak to dokładnie działa, trzeba wiedzieć że lista ta nie składa się z URL-i, tylko z tzw. hashy. Specyfikacja podaje przykład:

Input is “abc”

SHA 256 digest is ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c b410ff61 f20015ad.

The 32-bit hash prefix is ba7816bf.

Firefox przechowuje lokalnie listę 32-bitowych “przedrostków” hashy (hash prefixes) i aktualizuje ją co 30 minut (podczas aktualizacji, Firefox pobiera tylko informacje o dodanych i usuniętych stronach, a nie całą listę). Każdy odwiedzany URL jest hashowany i jego prefiks jest porównywany z tą listą. Jeśli jest na niej obecny, to Firefox prosi Google o wszystkie pełne 256-bitowe hashe, które pasują do danego prefiksu. Tak więc jedyne, co może wiedzieć Google, to to że użytkownik odwiedził którąś z N stron (gdzie N jest duże), których hashe zaczynają się od wysłanego przez Firefoksa prefiksu. Dodatkowo, nie widomo dokładnie, jakie to strony, bo hashowanie jest procesem nieodwracalnym, tj. z URL-a można zrobić hash, ale z hasha nie można zrobić URL-a.

Dzięki takiemu systemowi, lista przechowywana w Firefoksie jest niewielkich rozmiarów, zawiera bowiem tylko prefiksy. W przeciwnym wypadku jej rozmiar liczony byłaby prawdopodobnie w megabajtach, co uniemożliwiałoby tak częste jej aktualizowanie (i narażało użytkowników na większe niebezpieczeństwo).

* * *

Po premierze Chrome w sieci pojawiło się wiele artykułów o Google i o Firefoksie. Wiele teorii, porównań i czasami zarzutów. Krytyka jest dobra i potrzebna, ale warto też sprawdzić najpierw, czy słuszna :)

To chyba pierwszy artykuł, który wyjaśnia sprawę, a nie snuje (w większości błędne) domysły. Dzięki!

W większości w miarę prawidłowo, jest jednak kilka “ale”.

“Jeśli jest na niej obecny, to Firefox prosi Google o wszystkie pełne 256-bitowe hashe, które pasują do danego prefiksu.”

Niezupełnie. W założeniu ma być jeden hash, który pasuje dokładnie do odwiedzonej strony/domeny. Poza tym - tak naprawdę (specyfikacja o tym nie pisze) Firefox wysyła kilka hashy, nie tylko związane z tą odwiedzoną stroną, w celu utrudnienia przez Google dojścia, jaka strona była odwiedzona (ale to “zabezpieczenie” i tak można obejść; powinienem bug nowy posłać…). Związany bug: 419117. (Dodano z nim nieprawdziwy komentarz w kodzie… Może to przypadek, może nie… “The insert statement chooses a random ID for the entry” — to zdanie nie jest prawdziwe, sprawdź kod, jeśli mi nie wierzysz.)

“Tak więc jedyne, co może wiedzieć Google, to to że użytkownik odwiedził którąś z N stron (gdzie N jest duże),”

Co do “N jest duże” właśnie nie byłbym taki pewien, a głównie na tym (niepopartym żadnymi wyliczeniami z Twojej strony) założeniu opiera się cała Twoja argumentacja, że “Google nie ma żadnych możliwości szpiegowania”.
Poza tym zwróć uwagę na to, że śmiało można założyć, że Google w dowolnym momencie zna wszystkie domeny w Internecie. Może bez problemu wyliczyć sumy sha256 z nich, wziąć te pierwsze 4 bajty i po prostu porównać z tym, co przyszło od użytkownika. Załóżmy, że jest pasujących 10 stron, z których tylko jedna jest w domenie .pl. Jeśli użytkownik łączy się z adresu IP z Polski, to można z pewnym prawdopodobieństwem przyjąć, że odwiedził stronę w domenie .pl, a nie inną. To tylko jedna z możliwości, jakie ma Google. Jeśli do tego dodać, że z requestem po cały hash (i z requestami po update lokalnej listy), jest przesyłany unikalny identyfikator, przypisany do danego profilu/użytkownika (w ciasteczku Google - ciasteczko z domeny .google.com jest przesyłane z każdym takim requestem), to możliwości identyfikacji “właściwej” strony znacznie rosną (np. sprytne heurystyki na podst. historii innych przysłanych hashy czy historii zapytań w ich wyszukiwarce…).

“których hashe zaczynają się od wysłanego przez Firefoksa prefiksu. Dodatkowo, nie widomo dokładnie, jakie to strony, bo hashowanie jest procesem nieodwracalnym, tj. z URL-a można zrobić hash, ale z hasha nie można zrobić URL-a.”

Jeśli masz listę hashy i wiesz na podstawie czego zostały obliczone, to możesz dopasować hashe i w ten sposób znaleźć właściwy URL/domenę. A Google ma listę URLi/domen, bo to w końcu oni przesyłają hashe z nich wyliczone do przeglądarki.

“Dzięki takiemu systemowi, lista przechowywana w Firefoksie jest niewielkich rozmiarów, zawiera bowiem tylko prefiksy. W przeciwnym wypadku jej rozmiar liczony byłaby prawdopodobnie w megabajtach, co uniemożliwiałoby tak częste jej aktualizowanie (i narażało użytkowników na większe niebezpieczeństwo).”

“Pełny” plik urlclassifier3.sqlite ma wielkość ok. 50 MB. Napiszę o nim kiedyś więcej, bo dosyć dobrze znam strukturę i przeznaczenie bazy danych w nim zawartej (chociaż prawdę mówiąc przeznaczenia tabeli “moz_subs” nadal nie jestem pewien…).

“Po premierze Chrome w sieci pojawiło się wiele artykułów o Google i o Firefoksie. Wiele teorii, porównań i czasami zarzutów. Krytyka jest dobra i potrzebna, ale warto też sprawdzić najpierw, czy słuszna :)”

Warto też wszystko sprawdzić, zanim się wyprodukuje post w blogu, który ma stanowić “sprostowanie” dla jakichś niusów.
A propos Chrome - z mojego pobieżnego przeglądania źródeł Chrome wynika, że w Chrome jest zaimplementowany dokładnie ten sam protokół, co w FF3 (chociaż pewne szczegóły pewnie się różnią…). Zob. katalog “safe_browsing” w źródłach Chrome. Np. w pliku protocol_manager.cc są te same URLe, związane z tą usługą, co w about:config (czyli w firefox.js) w Firefoksie. Z kolei w protocol_parser.h jest podany link do specyfikacji, która jest dokładnie ta sama, co w FF3. :-)

Pozdrawiam, ta wiadomość powinna być chyba dłuższa, ale na razie tyle.

Napisałem wyżej: “W większości w miarę prawidłowo (…)“, jednak w sumie nie jest prawidłowo. Twierdzenia różnych serwisów o tym, że “Firefox wysyła dane o użytkownikach do Google” jest w zasadzie prawdziwe, a Ty piszesz, że to nieprawda. Co więcej, zacytowany przez Ciebie fragment:

“Organizacja dodała również, ze w żadnym wypadku Firefox nie wysyła informacji o odwiedzanych serwisach do Google. Dopiero jeśli znajdzie wśród nich adres znajdujący się na liście, odpytuje Google’a, czy ten wpis jest jeszcze aktualny. W skrócie można powiedzieć, że adres URL jest przekazywany wtedy, gdy uważąny jest za szkodliwy.”

uznałeś za nieprawdziwy, ale tak naprawdę sytuacja jest bardziej złożona:

“Organizacja dodała również, ze w żadnym wypadku Firefox nie wysyła informacji o odwiedzanych serwisach do Google.” — wysyła, nie wprost (tzn. nie wysyła całych URLi “dosłownie”), ale jednak pewne informacje związane z odwiedzoną stroną przesyła; dalej:

“Dopiero jeśli znajdzie wśród nich adres znajdujący się na liście, odpytuje Google’a, czy ten wpis jest jeszcze aktualny.” — w zasadzie prawda; dalej:

“W skrócie można powiedzieć, że adres URL jest przekazywany wtedy, gdy uważąny jest za szkodliwy.” — dowcip polega na tym, że Google może przysłać hashe, które pasują do stron, których odwiedziny chcieliby monitorować, a później, przy żądaniach o pełny hash, zawsze przysyłać losowo wygenerowany, lipny hash, który nie będzie pasował do żadnej strony. Mówiąc inaczej — nie wiadomo a priori, jakie strony tak naprawdę są zablokowane przez Google, nie można zweryfikować tego, czy lokalna baza zawiera listę “złych” URLi/domen, czy też także są wśród nich URLe/domeny, których odwiedziny Google chciałoby monitorować. (Aczkolwiek można sprawdzić wybraną domenę/stronę (czy też ich listę), czy wejście na nią spowoduje wysłanie requestu po cały hash.)

Dalej, napisałeś: “Prawdą jest, że co 30 minut Firefox pobiera aktualizacje listy podejrzanych (…)”. Z tym czasem też nie do końca tak jest. Z moich obserwacji wynika, że ten czas faktycznie oscylował zawsze w okolicach 1800 sekund, ale generalnie może się to zmienić, bo to w zasadzie Google decyduje o czasie następnego połączenia: przeczytaj jeszcze raz dokładnie protokół, zwróć uwagę na parametr “n:” w sekcji “HTTP Response for Data”. (Obsługa tego parametru jest zaimplementowana w FF3, sprawdzałem źródła.)

Sprostowanie, bo się troszkę zagalopowałem :-) - napisałem w drugim komentarzu wyżej:

“”Organizacja dodała również, ze w żadnym wypadku Firefox nie wysyła informacji o odwiedzanych serwisach do Google.” — wysyła, nie wprost (tzn. nie wysyła całych URLi “dosłownie”), ale jednak pewne informacje związane z odwiedzoną stroną przesyła”

oczywiście, nie z każdą odwiedzoną stroną, ale tylko z tą pasującą do hasha w lokalnej bazie danych itd. (zresztą tak naprawdę jest jeszcze kilka inna warunków, które muszą być spełnione, żeby się pojawiło połączenie z Google po pełny hash - np. nie może istnieć już pełny, w miarę aktualny hash w bazie (przeglądarka może cache’ować pobrane pełne hashe) i takie tam :)).

—
Przy okazji warto jednak zwrócić uwagę na inną kwestię, w oderwaniu w zasadzie od przyziemnych kwestii technicznych, o których było wyżej: to Google wyłącznie decyduje, kiedy i jakie strony zablokować, bez kontroli jakiejkolwiek społeczności, nie tylko “społeczności Mozilli”, ale też społeczności, powiedzmy, międzynarodowej.

W ogóle uważam za poroniony pomysł wprowadzenia listy stron stanowiących “atak” (czyli tzw. “ochrony przed malwarem”). O co tutaj chodzi? Przecież jeśli istnieje w przeglądarce błąd pozwalający wykonać po wejściu na odpowiednio spreparowaną stronę dowolny kod w systemie, to właściwym rozwiązaniem jest przecież tylko i wyłącznie usunięcie tego błędu w przeglądarce, a nie (próby) blokady “złych” stron (bo one mogą się szybko zmieniać).

Prosiłbym o umieszczenie wszystkich moich komentarzy (może za wyjątkiem niniejszego), włącznie z pierwszym, który zaczynał się od słów “W większości w miarę prawidłowo (…)”, ewentualnie żadnego, jeśli tylko pierwszy komentarz uznałeś za niepożądany (bo go aktualnie nie widzę).
Pozdrawiam.

@BartZilla:
Aksimet zjadł niechcący pierwszy komentarz, przez miałem problemy ze zrozumieniem drugiego i trzeciego ;) Już powinno być dobrze.

O, hej BarZilla :) Dawno Cie nie widzialem… czekaj… od kiedy? Ah wiem! Od kiedy zaatakowales mnie przekonujac, ze sie nie znam, nic nie rozumiem, i nie mam pojecia jakie ciemne sily w Mozilli wspolpracuja z Google aby zdobyc swiat, a ja odpisalem Cie dluugasnego maila… tak, chyba od wtedy… Dobrze wiedziec, ze zyjesz i energia Cie rozpiera :)

Co do meritum.
1) Lista stron podejrzanych jest zdaje sie z Symantec Phishing Group.
2) Co do pytania o “maleware” - wydaje mi się, że chwila sam na sam z tym zagadnieniem pozwoliła by Ci rozwiązać zagwozdkę. Maleware nie jest szkodliwe per say dla przeglądarki, tylko dla systemu. Np. wirus. Ludzie, niestety, mają tendencje klikania w “Hermina z Harrego Potera całowała się z Hagridem.avi” i zawsze będą mieli. Ta ochrona daje szansę ostrzeżenia użytkownika przed tym. Żadna poprawka przeglądarki (które przecież są wypuszczane na bieżąco) nie pomoże.

Cała Twoja linia ataku opiera się na założeniu, że Google kontroluje i może wykorzystywać listę w złej woli. Czy obalenie tego (i wykazanie kto i na jakich zasadach przygotowuje listę) sprawi, że spędzisz najbliższe miesiące przepraszając w tych wszystkich miejscach w których siałeś podejrzenia i oskarżenia?

Hej, Gandalf (zbraniecki)! Wiedziałem, że wcześniej czy później się gdzieś pojawisz, w końcu stanowisko pijarowca Mozilla Corp. do czegoś zobowiązuje ;-).

“O, hej BarZilla :) Dawno Cie nie widzialem… czekaj… od kiedy? Ah wiem! Od kiedy zaatakowales mnie”

Niezwykle mi przykro, że moją kulturalną wypowiedź nazywasz “atakiem”. Jednak jeszcze bardziej było mi przykro, że zdecydowałeś się na jej ocenzurowanie (tj. nieopublikowanie) na swoim blogu. To chyba jest część tej “otwartości”, o której tyle trąbi Mozilla… Napisałeś wprawdzie jakieś uzasadnienie tej decyzji, ale niezbyt przekonujące… Tak się zaczęła nasza niezbyt długa i niezbyt owocna korespondencja e-mailowa.

“przekonujac, ze sie nie znam, nic nie rozumiem, i nie mam pojecia jakie ciemne sily w Mozilli wspolpracuja z Google aby zdobyc swiat, a ja odpisalem Cie dluugasnego maila… tak, chyba od wtedy”

Twój e-mail składał się głównie z erystyki, a na erystyczny ping-pong z pijarowcami jakoś szkoda mi czasu, wybacz, wolę się zająć czymś bardziej konkretnym.

“Dobrze wiedziec, ze zyjesz i energia Cie rozpiera :)”

Ja też się cieszę, że u Ciebie wszystko w porządku :).

“Co do meritum.
1) Lista stron podejrzanych jest zdaje sie z Symantec Phishing Group.”

Lista stron (a właściwie hashy) jest pobierana z serwerów Google. Konkretnie przeglądarka (FF3) łączy się z: 1. w celu odświeżania lokalnej listy hashy - z adresem (z odpowiednimi parametrami) http://safebrowsing.clients.google.com/safebrowsing/downloads (wartość ustawienia browser.safebrowsing.provider.0.updateURL w about:config); 2. w celu pobrania pełnego hasha - z adresem (z odpowiednimi parametrami) http://safebrowsing.clients.google.com/safebrowsing/gethash (wartość ustawienia browser.safebrowsing.provider.0.gethashURL w about:config). W obu przypadkach używa metody POST i przesyła/odbiera dane mniej-więcej zgodnie z protokołem, do którego link jest w komentowanym wpisie. (Nawiasem mówiąc, przeglądarka łączy się też z Google w celu pobrania klucza, potrzebnego przy weryfikacji update’ów: jest to adres https://sb-ssl.google.com/safebrowsing/newkey - wartość ustawienia browser.safebrowsing.provider.0.keyURL w about:config.) Każdy to może stosunkowo łatwo zweryfikować - wystarczy uruchomić lokalny sniffer/analizator pakietów, włączyć FF na domyślnych ustawieniach, wejść na jakąś “neutralną” stronę (np. about:blank) i poczekać godzinkę czy dwie, a później przejrzeć, co złapał analizator pakietów.

“ 2) Co do pytania o “maleware” - wydaje mi się, że chwila sam na sam z tym zagadnieniem pozwoliła by Ci rozwiązać zagwozdkę. Maleware nie jest szkodliwe per say dla przeglądarki, tylko dla systemu. Np. wirus. Ludzie, niestety, mają tendencje klikania w “Hermina z Harrego Potera całowała się z Hagridem.avi” i zawsze będą mieli. Ta ochrona daje szansę ostrzeżenia użytkownika przed tym. Żadna poprawka przeglądarki (które przecież są wypuszczane na bieżąco) nie pomoże.”

Mówiąc inaczej: rozwiązania w softwarze nie mogą służyć (bo niejako z definicji będą nieskuteczne) do rozwiązywania problemów spoza domeny software’owej. Cieszę się, że potwierdziłeś mój punkt widzenia na tą sprawę :-). (Nawiasem mówiąc, polecam artykuł o The Dumbest Ideas in Computer Security, punkt #2.)

“Cała Twoja linia ataku”

I znowu używasz słowa “atak”, w zupełnie nieuzasadniony sposób. Erystyka.

“opiera się na założeniu, że Google kontroluje i może wykorzystywać listę w złej woli.”

To, że to tylko i wyłącznie od Google zależy kiedy i jakie strony zablokować, nie jest żadnym założeniem, a faktem — dane dla usługi “safebrowsing” pochodzą z serwerów Google.
To, że istnieją techniczne możliwości wykorzystania przez nich tej usługi “w złej woli” jest również faktem. Dla dalszej dyskusji poprosiłbym o ściślejsze zdefiniowanie “złej woli”. Czy np. “złą wolą” będzie to, że Google może wykorzystywać dane zebrane podczas działania usługi “safebrowsing” w FF ze swoimi partnerami biznesowymi, pomimo tego, że większość użytkowników o tym nie wie?

“Czy obalenie tego (i wykazanie kto i na jakich zasadach przygotowuje listę) sprawi, że spędzisz najbliższe miesiące przepraszając w tych wszystkich miejscach w których siałeś podejrzenia i oskarżenia?”

Znowu erystyka. To jest pytanie z gatunku “kiedy przestał pan bić swoją żonę”. Pozostawię to bez komentarza.

—
Tak nawiasem mówiąc, to miałbym kilka krytycznych uwag odnośnie tego, co ostatnio wyprodukowałeś w swoim blogu, ale pamiętając o tym, że nie dopuściłeś do publikacji mojego “niewygodnego” komentarza (przy innym wpisie) daruję sobie pisanie tam… Hmm, chyba mam jeszcze jeden powód, dla którego warto założyć swojego bloga — z przyjemnością dokonam rozkładu na czynniki pierwsze Twoich PRowych tekstów ;-), nierzadko pustych treściowo i merytorycznie, za to pełnych okrągłych zdań i przyjemnych niezobowiązujących ogólników…

Zauważ jak sam budujesz rzeczywistość wokół siebie:

1) Ja Twoje komentarze uznaje za atakujące i FUDujące. Ty za kulturalną wypowiedź.
2) W efekcie ja wycinam Twój FUD, ponieważ uważam go za nieuprawniony i szkodliwy, Ty zaś to samo nazywasz cenzurą prawdy.
3) Ja kontaktuje się z Tobą na mailu, aby wytłumaczyć mój (prywatny) punkt widzenia i powody, dla których zdecydowałem się ten FUD wyciąć, choć nigdy tego nie robię. Ty uznajesz, że wytłumaczenie nie było wystarczające
4) Ja poświęcam dalej swój czas aby kontynuować tłumaczenie Ci powodów, punkt po punkcie, Ty przestajesz odpowiadać. Następnie po miesiącu tłumaczysz tutaj, że to dlatego, że “szkoda Ci było czasu” naswet nie kwapiąc się, żeby napisać “sorry, nie będę dalej rozmawiał, bo coś tam” - zdziwi Cie jak napisze, że Twoje wytłumaczenie mnie nie przekonuje? Dodatkowo deprecjonujesz wartość moich poglądów, przekonań i argumentów nazywając to “erystyką PRowca” - czyli na dodatek szufladkujesz mnie odbierając mi prawo do posiadania własnego zdania i tym samym dając sobie prawo do ignorowania go.
5) Następnie wracasz dłuższy czas potem, aby dalej szerzyć swoje oskarżenia tym razem tutaj… Czy mam rozumieć, że dyskusja z Tobą na argumenty znowu skończy się tym, że przestaniesz odpowiadać, kiedy przestanie Ci to odpowiadać i zredukujesz dysonans poznawczy szufladkując mnie, stosując atak personalny (’PRowiec, mówi tak, bo mu płacą’)?

Nie widziesz nic błędnego w swoim zachowaniu? Albo inaczej. Znasz definicje i historie takich gwiazd polskiego Internetu jak np. Ekspert? Arnold Buzdygan? Wiesz co ich cechowało? Podobne zachowanie…

Ja nie twierdze, że nie masz racji, ja tylko twierdzę, że unikasz przyznania się do błędów i wolisz siać FUD niż go wyjaśniać. Szkoda.

1) Ja wiem, że lubisz powtarzać jak to wiele wiesz, ale mówisz wiedzę oczywistą. Opisujesz mechanizm pobierania listy z przeglądarki, a nie odnosisz się do zdania kto przygotowuje listę.

2) Przyznam, że nie rozumiem Twojej wypowiedzi. Cały czas poruszamy się w strefie softwarowej, więc? Czy w ramach poprawiania sobie humoru, mogę tak jak Ty napisać “Cieszę się, że przyznajesz mi rację i przyznajesz, że się pomyliłeś i zgadza się, że ochrona przed maleware ma sens”
URL który mi podałeś ma jeden błąd logiczny. Zakłada równą wartość szkodliwości wszystkich “badnessów”, podczas kiedy wyeliminowanie kilkudziesięciu/set najgroźniejszych zmniejsza zagrożenie o połowę… choć numerycznie opis jest prawdziwy.

“I znowu używasz słowa “atak”, w zupełnie nieuzasadniony sposób. Erystyka.”

Ty zaś używasz takich określeń jak “ukrywa”, “dogaduje się z Google”, “celowo nie informuje” - mogę też nazwać to erystką czy już mogę FUDem i oskarżeniami bez pokrycia?

“To, że to tylko i wyłącznie od Google zależy kiedy i jakie strony zablokować, nie jest żadnym założeniem, a faktem — dane dla usługi “safebrowsing” pochodzą z serwerów Google.”

Moje zdjęcia na Flickrze pochodzą z serwerów Flickra, ale ja decyduje co się tam pojawi. Ot zagwozdka…

“Znowu erystyka. To jest pytanie z gatunku “kiedy przestał pan bić swoją żonę”. Pozostawię to bez komentarza.”

A szkoda. Nie jest to erystyka (nota bene nadużywasz tego słowa, stosujesz je wszędzie gdzie argumentacja Ci nie odpowiada), tylko pytanie. Dotychczas moja praktyka rozmów z Tobą wskazywała wyłączanie się (to samo robiłeś na forum MozillaPL) kiedy dyskusja przestawała byc pobierzna i zaczynała analizować argumenty. To kolejna wskazówka, że bardziej interesuje Ci napisanie dużymi literami pierwszego komentarza “Mozilla ukrywa!” “Mozilla szpieguje” niż dalsza dyskusja na ten temat… skojarzenia z trollingiem znowu w mocy.

“Tak nawiasem mówiąc, to miałbym kilka krytycznych uwag odnośnie tego, co ostatnio wyprodukowałeś w swoim blogu, ale pamiętając o tym, że nie dopuściłeś do publikacji mojego “niewygodnego” komentarza (przy innym wpisie) daruję sobie pisanie tam…”

Napisz na maila. W końcu jeśli chodzi Ci o dyskusję to nie musisz pisać w komentarzach… A zasady znasz. Jeśli napiszesz o problemie i założysz dobrą wolę drugiej strony - nic się nie stanie. Jeśli będziesz siał podejrzenia, oskarżenia i pomówienia. Musisz liczyć się z wycinaniem. Naprawdę, nie sądze, aby rozróżnienie było trudne.

“z przyjemnością dokonam rozkładu na czynniki pierwsze Twoich PRowych tekstów ;-), nierzadko pustych treściowo i merytorycznie, za to pełnych okrągłych zdań i przyjemnych niezobowiązujących ogólników…”

I znowu próbujesz mnie obrażać. Po co te wycieczki osobiste? Brakuje Ci argumentów innego typu? Czy ja nazywam Twoje argumenty “pustymi”? I jeśli możesz, daruj sobie też używanie słowa “PRowy” - pisałem tak 5 lat temu, 3 lata temu, 8 lat temu… pisałem tak na temat GNU, Linuksa, KDE, Mozilli, Flocka, wolnej kultury i wolnego oprogramowania. Pisałem tak w 2000 roku na grupach newsowych i w 2008 na blogu. Funkcję rzecznika prasowego pełnie od lutego. Ja rozumiem, że łatwiej się ignoruje zdanie adwersarza jeśli się go samego zaszufladkuje, a jego argumenty nazwie “pustymi”, ale myślę, że bardziej to świadczy o Tobie, niż o kimkolwiek innym jeśli nie możesz bez tego poradzić sobie w rozmowie. I psst… blog nic tu nie pomoże, jeśli nadal będziesz zakładał, że rozmówca nie ma nic do powiedzenia, kłamie, pisze “pusto”, i “PRowo”, to będzie to taki sam trolling, jaki uprawiasz teraz. Natomiast założenie, że ktoś ma dobrą wolę, nie jest głupi, ma swoje zdanie pozwala otworzyć się na nową próbe - zamiast “pokonania go w dyskusji”, “otworzenie się na jego punkt widzenia” - nazywamy to w psychologii złożonością poznawczą i jest jednym z elementów inteligencji emocjonalnej. Dobra wiadomość jest taka, że całość jest do wytrenowania. :)

Gandalf, nie zamierzam szczegółowo odpowiadać na twoje bezczelne oskarżenia i ataki osobiste, więc tylko w skrócie: nie FUDuję, nie troluję, nikogo nie pomówiłem, potrafię się przyznać do błędu, jeśli go faktycznie popełniłem (za to ty masz z tym problemy - na forum mozillapl z całą stanowczością twierdziłeś, że w niektórych lokalizacjach domyślną wyszukiwarką jest co innego niż Google; kiedy okazało się, że Google jest wszędzie, kręciłeś nadal).

Najwyraźniej nie czujesz się zbyt silnie w kwestiach technicznych, więc starasz się maksymalnie rozwodnić dyskusję, sprowadzić ją na manowce, stosując nieuczciwe triki (czyli erystykę; przykładem jest zarzucanie przeciwnikowi ataku osobistego, zarazem samemu bezczelnie atakując). Nie zamierzam się w to z tobą bawić. Jeśli masz jakieś konkrety, to o nich napisz, jeśli nie - uważam dyskusję z tobą za zakończoną.

Wracając do meritum, czyli tego, że Firefox może wysyłać dane związane z odwiedzanymi stronami do Google: pisze o tym sama Mozilla w oficjalnym dokumencie, jakim jest “Polityka prywatności Firefoksa” (która jest integralną cześcią EULi w świetle jej punktu 4.). Chodzi o następujący fragment, dotyczący usługi “ochrony przed phishingiem/malwarem” (wytłuszczenie ode mnie):

“While it is possible that a third party service provider may determine the actual URL from the hashed URL sent, (…)”

Tłumaczenie na polski podkreślonego fragmentu (znamienne, że te dokumenty, na które przecież użytkownik musi się zgodzić przy instalacji przeglądarki, nie są przetłumaczone na polski):

“jest możliwe, że zewnętrzny dostawca usługi może ustalić faktyczny URL na podstawie wysłanego hasha URLa”

“Zewnętrzny dostawca” to oczywiście Google.

Jak widać, sama Mozilla pisze, że to jest możliwe. Dlatego myślę, że warto poprawić komentowany wpis, napisać jakieś sprostowanie. Nie warto oszukiwać użytkowników, bo prawda wcześniej czy później i tak wyjdzie na jaw i na dłuższą metę to się obróci przeciwko wam.

(Kopia “Polityki prywatności Firefoksa” w WebCite, na wypadek, jakby coś zmienili.)

BartZilla, Gandalf: z osobistymi wycieczkami znikać na swoje blogi, fora, IM-y i inne. Z bogiem. Będę wycinał od teraz wszystko, co choćby zapachnie bezsensowną kłótnią i przepychanką.

BartZilla:
Firefox wysyła kawałki hashy, nie URL-e. Artykuł podał nieprawdziwą informację i dlatego zdecydowałem się napisać sprostowanie. Nie uważam, że napisałem coś, co mija się z prawdą. Owszem, istnieje prawdopodobieństwo, że Google będzie umiał w niektórych przypadkach wywnioskować, o jakie strony chodzi. Jako dowód, cytujesz politykę prywatności Firefoksa.

Ale cytujesz niedokładnie. Pełen cytat:

While it is possible that a third party service provider may determine the actual URL from the hashed URL sent, Mozilla’s third party service providers have entered into a written agreement with Mozilla not to use any data or other information about or from users of Firefox for purposes other than to provide and maintain their service. In addition, in no event will these third party service providers correlate any Firefox user data with any other data collected through other products, services or web properties of that provider. These third party service providers may inform you about additional notices regarding their applicable privacy policies.

To, czego nie dało się w 100% zabezpieczyć od strony kodu i specyfikacji, zostało zabezpieczone prawnie. Rozwiązanie to pozwoliło dostarczyć bardzo pożądaną funkcję i chronić użytkowników nie tyle przed exploitami błędów w samej przeglądarce, co przed ich własną nieuwagą (np. bankofarnerica.com i setki tysięcy innych).

“Nie uważam, że napisałem coś, co mija się z prawdą.”

Nagłówek tego wpisu (i informacje niżej) brzmi: “Firefox wysyła dane o użytkownikach do Google - nieprawda.”. Hash, pasujący do odwiedzonej strony (nawet jeśli jest to tylko 4-bajtowy fragment hasha), to jest jakaś dana o użytkowniku (tzn. o odwiedzonej przez niego stronie). Podobnie unikalny identyfikator przesyłany wraz z ciasteczkiem dla domeny .google.com.

“Owszem, istnieje prawdopodobieństwo, że Google będzie umiał w niektórych przypadkach wywnioskować, o jakie strony chodzi. Jako dowód, cytujesz politykę prywatności Firefoksa.”

Nie tylko, napisałem też wyżej o ewentualnych możliwościach Google’a. Zamierzam też stworzyć analogiczny projekt do tego, który zademonstruje, co jest możliwe z punktu widzenia “dostawcy usługi safebrowsing” w FF3 (mimo, że Google, wbrew duchowi open-source/free-software, zabrania użycia specyfikacji, więc być może muszę się liczyć z prawnymi retorsjami z ich strony…).

“To, czego nie dało się w 100% zabezpieczyć od strony kodu i specyfikacji,”

Ależ się dało — zamiast wysyłać kawałki hashy możnaby od razu wysyłać całe hashe. Wtedy przeglądarka nie musiałaby się dodatkowo łączyć w celu “weryfikacji”. To jedna kwestia. Inna jest taka, że Firefox nie musi przesyłać ciasteczka Google’a (o ciasteczkach specyfikacja nawet nie wspomina), ale Google ostro zaprotestowało (oferując marną IMO wymówkę), kiedy zgłosiłem to jako bug i zaoferowałem nawet patche. Problem był zgłoszony już w styczniu 2007 roku, pierwotnie dotyczył FF2, ale to jest cały czas nierozwiązana kwestia, również w FF3.

“zostało zabezpieczone prawnie.”

Nie da się tych “zabezpieczających” twierdzeń zweryfikować — Google strzeże bardzo silnie wszelkich informacji nt. działań wewnątrz swojej firmy. Jeśli np. jednak korelują informacje zebrane podczas obsługi usługi “safebrowsing” z danymi zebranymi z innych serwisów — to któż to sprawdzi? Wszystko sprowadza się do kwestii zaufania — jeśli ktoś nie ufa Google, to nie powinien używać FF na domyślnych ustawieniach. Problem w tym, że jakieś 99% użytkowników FF o tym nie wie — w GUI czy w helpie słowo “Google” nie pada, o ile wiem, nigdzie. (Związane zgłoszenie w Bugzilli.)

“Rozwiązanie to pozwoliło dostarczyć bardzo pożądaną funkcję”

Pożądaną przez kogo? Na pewno nie przeze mnie. Albo inaczej - ochrona przed phishingiem być może jest potrzebna, ale nie w formie blacklist utrzymywanych centralnie przez pojedynczą korporację, mającą w dodatku nieposkromiony apetyt na dane dotyczące użytkowników Internetu, a zarazem słynącą z paranoicznej wręcz ostrożności na temat informacji o niej samej.

“i chronić użytkowników”

Faktyczna jakość tej “ochrony” jest dyskusyjna…

“nie tyle przed exploitami błędów w samej przeglądarce, co przed ich własną nieuwagą (np. bankofarnerica.com i setki tysięcy innych).”

W FF2 była tylko “ochrona” przed phishingiem (czyli wyłudzeniami z banków itp.). W FF3, oprócz “ochrony” przed phishingiem, jest jeszcze dodatkowo “ochrona” przed malwarem (czyli tak naprawdę przed czym?). Jest dodatkowa lista URLi oznaczonych jako “złe”. Stąd też dwie opcje związane z tym w about:config i w GUI (browser.safebrowsing.enabled to nie jedyna opcja związana z opisywaną funkcjonalnością; jest jeszcze browser.safebrowsing.malware.enabled — istnieją dwie listy, więc żeby całkiem to wyłączyć, trzeba ustawić obie wartości na false lub też odptaszkować obie związane z tymi prefami opcje w GUI; to tak gwoli informacji).

—
Korzystając z okazji, chciałbym nieco sprostować/uzupełnić to, co napisałem w moim pierwszym komentarzu:

“Jeśli jest na niej obecny, to Firefox prosi Google o wszystkie pełne 256-bitowe hashe, które pasują do danego prefiksu.

Niezupełnie. W założeniu ma być jeden hash, który pasuje dokładnie do odwiedzonej strony/domeny.”

Oczywiście, serwer może zwrócić więcej niż jeden pełny hash per każdy wysłany częściowy hash. Czyli to zacytowane zdanie jest prawidłowe, moje “niezupełnie” było niepotrzebne.
(Ta drobna errata nie zmienia jednak w żaden sposób reszty dyskusji.)

Dobra, ten komentarz powinien być w sumie jako pierwszy, ale wolałem się najpierw upewnić co do kilku rzeczy… Opiszę, jak to faktycznie działa i co z tego wynika (Google może wiedzieć, kto kiedy odwiedził wybraną stronę/strony, nawet bez stosowania jakichś wyuzdanych heurystyk czy dodatkowych informacji - moja początkowa ocena sytuacji była zdecydowanie zbyt ostrożna).

Twój opis stanowi duże uproszczenie, na tyle duże, że jest w zasadzie błędny. Stąd doszedłeś do błędnego wniosku, że “N jest duże” (przypuszczam, że Twój tok rozumowania był następujący: 32-bitowy prefiks pozwala zakodować “tylko” 2^32 = 4294967296 różnych stanów; jest to duża liczba, ale URLi w całym Internecie jest jeszcze więcej, stąd można założyć istnienie kolizji, tzn. identycznych 32-bitowych prefiksów sumy SHA256 wyliczonych z zupełnie różnych URLi; stąd rzekoma niemożność Google’a do ustalenia, jaki adres został odwiedzony).

Zwróć uwagę, że gdyby to działało dokładnie tak, jak opisałeś, to nie byłoby możliwe np. wygodne zablokowanie całej domeny (trzeba by było enumeratywnie określić wszystkie strony (URLe) w tej domenie, co nie byłoby zbyt wygodne, wydajne ani skuteczne…). Dlatego cały ten mechanizm jest bardziej skomplikowany.

(Szczegóły i nazwy plików/metod/itp. są podane dla źródeł FF3.0, FF3.0.1, FF3.0.2 i FF3.0.3, prawdopodobnie też późniejszych…)

Podczas regularnych połączeń z Google są ściągane (i zapisywane w bazie w pliku urlclassifier3.sqlite w katalogu profilu) 4-bajtowe prefiksy hashy SHA256, zgadza się, ale niekoniecznie jeden prefiks per blokowana strona.
W tabeli moz_classifier są dwie kolumny (pola każdego rekordu) z częściowymi hashami: domain i partial_data. W przypadku, kiedy Google chce zablokować całą domenę, jest przysyłany tylko hash dla kolumny domain, a partial_data pozostaje puste. Przeglądarka podczas wejścia na dowolną stronę wylicza hash z domeny (a dokładniej - z dwóch i trzech jej głównych składowych, szczegóły w pliku nsUrlClassifierDBService.cpp w metodzie nsUrlClassifierDBServiceWorker::DoLookup()) i sprawdza, czy 4-bajtowy prefiks jest w lokalnej bazie danych (w kolumnie domain). Jeśli jest (pomijam tu dodatkowe mniej istotne warunki) - wysyła żądanie o pełny hash SHA256, wyliczony z domeny, przeglądarka go odbiera i porównuje z tym wyliczonym. Jeśli są identyczne - pokazuje zamiast strony odpowiedni komunikat (ostrzeżenie o phishingu lub malware; który pokazać decyduje wartość table_id dla danego rekordu).
Z kolei jeśli Google chce zablokować (lub monitorować odwiedziny) tylko część strony (tzn. URLa) lub dokładny cały URL, wtedy, oprócz kolumny domain, zaczyna grać rolę także kolumna partial_data: przesłane wcześniej dane wypełniają dwoma prefiksami hashy obie kolumny: domain i partial_data. Początek tego co się dzieje, jest taki sam, jak przy pustym partial_data, co opisałem wyżej, ale w przypadku pasującego prefiksu domeny jest jeszcze dodatkowo sprawdzany i porównywany z wartością partial_data prefiks hasha wyliczony z całego oraz częściowego URLa (co dokładnie oznacza “częściowego”, nie będę się tutaj rozpisywał; przeczytaj specyfikację albo, nawet lepiej, źródła: kod metody nsUrlClassifierDBServiceWorker::GetLookupFragments(); dość powiedzieć, że maksymalnie możliwych jest kilkadziesiąt kombinacji(*), co pozwala na dużą elastyczność w zakresie możliwości określenia tego, co dokładnie zablokować). Jeśli prefiks z partial_data jest identyczny z prefiksem któregoś z wyliczonych hashy, to jest wysyłane (pomijam tu dodatkowe mniej istotne warunki) żądanie po cały hash i jeśli pełne hashe (ten pasujący wyliczony i ten właśnie odebrany) są identyczne, to przeglądarka pokazuje zamiast strony ostrzeżenie.

Tyle, jeśli chodzi o działanie tego ustrojstwa. Teraz czas na wnioski.

Najważniejszy jest taki, że w drugim przypadku (pełne domain i partial_data) jest ekstremalnie niskie prawdopodobieństwo (praktycznie równe 0), żeby wystąpiło żądanie o pełny hash z powodu odwiedzin innej strony niż ta określona przez dostawcę danych (tzn. Google). Dlaczego? Albowiem żądanie o pełny hash występuje tylko wtedy, kiedy są spełnione dwa (w dodatku powiązane ze sobą) warunki: pasujący prefiks hasha domeny i równocześnie pasujący prefiks hasha całego URLa (lub jego fragmentu). Skutek jest taki, że Google może wiedzieć, jaka strona była odwiedzona. Dlatego właśnie FF wysyła więcej niż jeden hash przy żądaniach o pełny hash — tyle tylko, że, jak wspomniałem w bodajże moim pierwszym komentarzu, dodatkowe hashe nie są w pełni losowo wybierane i serwer może określić, który to hash faktycznie spowodował wysłanie żądania o pełne hashe.
Zdanie z Twojego opisu: “(…) hashowanie jest procesem nieodwracalnym, tj. z URL-a można zrobić hash, ale z hasha nie można zrobić URL-a” jest prawdziwe dla nas, ale nie dla Google. Dlaczego? Albowiem my faktycznie nie mamy możliwości przekształcenia wszystkich prefiksów w URLe/domeny (chyba, że zastosujemy metodę brute-force, co z oczywistych względów (np. ma ktoś listę wszystkich domen i URLi w Internecie?) jest praktycznie niewykonalne). Z drugiej strony serwer (Google) najpierw musiał wyliczyć te prefiksy (bo on je w końcu wcześniej przysłał), a zatem mógł zachować też odwzorowanie “prefiks” -> “URL/domena”, co pozwala mu - po otrzymaniu prefiksu - znaleźć właściwy URL/domenę. (I nie, nie ma tutaj wieloznaczności, albowiem prefiksu z żądania o pełny hash nie należy traktować jako coś, co wybiera któryś z N prefiksów hashy z wszystkich URLi w Internecie, ale raczej jako indeks w posiadanej przez serwer tabeli z przypisaniami “prefiks” -> “URL”, gdzie prefiksy to prefiksy wysłane wcześniej przeglądarce.)

Drugi istotny wniosek (który wynika nawet z Twojego uproszczonego opisu) jest taki, że wysłanie żądania o pełny hash wcale nie musi wiązać się z pokazywaniem ostrzeżenia użytkownikowi - przeglądarka podejmuje decyzję o pokazaniu bądź nie tego ostrzeżenia już po wysłaniu żądania o pełny hash i odebraniu odpowiedzi. A serwer może odpowiedzieć jakkolwiek; w szczególności może zwrócić hashe nie pasujące do żądanego albo nie zwrócić nawet żadnych pełnych hashy, skutkiem czego strona się normalnie wczyta, pełny hash nie zostanie w cache’u i użytkownik nie będzie miał pojęcia, że przed momentem miała miejsce komunikacja z serwerami Google. Specyfikacja nawet wprost przewiduje taki przypadek (pusta odpowiedź i kod 204) — uzasadnia to tym, że w międzyczasie (tzn. między ostatnią aktualizacją lokalnej bazy i wysłaniem żądania o pełny hash) mógł zostać skasowany dany prefiks (prefiksy) w bazie utrzymywanej po stronie serwera.

Biorąc pod uwagę wszystko powyższe trzeba przyznać, że Google jest naprawdę genialne (co nie powinno dziwić, bo oni są znani z zatrudniania dużej ilości naprawdę łebskich ludzi, których odpowiednio motywują do pracy) — udało im się zaimplementować potencjalny spyware w popularnej przeglądarce open-source i tylko od nich zależy, czy i w jaki sposób to wykorzystają (tzn. jakimi danymi “nakarmią” Firefoksa). Dodatkowo mają też oczywiście możliwość dowolnego blokowania dowolnych stron (dowolnym użytkownikom, bo mogą teoretycznie wysyłać zupełnie różne dane różnym użytkownikom(**)).

Warto też nadmienić, że w aktualnej wersji FF3 opisane sprawdzanie hashy (i ewentualne wysyłanie żądania o pełne hashe w razie dopasowania) jest przeprowadzane dla każdego odwiedzanego adresu, ale jest planowane także uruchamianie tego mechanizmu dodatkowo dla każdego zasobu w odwiedzonej stronie (tj. np. dołączonych skryptów JavaScript, plików CSS, osadzonych aplikacji we Flashu, być może też obrazków itd. itp.). Propozycja wyszła od Google, ustawiona jest już w Bugzilli flaga “blocking-firefox3.1+”, więc pewnie będzie tak to funkcjonowało w następnej stabilnej gałęzi FF.(***) (Patche w bugu 453723 wprowadzają pewne optymalizacje, które mają spowodować mniejszą liczbę wykonywanych operacji dla wcześniej sprawdzonych, “czystych” adresów; można to traktować jako przygotowania do rozwiązania kwestii sprawdzania wszystkich zasobów ze strony…)

Mam nadzieję, że cały powyższy wywód przekonał Cię co do tego, że Mozilla słusznie pisze, że Google ma (stosunkowo prostą) możliwość znalezienia odwiedzanych URLi na podstawie wysłanego prefiksu hasha. Pytaj, jeśli coś jest niejasne.

Na zakończenie pozwolę sobie, po raz ostatni, na uwagę odnośnie Twojego tekstu: w świetle powyższego Twój opis jest mocno niekompletny. Dlatego, jeśli już tak się bronisz przed wycofaniem IMO wątpliwego tekstu “Firefox wysyła dane o użytkownikach do Google - nieprawda”, to chociaż popraw (albo nakieruj czytelnika na ten komentarz) tekst dotyczący opisu działania tego całego ustrojstwa.

Pozdrawiam (jakaś wersja tego teksu (docelowo mocno poszerzona) ukaże się też na mojej stronie).

—
Przypisy:
(*) Ilość sprawdzanych kombinacji zależy od tego, z ilu komponentów składa się URL. Im więcej poddomen i katalogów w ścieżce, tym więcej będzie sprawdzanych kombinacji. Np. duża ilość kombinacji byłaby dla przykładowego URLa: poddomena1.poddomena2.poddomena3.poddomena4.poddomena.domena.com/sciezka/z/wieloma/kata/logami/plik?param=wart, a mała (właściwie tylko cały URL) dla np.: domena.com/plik.html.

(**) Google może stuprocentowo pewnie określić użytkownika (profil przeglądarki) na podstawie unikalnego identyfikatora w ciasteczku, które jest domyślnie przesyłane zarówno z żądaniami o aktualizację lokalnej bazy, jak i z żądaniami o pełny hash.

(***) W Google Chrome prawdopodobnie już tak jest teraz - w źródłach Chrome są pliki związane ze sprytnym mechanizmem o nazwie “bloom filter”, o którym wspomniał też Ian Fette w swoim komentarzu w Bugzilli.

Akismet chyba znów “zjadł” mój (obszerny) komentarz (z soboty, 27 września)… Czy dałoby się coś na to poradzić? Z góry dziękuję.

Zrobione. Aksimet nie lubi linków w komentarzach i stąd te pomyłki.