dreiwert

joined 2 years ago
[–] [email protected] 0 points 6 days ago

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.

Nie ma co do tego wątpliwości. Widzialem wiele wysokiej jakości treści tego autora. Nie zmienia to jednak fakto, że w tym konkretnym przypadku doszło do pomylenia "protokołu" i "wdrożeń", co doprowadziło do błędnego rozumowania.

Na marginesie, uznanie jako ekspert ds. bezpieczeństwa nie uniemożliwia wnoszenia bardziej zróżnicowanego wkładu w debatę na temat komunikatorów: https://www.messenger-matrix.de/messenger-matrix-en.html

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: https://arstechnica.com/information-technology/2022/09/matrix-patches-vulnerabilities-that-completely-subvert-e2ee-guarantees/

Tak, niewątpliwie nie wykonali bardzo dobrej pracy, dostarczając wdrożenie referencyjne. Fakt, że Matrix stał się na tyle ważny, że powstają konkurencyjne implementacje zarówno dla serwera, jak i klienta, dodaje mi jednak nadzieję.

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.

Aby nie wymagać od użytkowników niezorientowanych technicznie, że zrozumiają, kiedy komunikator zmienia do komunikacji niezaszyfrowanej, aplikacja powinna po prostu odmówić udział uw komunikacji niezaszyfrowanej, nawet jeśli protokół na to pozwalałby w sieci.

Jeśli jednak zgodzimy się, że musimy chronić użytkownika przed samym sobą, Signal również wymaga ulepszenia. O ile wiem, do lutego 2024 roku Signal zawsze przekazywał numer telefonu uczestikom komunikacji. W praktyce umożliwia to przeprowadzenie "downgrade attack": Jeśli atakujący zakłócił zaszyfrowaną komunikację Signal, użytkownicy mogliby zdecydować się na użycie numeru telefonu i komunikowanie się za pośrednictwem sieci telefonicznej, a więc bez E2EE. Rozumiem, że Signal dziś wprowadził opcję nie podawania numeru telefonu innym użytkownikom. Oznacza to jednak, że jeszcze zapewnia opcję obniżenia poziomu zabezpieczeń komunikacji. Dlatego, jeśli chcemy, aby obniżenie oceny było niemożliwe, Signal powinien całkowicie zrezygnować z numerów telefonów.

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.

Zgadzam się, że należy starać się unikać błędów z przeszłości. Po prosto nie jestem pewien, czy to oznacza, że powinniśmy porzucić ideę otwartych i interoperacyjnych protokołów, która kiedyś uczyniła Internet dużym i zróżnicowanym.

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.

Nie znalazłem jeszcze żadnych źródeł, które konkretyzowałyby takie szczegóły. Jeśli takie istnieją, chętnie je przeanalizuję.

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

Zaznaczyłem to twierdzenie, które bardzo przypomina to, co @[email protected] napisał w swoim artykule. Ciągle czekam, aż ktoś będzie w stanie uzasadnić to twiedzenie bez mieszania protokołu z implementacją. Jak już powiedziałem, jeśli aplicacja, z której korzystam, nie umożliwia przejścia na niezaszyfrowaną komunikację, nie widzę powodu (w logicznym, naukowym sensie), dla którego zbudowanie jej na wielozadaniowym protokole, który może również wykonywać różne czynności, miałoby stwarzać jakiekolwiek ryzyko dla bezpieczeństwa. Najgorsze, co mogłoby się zdarzyć, jest to, że ludzie nie będą mogli ze mną rozmawiać, ponieważ moja aplikacja odmówi ich prośbie o niezaszyfrowaną komunikację.

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.

Ja sobie patrzę na Cwtch z nadzieją: https://docs.cwtch.im/

Także ja śledzę to z zainteresowaniem.

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.

