“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.)”

Po moim zwróceniu uwagi na IRCu Gavin wysłał zgłoszenie 471299 dotyczące tej kwestii…

“(…) 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 (…)”

Trochę nad tym myślałem i ogólnie rzecz biorąc to jest raczej zbyt daleko posunięty wniosek: w przypadku pojedynczego i odosobnionego requestu o pełny hash jest pewne pole na wieloznaczność…

“(…) 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.”

Ten projekt, implementujący protokół “safebrowsing wersja 2″, demonstruje tą kwestię, jak i inne związane z domyślnie włączoną “ochroną przed phishingiem/malwarem” w Firefoksie 3.

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.

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.)

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).

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.)

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. :)