Autor blogu jednak stwarza wrażenie, że protokoły Matrix lub XMPP/OMEMO są słabe.
Nie “stwarza wrażenie”, a “oferuje swoją ekspercką opinię o tych protokołach, podpartą kupą doświadczenia i wiedzy, oraz dogłębną analizą.” To nie jakiś random z Internetów, a ekspert szeroko znany w kręgach związanych cyberbezpieczeństwem.
Aplikacja może bardzo dobrze uniemożliwić obniżenie poziomu komunikacji do postaci niezaszyfrowanej i odmówić przyjęcia komunikacji niezaszyfrowanej, nawet jeśli protokół pozwala również na pisanie komunikatorów bez szyfrowania
Może, ale jest to dodatkowa rzecz, która musi być dobrze, poprawnie zaimplementowana, i nie zepsuta przypadkiem w następnych wersjach. Kolejny skomplikowany element i tak już nieprawdopodobnie skomplikowanego systemu. A Matrix nie ma zbyt dobrej historii nie popełniania durnych błędów w implementacji własnego protokołu: arstechnica.com/…/matrix-patches-vulnerabilities-…
Mało tego, musi to też być dobrze zakomunikowane dla osób korzystających, które będą musiały zrozumieć to, że jakaś część komunikacji w danej aplikacji może być nieszyfrowana, i uważać na to, czy w danym momencie komunikują się w sposób szyfrowany, czy nie.
Powtarzam: tworzenie takich aplikacji jest nieodpowiedzialne. To zastawianie pułapek na osoby implementujące, oraz na osoby korzystające. Nie ma tu absolutnie żadnego usprawiedliwienia.
W powiązanym temacie, bezpieczne aplikacje internetowe są możliwe, nawet w świecie, w którym przeglądarki rozumieją niezaszyfrowany protokół HTTP.
Tak, i ataków downgrade na HTTPS były dziesiątki. Dekady zajęło doprowadzenie HTTPS to stanu jako takiego bezpieczeństwa. Zamiast powtarzać ten błąd i wystawiać się na takie ryzyko, lepiej po prostu nie wspierać wysyłania nieszyfrowanych wiadomości.
Chociaż nie poprawia to niczego dla prywatnego użytkownika końcowego, fakt, że siły zbrojne ufają niestandardowemu komunikatorowi opartym na Matrix z poufnymi informacjami
Masz rację, to nie poprawia niczego dla prywatnego użytkownika końcowego. Bundeswehra korzysta z własnej wersji klienta Matriksa (BwMessenger) – o ile się założymy, że tryb nieszyfrowany jest kompletnie wycięty? Mało tego, korzysta z niego we własnej, zamkniętej sieci. Idę o zakład, że ta sieć jest dodatkowo szyfrowana na niższym poziomie.
może wskazywać, że sam protokół nie implikuje słabego szyfrowania.
Sam protokół niczego nie “implikuje”, on po prostu dopuszcza możliwość komunikowania się w sposób nieszyfrowany. I to jest problem, którego porządny protokół komunikacji w 2025r. po prostu nie powinien mieć.
Prawdziwym żalem jest to, że obecnie nie wydaje się istnieć żadna aplikacja końcowego użytkownika, która byłaby otwarta, federacyjna, przyjazna dla użytkownika i bezpieczna.
Albo wystąpiłyby techniczne wady, albo byłaby scentralizowana, co narażałoby użytkowników na ryzyko uzależnienia od dostawcy i gównowacenia.
Ryzyko zgównowacenia istnieje zawsze, decentralizacja je zmniejsza. Zmniejsza je również na przykład nie bycie startupem mającym generować zyski dla inwestorów. Signal zarządzany jest przez fundację, która takim startupem bardzo mocno nie jest. Więc akurat nie mam problemu z polecaniem Signala, choć chciałbym, by był federowany rzecz jasna.
Takie gadanie, że wszystko do dupy, tylko utwierdza ludzi w przekonaniu, że to nie ważne, z czego korzystają, skoro wszystko syf. I zostają na Telegramie. Nie wiem, czy to jest efekt, na którym Ci zależy.
Pracowałem z dziennikarkami i dziennikarzami śledczymi oraz ich źródłami, w tym osobami zajmującymi się publikacją Panama Papers. Odpowiadałem za ich bezpieczeństwo cyfrowe. Z mojego doświadczenia wynika, że wspieranie w jednej aplikacji szyfrowania end-to-end i wiadomości nie szyfrowanych w ten sposób wcześniej czy później doprowadza do tego, że ktoś nie ogarnia różnicy i komunikuje się w sposób nie szyfrowany end-to-end będąc przekonanym, że komunikacja jest w pełni szyfrowana.
Mało tego, nawet jeśli dana osoba korzystająca jest w pełni uważna i nie popełni sama takiego błędu, sam fakt istnienia możliwości wysłania wiadomości nie szyfrowanej end-to-end oznacza możliwość przeprowadzenia tzw. “downgrade attacks”.
Moim zdaniem, podpartym ponad dekadą doświadczenia w cyberbezpieczeństwie, tworzenie aplikacji, która miesza szyfrowanie end-to-end z nieszyfrowanymi wiadomościami jest skrajnie nieodpowiedzialne.
Jeśli możliwe jest wsparcie szyfrowania end-to-end w danej aplikacji, nie ma żadnego powodu, by jakakolwiek komunikacja odbywała się w jakikolwiek inny sposób.
Zdecentralizowane system też, choć oczywiście trudniej je kontrolować (o ile są wystarczająco rozproszone).
Nie można już w spokoju polecać usług komunikacyjnych, które nie są federowane.
Pewnie. Bardzo chciałbym, by istniała realna, zdecentralizowana alternatywa dla Signala, która zapewnia taki sam poziom prywatności i bezpieczeństwa. Ale jeszcze jej nie widziałem. Polecanie osobom korzystającym z Signala czegoś, co nie zapewni im podobnego bezpieczeństwa, jest nieodpowiedzialne.
Zdecentralizowane projekty, które wydają mi się obiecujące w tej przestrzeni (nie mówię, że inne nie istnieją, to bardzo subiektywna lista):
I bardzo dobrze. Szanse na wywrócenie stolika się pojawiają regularnie, tylko trzeba być na taką szansę gotowymi.
Fedi było sobie w cieniu i rozwijane po cichu przez dekadę zanim Musk przejął Twittera – a wtedy było już ~gotowe, i dużo na tym zyskało. Tak samo Lemmy.
Więc jak najbardziej taka praca u podstaw jest niezbędna i cenna.
Ponieważ XMPP nie jest na dzień dzisiejszy potencjalną alternatywą, przynajmniej nie w zakresie prywatnej, szyfrowanej komunikacji. Mówię to z żalem, jako osoba, która odpaliła i zarządzała kilkoma serwerami XMPP już ponad dekadę temu. XMPP znacznie się poprawiło przez te lata, ale jeszcze sporo mu brakuje do zapewnienia odpowiedniego poziomu bezpieczeństwa:
OMEMO is not the worst attempt at making XMPP encrypted (see: XEP-0027 for that), but it still doesn’t meet the bar for the kind of private messaging app that Signal is, and is not a viable competitor to Signal.
To understand why this is true, you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can).
Cały post jest wart lektury, nurkuje w problemy z XMPP znacznie głębiej. Warto też przeczytać bardziej ogólny post Soatoka (linkowałem go w tym wątku poprzednio): soatok.blog/…/what-does-it-mean-to-be-a-signal-co…
W artykule nie sugeruję też np. Cwtch, który moim zdaniem jest ciekawszym podejściem do stworzenia w pełni szyfrowanej, zdecentralizowanej alternatywy dla scentralizowanych komunikatorów – ponieważ artykuł w OKO.press kierowany jest do osób raczej nietechnicznych, a Cwtch nie jest jeszcze gotowy na takie osoby korzystające.