Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
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.