W dniu dzisiejszym – jedna z większych afer związanych z „prywatnością” od lat oraz dwa interesujące case study od Facebooka.
Zapraszamy do lektury!
W dniu dzisiejszym – jedna z większych afer związanych z „prywatnością” od lat oraz dwa interesujące case study od Facebooka.
Zapraszamy do lektury!
No, chyba takiej “inby” jeśli chodzi o tematy związane ze śledzeniem obywateli nie było od czasu, gdy w 2013 roku Edward Snowden wyjawił tajniki programu PRISM (tak, od tamtej pory minęło już prawie 10 lat). Od tamtego czasu wprawdzie takie firmy jak Palantir czy wspominany dzisiaj Pegasus pojawiały się w mediach (min. w kontekście zakupu ich usług przez Polski rząd), jednak chyba nigdy jeszcze sprawa nie była tak “gruba”.
W ramach śledztwa Amnesty International udało się ustalić ponad 50 tys. ofiar Pegasusa, oprogramowania działającego jak spyware i w założeniach służącego do walki z terroryzmem.
Badacze NGOsa opublikowali również narzędzie, którym można sprawdzić, czy nasz telefon nie był przypadkiem zaatakowany. Wyciek udowodnił, że narzędzie nie jest wykorzystywane tylko do walki z terrorystami, ale że rządy w wielu krajach używają go również do śledzenia nie tylko aktywistów, dziennikarzy czy prawników, ale w niektórych przypadkach również ich rodzin. Sprawę świetnie opisał nasz Niebezpiecznik, publikując artykuł o wycieku, w którym znajdziecie znacznie dokładniejszy opis sytuacji, niż ja jestem w stanie przygotować w paru akapitach naszego przeglądu. Bardzo zachęcam do lektury.
To, że sytuacja trochę przycichła, nie oznacza jednak, że NSO Group (twórcy Pegasusa) nie muszą liczyć się z pewnymi konsekwencjami. Na pewno wszelkie przyszłe informacje o użyciu ich oprogramowania będą mocniej kontestowane. Dodatkowo, firma zaczęła “śmierdzieć” – przykładowo, Amazon po publikacji raportu w którym tylko wspomniana była nazwa ich usługi CloudFront, natychmiast zdecydował się usunąć konto firmy. NSO Group z pewnością może spodziewać się też dalszych kroków, bo teraz, gdy sprawa się ciutkę “rypła”, rządy używające usługi zaczynają dostawać bardzo niewygodne pytania.
Zawsze gdy widzę tego typu temat, przypomina mi się fascynujący esej Franka Riegera z 2005 roku. Przeczytałem go lata temu, często wracam do niego myślami i zauważam, jak bardzo prorocza była jego wizja świata, w którym walka z oprogramowaniem inwigilacyjnym została przegrana wraz atakiem na World Trade Center. Spędziłem dobre pół godziny grzebiąc po swoich archiwach, żeby go dla Was odgrzebać, dlatego mam nadzieje, że docenicie . Jeden z lepszych manifestów dotyczących etyki w inżynierii oprogramowania z jakim miałem kiedykolwiek styczność.
Pozostając w temacie bezpieczeństwa, czas przyglądnąć się ciekawym ruchom Facebooka jeśli chodzi o rozwój WhatsAppa. W zeszłym tygodniu podzielili się oni bowiem ze światem ciekawym case study, dotyczącym styku prywatności użytkownika i szeroko rozumianej użyteczności.
Kryptografia używana w nowoczesnych komunikatorach sama w sobie jest trudnym problemem, a jeżeli dodatkowo chcemy np. zapewnić synchronizacji wiadomości między poszczególnymi urządzeniami – wyzwanie jeszcze dodatkowo wzrasta. Dlatego do tej pory WhatsApp posiadał sporo ograniczeń – był przypięty tylko do pojedynczego urządzenia, które stanowiło “pojedynczy punkt prawdy”. Każdy inny sposób użycia (jak np. przeglądanie wiadomości z komunikatora na laptopie) tak naprawdę sprowadzało się do komunikacji nie z jakimś centralnym serwerem, a z własnym telefonem. W wypadku gdy takowy tracił baterie, również zewnętrzne urządzenia nie mogły dostać się do listy wiadomości.
Facebook zdecydował się rozwiązać problem za pomocą multibroadcastu. Każde urządzenie posiadać ma własny klucz szyfrujący, a każda wiadomość użytkownika trafiać ma teraz nie do pojedynczego klienta, a do całej ich listy, gdzie każdy z osobna przetrzymuje już wyłącznie lokalne zmiany. Dzięki temu firma unika trudnego problemu dzielenia głównego klucza, po prostu wysyłając wszystkie wiadomości wszędzie.
Jest to podejście mające swoje wady. Tak naprawdę w dalszym ciągu nie istnieje żadna forma globalnego backupu. Jeżeli użytkownik zgubi wszystkie swoje urządzenia, nie będzie mógł odzyskać swojej historii wiadomości, co jest możliwe np. w przypadku iMessage, używającego iCloud jako sposobu na synchronizacje urządzeń End-to-End. Fakt, że nawet taka firma jak Facebook od lat nie jest w stanie zapewnić tego poziomu funkcjonalności pokazuje, jak wielka przewaga kryje się w pełnej kontroli całego ekosystemu. A jak ważna rolę pełnią dziś komunikatory, niech uzmysłowi prosty fakt: od lat mówi się, że to własnie iMessage stanowi najpotężniejszego konia trojańskiego Apple, tak mocno trzymającego ludzi w ich ekosystemie.
Oczywiście, całość jest trochę bardziej skomplikowana niż byłem w stanie to tutaj przedstawić. Jeśli ktoś jest zainteresowany szczegółami – WhatsApp opublikował Whitepaper zawierający więcej detali.
Wspomniane zmiany w WhatsAppie to jednak nie jedyna ciekawa publikacja udostępniona w zeszłym tygodniu przez Facebooka. Podzielili się również wrażeniami z olbrzymiej migracji danych – procesu przejścia firmy na MySQL 8.
Czy też macie czasem wrażenie, że o MySQL jest bardzo cicho? Kiedyś “domyślna” baza dla aplikacji, dziś została wręcz zupełnie wyrugowana z tej roli przez Postgresa. Ciężko mi powiedzieć co jest powdem – czy jego licencja, czy fakt łatwej dostępności w rozwiązaniach chmurowych (aczkolwiek to nie jest tak, że tam jakoś brakuje wsparcia dla MySQL), czy też łatka rozwiązania przeznaczone dla PHP, co u niektórych (dziś już mocno bezpodstawnie) ciągle kojarzy się z amatorką.
I rozumiem jeżeli tego typu decyzje podejmowane były przez doświadczonych administratorów baz danych, analizujących wydajność konkretnych silników. Gdzie tam – dzisiejszy programista (generalizuje, ale tylko trochę) prawie na bazach się nie zna (już prędzej tych NoSQL) i ciężko jest wydusić z niego jakieś merytoryczne argumenty – przyznam że czasem trochę “trollersko” próbowałem. Po prostu mamy do czynienia ze starym, dobrym “nikogo nie zwolnili za użycie PostgreSQL”.
Dlatego też lubię poczytać sobie czasem interesujące przykłady użycia MySQL, jak ten opublikowany przez Facebooka – okazuje się bowiem, że baza ta w dalszym ciągu stanowi trzon największej sieci społecznościowej na świecie. W swoim case study opisują oni bowiem proces migracji z ciut juże prehistorycznej wersji MySQL 5.6 na aktualniejszą (wydaną w 2018) wersję 8. Dlaczego nie użyć najświeższego wydania? Otóż okazuje się, że wspomniana migacja… trwa już kilka lat. Facebook posiada dużą ilość niestandardowego kodu – ponad 1700 poprawek w swojej własnej “gałęzi” MySQL 5.6. Nawet pomimo regularnego przenoszenia ich do wersji 8.0, firma cały czas dodaje więcej niestandardowych funkcji do wersji 5.6, więc zmigrowana “ósemka” musi nadganiać.
Dodatkowo, decyzja o pominięciu dużego wydania 5.7 (MySQL ma niestandardową numeracje kolejnych wersji – 5.6 -> 5.7 -> 8) sprawiła sporo problemów, a to ze względu na niektóre deprekacje API. Pokazuje to, że czzsem nie warto zbyt długo czekać z aktualizacją zależności – można się zdziwić jakie będą skutki.
Mimo, że cały proces nie został jeszcze ukończony, twórcy twierdzą że niektóre benefity wydania 8 już są zauważalne, więc całość kończy się na optymistycznej nucie. Post ten na pewno będzie najbardziej interesujący dla tych, których intersują bazy danych, ale w zasadzie powinien stanowić swoistą przypowieść dla każdego, kto nie miał w swojej karierze epizodów z wychodzeniem z systemów legacy.