Zdecydowanie zrobili kilka rzeczy dobrze. Wciąż uważam, że centralizacja jest ryzykowna. W Stanach Zjednoczonych, uniwersytety również powinny być niezależne, ale przekonaliśmy się, jak bardzo Trumpiści troszczą się o tę niezależność. Nie znam się na fundacjach, i co mogłoby się stać, gdyby stanęły im na drodze.

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.

Wprost przeciwnie. Właśnie skrytykowałem wadliwą argumentację w artykule, który zacytowałeś, a jeśli chodzi o debatę na temat komunikatorów, apeluję o mniej czarno-białego myślenia. Jak rozumiem, Telegram jest tak zły, jak tylko może być, biorąc pod uwagę, że jest scentralizowany i nie ma E2EE. Ale nie widzę ani pojedynczego "dobrego" komunikatora, ponieważ to bardzo zależy od tego, przed jakim modelem zogrożeń chcesz się chronić. I nie wierzę, że bezpieczeństwo można osiągnać bez wysiłku. Tak jak użytkownicy XMPP lub Matrix powinni dwokrotnie sprawdzić swoje wdrożenie i pradwopodobnie zgłosić błędy, jeśli pozwala na ataki typu downgrade, użytkownicy Signal powinni domagać się większej decentralizacji i lepszej integracji z klientami innych programistów. Wydaję się, że nie leży to w najlepszym interesie użytkowników dbających o bezpieczeństwo, aby Signal żądał jednolitej kultury w odniesieniu do oprogramowanie klienckiego (https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165), podczas gdy istnieją deweloperzy klientów, którzy mogą nawet lepiej sobie radzić w kwestii bezpieczeństwa urządzeń (@[email protected]).

[–] [email protected] 1 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

