Czy raspberry pi może ogrzać dom?

Niezależnie od przyczyn, chociaż trzeba przyznać, że według badań i statystyk Głównym powodem awarii są błędy ludzkie . Obydwa te incydenty pokazały, jak bardzo świat w tym momencie jest uzależniony od dużych dostawców chmurowych. I jak bardzo nieuniknione są awarie, nieważne jakie byśmy mieli dobre systemy, co byśmy robili. Jednak awarie będą się zdarzały, a ich skutki będą odczuwalne coraz bardziej, ponieważ coraz więcej rzeczy jest zależnych od czy to tych usług bezpośrednio, czy usług działających na nich jako na platformach. Kolejnym tematem jest Google Safe Browsing, a dokładniej problemy z tą usługą.

Ale może od początku. Co to jest w ogóle Google Safe Browsing? Jest to usługa uruchomiona przez Google w 2007 roku, której zadaniem jest chronić użytkownikiem przed wejściem na złośliwe strony. Jak to działa? W teorii bardzo prosto. System skanuje miliardy różnych stron dziennie, szukając oznak phishingu, malwareu i innego niebezpiecznego syfu na stronach. Gdy system Google wykluje zagrożenie, dostaje to, dodaje tę stronę do listy niebezpiecznych adresów. Usługa Google Safe Browsing jest zintegrowana z większością przeglądarek. Tak naprawdę ze praktycznie wszystkimi opartymi na silniku Chrome oraz z przeglądarką Firefox i pochodnymi opartymi na jej silniku, a dodatkowo jest też wykorzystywana przez inne platformy bezpieczeństwa.

Ostatnim takim znanym przykładem był projekt IMIH. Jest to otwarta źródłowa alternatywa dla Google Photos. W październiku tego roku IMIH stanął tak naprawdę, można powiedzieć, przed małym kryzysem. Bo wszyscy, którzy próbowali dostać się na jakąkolwiek stronę związaną z tym projektem, byli witani dużą, czerwoną stroną z ostrzeżeniem, na którym był komunikat, że jest to strona zwodnicza. Tak to chyba najlepiej należałoby przetłumaczyć. Deceptive side ahead. Wynikało to z tego, że Google Safe Browsing tak właśnie zakwalifikował tą stronę.

W efekcie, jako że wszystkie strony należące do domeny imich.cloud zostały oznaczone jako niebezpieczne, imich znalazł się odcięty od własnych narzędzi, a wszyscy użytkownicy tak naprawdę stracili dostęp do tego projektu. Podczas sprawdzania, co było powodem tego, okazało się, że flagowane były adresy URL wewnętrznych środowisk projektu, czyli tak naprawdę tymczasowe strony, które były automatycznie generowane dla każdego pool requesta na GitHubie, z takimi typowymi wewnętrznymi adresami, jednak w domenie imich.cloud. Według Google'a i jego systemu, strony te próbowały oszukać użytkowników i nakłonić ich do zrobienia czegoś niebezpiecznego, rzeczy takich jak instalacja oprogramowania lub ujawnienie danych osobowych.

A przynajmniej taka była oficjalna odpowiedź systemu. Co ciekawe, Google Safe Browsing nie flagowało jednej z subdomeny, ale po prostu zastosowało etykietkę niebezpieczna dla całej domeny innych cloud, co skutecznie odciąło wszystko. Zespół odpowiedzialny za projekt imich zareagował tak jak mógł, czyli w Google Search Console wysłali prośbę o przegląd tej strony, wyjaśniając, że strony są ich własnymi wdrożeniami, na ich własnych serwerach, że pod nikogo się nie podszywali, że jest to ich oprogramowanie, które oni sami tworzą, ich infrastruktura, ich narzędzia. I po dwóch dniach dostali wiadomość, że zostało to zaakceptowane, domena została oczyszczona i jest dostępna.

I tak naprawdę w razie czego poświęcenia jednej mniej ważnej domeny, która zostanie oflagowana jako niebezpieczna, aby główna domena mogła być dostępna. Problemem jest to, że jest to obejście problemu, a nie rozwiązanie problemu. A główną przyczyną jest to, że Google Safe Browsing ma całkowicie nieprzejrzystą strukturę. Algorytm Google nie wyjaśnia, dlaczego coś zostało oflagowane. Dostaje się jedynie ogólną informację na temat kategorii, do której strona została zakwalifikowana, czy jest to phishing, czy malware, czy unwanted software, czy coś takiego, ale Nigdy nic więcej, więc trzeba samemu dojść do tego, co było przyczyną, co zostało znalezione przez algorytm, żeby móc to usunąć.

Na przykład w przypadku projektu Jellyfin przyczyną było to, że na stronie głównej projektu była strona logowania i to wyzwalało algorytm Google'a, który kwalifikował stronę jako phishing. Tylko w tym momencie pytanie. Czy to oznacza, że wszystkie strony, które mają ekran logowania powinny być flagowane jako niebezpieczne? Wspomniałem o projekcie Jellyfin. Jellyfin jest to... Otwartość źródłowa alternatywa dla Plex, ale co ciekawe, nie tylko Jellyfin i Imich zostali tak oflagowani. Google Safe Browsing oflagowało też takie otwarte projekty jak Nextcloud, który wielokrotnie był flagowany jako zawierający malware.

Nextcloud jest to tak naprawdę alternatywa dla Google Drive, można powiedzieć. Flagowany był też projekt Unohost, flagowany był N8n, czyli tak naprawdę otwarty źródłowy system do automatyzacji. I jak chyba widać, wspólnym mianownikiem tych wszystkich projektów jest to, że to są projekty alternatywne wobec usług, które czy to zapewnia Google, czy inne duże firmy technologiczne. Co sprawia, że zaczynają się plotki na temat tego, czy była to usterka algorytmu, czy też celowe działanie. Bo system ten pokazuje możliwość dania Google'owi tak naprawdę cenzury swojej konkurencji.

I to cenzury na tyle skutecznej, że praktycznie wycinającej ją z internetu. Zresztą nie oszukujmy się, nie tylko Google ma takie możliwości. Mozilla, Apple, Microsoft, kilka innych firm, które tak naprawdę są w stanie kontrolować, co większość ludzi jest w stanie bezpiecznie, przynajmniej z punktu widzenia przelundarki, odwiedzić w internecie. Są w stanie to wszystko zrobić, bo mają takie właśnie usługi jak Safe Browsing, jak URL filters, walidacja certyfikatów. To są tak naprawdę możliwości techniczne dające im potencjalnie możliwość cenzurowania internetu. I pokazuje to bardzo podobnie jak w przypadku awarii AWS czy Azure, które mieliśmy ostatnio.