Vlákno názorů k článku Předvolební Chat Control: nedáš souhlas se skenováním, nepošleš obrázek ani odkaz od Michal Kubeček - U služeb s koncových (E2E) šifrováním má skenování...

U služeb s koncových (E2E) šifrováním má skenování probíhat v uživatelově zařízení, ještě před tím, než je konverzace zašifrovaná a odeslaná. To by ale v praxi znamenalo, že by provozovatel šifrování obcházel.

Takže jejich představa je taková, že si každý před tím, než napíše komentář, bude muset stáhnout obrovskou databázi "závadných hashů" nebo něco ještě horšího?

Ještě jednou: ten společný bod potřebujete jen pro navázání komunikace, takže ve výsledku nebude vědět víc, než že Adam mluví s Boženou. Z další komunikace je už vyloučený.
Navíc tím společným bodem nemusí být žádný centrální server, ale někdo další, se kterým ti dva účastníci již komunikují. (Tohle právě uměl Skype - na začátku.)
Případně si můžete někde vystavit svůj vlastní, důvěryhodný propojovací bod.

E2E komunikace uz davno moc neni. Ono za NATy, o ktere zakopavate na kazdem rohu to dost dobre ani nejde. S nasazenim IPv6 se jednak mnozi moc nepretrhnou (zvlast pokud si udelate deep-dive do low-level aplikacnich veci a neresite jen web), druhak na IPv6 vam mj. nekteri mobilkari i tu E2E komunikaci zariznou - takze jste tam kde jste byl s NATem a na to, abyste si pokecal potrebujete nejaky middlebox.

Na tohle odpovím: prdlajs.
To spojení na TCP vydrží tak dlouho, dokud vydržíte komunikovat. Navíc, dokud ta komunikace běží, můžete si otevřít další a další...
Já to sice nijak intenzivně nepoužíval, ale testovací spojení mi vydrželo desítky minut, dokud jsem je neukončil. Pravda, bylo to před lety, kdy to s těmi NATy nebylo tak hrozné, o dnešku to tvrdit nemůžu.
Nicméně během bezpečáckého školení (před COVIDem...) nám to demonstrovali, a chodilo to.

Na udržení spojení je potřeba poslat pár bajtů za minutu - to zvládne i aplikace na pozadí. (Kdyby na to přišlo - běžné komunikátory se tak nechovají. Ale mně šlo o princip.)

Dávno, pradávno, jsem vysvětloval, jak se ty NATy dají - většinou! - obejít ("NAT traversal") a navázat přímou komunikaci, pokud máte společný třetí bod - a tím bodem nemusí být nutně klasický "centrální server", ale prostě stroj, na který vidí oba konce komunikace.

On je tak navržený třeba i SIP - hovor se sice naváže přes nějaký server, ale vlastní RTP stream už může jít přímo. Háček je v tom, že v praxi se to tak nedělá ani když by to šlo, protože komerční operátoři potřebují, aby hovor šel celou dobu přes ně, jinak by neměli kontrolu nad tím, jestli nevoláte déle, než jste zaplatil.

10. 9. 2025, 07:14 editováno autorem komentáře

No a nebo to udelate obracene... lokalne jen spocitate hash, posletete to nejakemu API endpointu k provereni. Mimochodem reseni, ktere se pouziva i na jinych typech sluzeb. U online chatu beztak nepredpokladate, ze API bude nedostupne, kdyz i samotnou zpravu pres nejake API odesilate.

U online chatu beztak nepredpokladate, ze API bude nedostupne, kdyz i samotnou zpravu pres nejake API odesilate.
Pokud ovšem ta komunikace neprobíhá E2E.
Reálně stačí najít protistranu (přes API nebo napřímo) a pak můžete komunikovat, aniž by byla nějaká třetí strana potřeba.

Dávno, pradávno, jsem vysvětloval, jak se ty NATy dají - většinou! - obejít (NAT traversal) a navázat přímou komunikaci, pokud máte společný třetí bod - a tím bodem nemusí být nutně klasický centrální server, ale prostě stroj, na který vidí oba konce komunikace.
Pak přišla aplikace Skype, která to uměla. (Pak to přestala umět, koupil ji Microsoft, a nakonec přestala úplně.) Podobně to umí Synology, pokud potřebujete na svůj NAS přistupovat odkudkoliv.
Že to nedělají běžné komunikátorty je pravděpodobné, ale rozhodně to neznamená, že to nelze - a že nejsou komunikátory, které to umí.

Akorat ze NAT-T proste neni neni E2E. Ten spolecny treti bod je ten "centralni" server a je lhostejno, kdo a jak ho provozuje. Bez nej to proste nejde - a ze se to ve vysledku tvari trosku a skoro jako E2E neznamena, ze to E2E komunikace je. A samotny stroj, co vidi na oba koncem je rizikem mj. i z pohledu sledovani te vasi komunikace.

vzhledem k tomu, že takový tunel ti otevřený nevydrží dlouho, tak takhle se od tebe dostává informace kdy a jak často komunikuješ s konkrétním dalším člověkem. Únik bočním kanálem může být v tomhle případě citlivý.

Hole punching ti neprojde symetrickým NATem, zejména ne tím schovaným za obřímy sítěmi jako jsou ty mobilní, takže stejně skončíš u přeposílacího serveru, který může narušit E2EE. To je důvod proč i to u Skypu zrušili, úspěšnost velmi klesala, kvalita takového spojení byla problematická (byl jsem v té době u toho).

Jak píšu: dokud vydržíš komunikovat, to spojení vcelku donře drží. A té komunikace nemusí být mnoho. Ostatně: ty aplikace si beztak vyměňují statusy (je on-line, píše...).
Krom toho je dobré, když ty kanály otevřeš rovnou dva (A-B a B-A) - při uzavření jednoho z nich lze snadno navázat další pomocí toho dosud fungujícího.

mobilní aplikace ti běžně chodí do sleepu, když je nemáš na popředí, pak se oživují notifikacemi. Aplikace, která ti bude kontinuálně komunikovat na síti ti naprosto zrujnuje baterku a většina se tak nechová.

a jak dlouho prosímtě vydržíš komunikovat a mít otevřenou chat aplikaci? :)

Jsou FW, které to NAT zavřou po minutě nečinnosti, jiné to pravidlo dokáží držet hodiny, to prostě záleží. Sám se může zamyslet na tím jak se k tomu asi chovají ty národní operátoři, myslíš, že drží NAT stavy hodiny?

Ve Skypu těch provozních dat bylo trochu víc než tvoje osobní zkušenost před pár lety.

Dnes NAT-T používá třeba ZeroTier, myslím, že někde na fóru/blogu psali kolik spojení udělají P2P a kolik běží přes jejich relay servery.