Zgadzam się na co pisałeś o aplikacjach. Autor blogu jednak stwarza wrażenie, że protokoły Matrix lub XMPP/OMEMO są słabe. Moim zdaniem, to błędne rozumowanie, i obniża wartość wysiłków deweloperów pracujących nad wolnymi rozwiązaniami. 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. W powiązanym temacie, bezpieczne aplikacje internetowe są możliwe, nawet w świecie, w którym przeglądarki rozumieją niezaszyfrowany protokół HTTP. 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 (https://element.io/case-studies/bundeswehr), może wskazywać, że sam protokół nie implikuje słabego szyfrowania.

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. Nie chciałbym znaleźć się w sytuacji, w której musiałbym polecać jakiegoś komunikatora. 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.

[–] [email protected] 0 points 2 weeks ago (4 children)

Zgadzam się, że problem z libolm jest naprawdę dołujący. Poza tym, nie zgadzam się w pełni. Autor dyskwalifikuje protokoły z powodu samego faktu, że implementują one również wariant niezaszyfrowany. Nie widzę powodu, dla którego powinniśmy odrzucać bardziej wielofunkcyjne protokoły, o ile możliwe jest zbudowanie interfejsu, który wymusza szyfrowanie.

[–] [email protected] 1 points 3 weeks ago (1 children)

Zcentralizowane platformy zawsze budzą żądzy "zainteresowanych stron", jeśli są wystarczająco popularne. I potem trudno jest ludziom się od tego uwolnić. Nie można już w spokoju polecać usług komunikacyjnych, które nie są federowane.

[–] [email protected] 3 points 4 weeks ago

Powierzanie prywatnej komunikacji oligarsze. Co mogłoby się nie udać?

[–] [email protected] 2 points 1 month ago

Choć może to być bolesne, ale ten cały ruch wydaje się bezsensowny, gdy ignoruje się Big Tech.

[–] [email protected] 1 points 1 month ago

A „oficjalny” oznacza „gwarantujący, że uprawnienia roota pozostają w Stanach”?

[–] [email protected] 1 points 2 months ago

Tak... wiele systemy są pewien, że wie jak powinien być "demokracja". Ale niewiele rozumie, że megakorpy nie są demokratyczne.

[–] [email protected] 2 points 2 months ago (2 children)

Służby kontrwywiadowcze mogły już prowadzić dochodzenie, ponieważ była to już "podejrzewana grupa ekstremistyczna", a więc przynajmniej od 2021 roku (patrz np. https://www.bbc.com/news/world-europe-56250460). Mimo to można mieć nadzieję, że teraz potraktują to poważniej.

[–] [email protected] 5 points 2 months ago (4 children)

Klasyfikacja nie wpłynie na tych wyborców AfDa, którzy na nich głosują, ponieważ są prawicowymi ekstremistami.

 

Pisarz sugeruje, że Kanada powinna zareagować na cła Trumpa nie wprowadzając ceł odwetowych, ale wycofując się z amerykańskich przepisów dotyczących własności intelektualnej. Czy to może być również perspektywa dla Europy?

[–] [email protected] 1 points 2 months ago
  1. Zepsuć wartość dolara
  2. Kupuj wszystkich dolarami
  3. ?
  4. Zysk
[–] [email protected] 1 points 2 months ago (2 children)

System, który chce mieć wolny internet, powinien potrzebować mniej niż jedenaście lat na to.

 

A workflow to scan 3D objects into Minetest voxel buildings targeted at low end hardware.

Comments are appreciated.

 

cross-postowane z: https://szmer.info/post/253278

Are there any universities that offer data recovery related lectures, e.g. in computer science or engineering related study programmes? It seems like there would be much potential in researching different techniques, yet I can't seem to find that topic in universities. Is all that knowledge hidden in privately owned companies?

13
submitted 2 years ago* (last edited 2 years ago) by [email protected] to c/[email protected]
 

What is the best fediverse-compatible service to run a blog (not microblog) on? I see a lot of #writefreely instances, but it doesn't seem too well-integrated. E.g. it seems to be impossible receive comments from #mastodon users. Then there is #plume, but it's harder to find instances and there is information about the software being less well maintained. So, what would be good options? I'd prefer not having to self-host.

 

cross-postowane z: https://szmer.info/post/289222

Git was designed as a decentralized version control system from the ground up. Yet it has been subverted by centralizing hosting and collaboration platforms that compete on projects hosting their code on them. Disagreements on where a project should be hosted regularly result in flame wars. But why, since we live in a world of federated services? If the Git hosters would federate, it might not matter on which server a merge request or an issue is filed.

The #gitea issue targeted at adding #activitypub is still open, but it seems to require in-depth architectural changes. So what would be the best bet for a Git hosting platform to be the first in entering the #fediverse?

 

Git was designed as a decentralized version control system from the ground up. Yet it has been subverted by centralizing hosting and collaboration platforms that compete on projects hosting their code on them. Disagreements on where a project should be hosted regularly result in flame wars. But why, since we live in a world of federated services? If the Git hosters would federate, it might not matter on which server a merge request or an issue is filed.

The #gitea issue targeted at adding #activitypub is still open, but it seems to require in-depth architectural changes. So what would be the best bet for a Git hosting platform to be the first in entering the #fediverse?

 

Der Artikel soll zu hochkochenden Diskussionen gefuehrt haben. Aber warum? Neben Dingen, die man tatsaechlich einmal angehen sollte (Stichwort Redis ueber TLS) sehe ich genau genommen weniger technische Probleme bei Mastodon, sondern eher Kollisionen der Mastodon-Software mit einer persoenlichen Meinung einer Einzelperson, wie technische Systeme funktionieren sollten.

 

Are there any universities that offer data recovery related lectures, e.g. in computer science or engineering related study programmes? It seems like there would be much potential in researching different techniques, yet I can't seem to find that topic in universities. Is all that knowledge hidden in privately owned companies?

 

A Lemmy post will often refer to a specific web link. Is there an API for the linked site to be notified about Lemmy posts referring to it (e.g. to be able to link back, or even to integrate Lemmy comments)?

 

See you there in December!

view more: next ›