Skip Navigation

dreiwert

@ dreiwert @szmer.info

Posts
15
Comments
58
Joined
4 yr. ago

  • Aptoide pozywa Google za rzekomy monopol

    Jump

  • [rules] Impossible effect (Tom Bombadil)

    Jump

  • Thanks. My bad. I missed the fact that in newer cards (and thus also Tom Bombadil), "on the bottom of your library in any order" became "on the bottom of your library in a random order".

  • [rules] Airbending and cast triggers

    Jump

  • Interestingly, various review sites which cover the airbend mechanic only mention leaves- and enters-the-battlefield triggers. But the rules explicitly state "cast it" in 701.65a.

  • MTG @mtgzone.com
    dreiwert @szmer.info
    rules

    Airbending and cast triggers

  • Kultowa biblia programistów coraz bliżej zamknięcia. Zabija ją sztuczna inteligencja

    Jump

  • Tęsknię za Usenetem...

  • Kultowa biblia programistów coraz bliżej zamknięcia. Zabija ją sztuczna inteligencja

    Jump
  • wolny internet @szmer.info
    dreiwert @szmer.info

    Kultowa biblia programistów coraz bliżej zamknięcia. Zabija ją sztuczna inteligencja

    ithardware.pl /aktualnosci/portal_programista_sztuczna_inteligencja-38022.html

  • X mści się za karę od UE - usunął konto reklamowe Komisji Europejskiej, Sikorski odsyła Muska na Marsa

    Jump

  • Można mieć nadzieje, że inne organy wykonawcze wyciągną z tego wnioski. O ile nie chce się, aby za każdym razem, gdy jakiś oligarch z Stanów otrzyma mandat w UE, konto zostało usunięte lub zablokowane.

  • „Shadow profiles” – co to jest, jak temu przeciwdziałać

    Jump

  • Może pozew zbiorowy byłby fajną rzeczą.

  • Prasówka z cyfryzacji 22-26.09.2025

    Jump

  • Co najmniej dwie wiadomości (25, 26) sugerują, że powinno być bardziej przejrzyste, z jakimi danymi są trenowane LLM.

  • Miasta w 3D z OpenStreetMap

    Jump

  • Czy można wnieść wkład poprzez nagrywanie i przesyłanie własnych tracków, tak jak w przypadku 2D OSM?

  • Prasówka z cyfryzacji 16-27.06.2025

    Jump

  • Trochę zwodniczy nagłowek: Zakaz szkolenia AI dotyczy tylko jedynej instancji Mastodona, nie całej sieci.

  • Popularny komunikator Telegram nie jest bezpieczny, ma powiązania z rosyjskimi służbami

    Jump

  • 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 @soatok@furry.engineer 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ń (@mollyim@fosstodon.org).

  • Popularny komunikator Telegram nie jest bezpieczny, ma powiązania z rosyjskimi służbami

    Jump

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

  • Popularny komunikator Telegram nie jest bezpieczny, ma powiązania z rosyjskimi służbami

    Jump

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

  • Popularny komunikator Telegram nie jest bezpieczny, ma powiązania z rosyjskimi służbami

    Jump

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

  • Nowa „szyfrowana” funkcja XChat (exTwittera) nie wydaje się być bardziej bezpieczna niż jej poprzedniczka.

    Jump

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

  • Proces w sprawie antymonopolowej przeciw meta

    Jump

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

  • wolny internet @szmer.info
    dreiwert @szmer.info
    ANG

    Pluralistic: Canada shouldn’t retaliate with US tariffs; Picks and Shovels Chapter One (Part 6 – CONCLUSION) (15 Jan 2025) – Pluralistic: Daily links from Cory Doctorow

    pluralistic.net /2025/01/15/beauty-eh/

  • Proces w sprawie antymonopolowej przeciw meta

    Jump

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

  • List otwarty ws. cyfrowej suwerenności

    Jump

  • W ramach wojny taryfowej, być może podatek cyfrowy faktycznie będzie brany pod uwagę.

  • Poweekendowa prasówka z cyfryzacji

    Jump
  • Minetest community @lemmy.ml
    dreiwert @szmer.info

    Using 3D scanned objects in Minetest

    gitlab.imn.htwk-leipzig.de /imocsy/lo-tek/-/wikis/object2minetest.en
  • EDV-Sicherheit @feddit.de
    dreiwert @szmer.info

    Zugang zu Hochschul-VPN nur mit ungepflegten Endgeraeten?

    itsz.htwk-leipzig.de /serviceangebote-dienste/vpn-zugriff-auf-das-hochschulnetz/linux
  • Fediverse @lemmy.ml
    dreiwert @szmer.info

    Best way to run a blog in the fediverse?

  • Open Source @lemmy.ml
    dreiwert @szmer.info

    Towards federated git collaboration

    github.com /go-gitea/gitea/issues/14186
  • Fediverse @lemmy.ml
    dreiwert @szmer.info

    Towards federated git collaboration

    github.com /go-gitea/gitea/issues/14186
  • Fediverse @feddit.de
    dreiwert @szmer.info

    Technisch begruendete Bedenken gegen Mastodon?

    www.heise.de /meinung/Interview-Grosse-Bedenken-auf-Mastodon-zu-setzen-aus-technischer-Sicht-7477138.html
  • Lemmy @lemmy.ml
    dreiwert @szmer.info

    Notification to linked site?

  • Fediverse @feddit.de
    dreiwert @szmer.info

    Lemmy-Community rund ums Studium