Portál AbcLinuxu, 5. května 2025 11:46
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
Matrix |
|
20% (83) |
Signal |
|
31% (125) |
Tox |
|
5% (20) |
jiné open-source |
|
11% (46) |
proprietární |
|
17% (69) |
jiné s šifrováním jako doplňkem |
|
5% (19) |
nešifruji |
|
13% (51) |
IM nepoužívám |
|
23% (93) |
Celkem 407 hlasů
Vytvořeno: 1.6.2020 12:25
Tiskni
Sdílej:
To není šifrovaný instant-messaging, protože IRC server všechno vidí v plain textu. Přece jen máme rok 2020, takže když se řekne šifrovaný instant-messaging, mělo by to znamenat end-to-end šifrování.
Jak může mít uživatel jistotu, že něco nesmrdí někde jinde v aplikaci?Android aplikace lze celkem dobře dekompilovat (i když to licence většinou nepovoluje). Ten výstup není zrovna hezké čtení, ale to konec konců mnoho open source zdrojáků taky ne.
Teoreticky by si to v budoucnu mohlo přes ten mail jen dohodnout jiný komunikační kanál, který by se pro ten hovor použil.Ano, dohaduje se jiný kanál např. pro audio/video konference a pro přenos obrovských souborů (větších než 10 MByte).
Já bych se hlavně spíš obával toho, aby to příliš nefloodovalo inbox (nebo nějakou složku, do které se to bude ukládat)DeltaChat by default vytvoří vlastní adresář "DeltaChat" a do inboxu pouze kouká a emaily pocházející z DeltaChat klientů přesouvá do toho adresáře "DeltaChat". Jinak se chránkou nedělá nic - takže žádný flooding atd. DeltaChat má přímo ve svých cílích pouze "nenápadně" využít stávající infrastrukturu a snaží se maximálně nepoškodit žádná existující "workflow" uživatelů.
aby zprávy neměly tendenci padat do spamuZatím jsem neviděl za těch několik let co se DeltaChat používá mezi tísícovkama lidí (myslím, že to nejsou ještě desetitisíce či více, ale snad brzy ano) s různými email servery, že by se to stávalo. Spam filtr nemá důvod je zahazovat protože jsou šifrované (a podle odesílatelů se dnes již prakticky nefiltruje kvůli příliš velkému množství false positives).
a aby mezi některými servery nebyly (měřítkem IM) příliš dlouhé latence.Praxe ukazuje, že většinou zprávy chodí až překvapivě rychle. Ale samozřejmě je to individuální.
Přecejen se e-mail primárně používá pro spíše méně spíše obsáhlejších zpráv a nejsem si jistý, jestli ohnutí této infrastruktury pro přenos kratších, často jednovětných zpráv, samostatně stojících odkazů apod. nebude způsobovat všelijaké problémy.Žádné mi nejsou známi. No a vzhledem k tomu, že je vše plně e2e šifrované, tak ani žádné neočekávám
Další věc je třeba garantované pořadí doručení, řeší to tam nějak?Ano, je to "nějak" chronologicky seřazené. Technicky myslím, že se "věří" časům, které uvádí odesílatel a nějak bez "skákání/trhání/posouvání" se upozorní na novou zprávů "výše v chatu". Bylo to ještě před pár měsíci hodně horké téma skoro po dva roky (je tam problémů spousta - od banálních typu "odesláno offline a doručeno až mnoho hodin/dní poté" přes nedůvěřování hodinám odesílatele ani žádným z "relay" SMTP serverů atd. až po user experience kdy nechceme linearitu diskuze bořit automatickým skákáním "nahoru" na nově přijatou avšak starou zprávu ale zároveň nechceme, aby diskuze zprávy byly úplně mimo kontext při zařazní "vždy na konec" atd.).
1. kdyz cilova osoba ma klienta, ale nema ho spustenej, prijde ji mail? nebo se nekde decentralizovane vi ze se v klientu nekdy v minulosti prihlasila a ceka se nez si klienta pusti? a doba cekani zalezi na cilovem mail server dle jeho timeout pro doruceni emailu nebo to muj client bude zkouset dokud se doruceni nepodari po tom co cilova osoba zapne klienta?Ano, email přijde vždy a okamžitě (tj. zcela nezávisle, zdali si ho nějaký MUA okamžitě/později/nikdy (ne)vyzvedne). Jakmile si pustí uživatel non-DeltaChat MUA (např. Thunderbird či Outlook), tak tam normálně uvidí nepřečtený email (zprávu od někoho, kdo ji odeslal z MUA DeltaChat) a pokud není šifrovaná, tak si ji může přečíst. Jakmile si ale spustí DeltaChat, tak ten tento email také uvidí (mělo by to být nezávislé na tom, zdali je či není přečtená) a rozšifruje (pokud byl zašifrovaný) a zobrazí (samozřejmě za předpokladu, že Thunderbird ten email nesmazal nebo nepřesunul do nějakého adresáře mimo inbox). Žádné čekání neexistuje, nýbrž pouze běžné "acknowledge received message" schéma. Zpráva tedy má více stavů - minimálně tyto: nejprve je "odeslaná lokálně" (tzn. pokud je DeltaChat offline; žádná indikace fajfkami u zprávy v UI), pak "odeslaná na odesílatelův SMTP" (indikace v UI jednou zelenou fajfkou) a pokud se tomuto SMTP podaří doručit ji a zároveň si ji vyzvedne adresát přes DeltaChat a zároveň si ji adresát přečte (tzn. otevře danou skupinu/chat), tak DeltaChat pošle okamžitě automaticky na pozadí "acknowledge" jako odpověď a potvrzení přijetí (indikace v UI druhou zelenou fajfkou).
2. chapu spravne ze lze mit klienty na pc a telefonu ktere oba budou dostavat notifikace i synchronizovat odeslane zpravy? (po tom co z prvniho prihlaseneho klienta udelam export a jinde import do nove pripravovaneho klienta)Ano, je to tak. Ten export a následný import je potřeba vzhledem k šifrování, resp. přenosu privátních klíčů a konfigurace DeltaChat-specific rozšíření nad rámec Autocrypt bezpečnou cestou. Aktuálně se to dělá exportováním na SD kartu (a rovnou se exportuje i historie zpráv, aby se nemusela na dalším zařízení stahovat), ale je rozpracovaná implementace přenosu těchto informací zcela na pozadí tak, že při přihlášení bude mít člověk možnost se přihlásit buď "bez synchronizace" a nebo prostě "se synchronizací" s tím, že tato druhá volba bude vyžadovat při prvním takovém přihlášení i&ndsp;OTP pro rozbalení dat pocházejících (a na pozadí automaticky se přenášejících) ze zařízení s klíči (tzn. "musím mít zrovna po ruce ten původní mobil, který mi zobrazí to OTP"). Odhaduji, že tento "intuitivnější" způsob bude dostupný zhruba za rok až dva (vzhledem k tomu, že jde o&nbps;"root of truest", tak je nutné delší testování než u ostatních features).
3. z principu vyuziti imap predpokladam nehrozi v budoucnu hlasove natoz video hovory, problem s tim nemam ale videl bych to jako castecnou brzdu pro pouziti u lidi ktere toto aktivne vyuzivajiDeltaChat už má experimentální podporu pro video a audio konference - cílem však není všechno hnát přes IMAP+SMTP (to by byl skutečně nesmysl, pokud ty protokoly nebudou výrazně vylepšeny v tomto ohledu v budoucnu), a tak se jedná spíše o integraci existujících služeb - aktuálně Jitsi Meet (který však již vyžaduje SPOF/centralizaci - konkrétně minimálně rendezvous server pro sestavení spojení přes WebRTC).
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging? proprietárníTak tomu nerozumim.
Jak vůbec může v možnostech chybět tradiční Jabber s OMEMO! (Pravda, implementace lurch pro Pidgin je… no… zkrátka, už jsem viděl lepší… Ale třeba v Gajimu je celkem dobře udělaná.)
Signal je teoreticky fajn. Prakticky…
In May 2016, Signal's lead developer Moxie Marlinspike requested that a third-party client called LibreSignal not use the Signal service or the Signal name. As a result, on 24 May 2016 the LibreSignal project posted that the project was "abandoned".
Vývojář LibreSignal: „If I finance running a TextSecure server for LibreSignal, will you federate with us?“
Signal (Moxie): „It is unlikely that we will ever federate with any servers outside of our control“
[zdroj]
Signal (Moxie): „federation and defined protocols […] no longer have a place in the modern world“ [zdroj]
„They have explicitly said that the only want their own builds of Signal using their server.“ [zdroj]
Říkám pořád, že pouhé „open-source“ nestačí. Svobodný software, svobodný ekosystém.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.