Názory k článku
Android 17 bude používat Encrypted Client Hello

Proč by měli požívat OkHttp?

Předpokládám, že proto, že tam už je to implementované.

A pan chytrolín se opět ozval. Já se ptal proč by měli zrovna používat OkHttp a ne treba jiného clienta. Cronet by to měl umět taky.

Pardon, já jsem zapomněl, že odpovídám hlupákovi, a musím napsat všechno explicitně.

Protože autoři té úpravy vědí, že to v OkHttp implementované je a funguje to správně (třeba proto, že to tam implementovali). A knihovnu OkHttp zvolili proto, že je to na Androidu de-facto standard pro HTTP komunikaci. Autoři té úpravy nedělali rešerši všech ostatních HTTP knihoven, aby zjistili, ve kterých už to implementované je a ve kterých to implementované není. Prostě doporučili tu jednu, která je nejpoužívanější a o které s jistotou vědí, že to tam implementované je.

Mně šlo o tu formulaci, že vývojáři "by měli použít OkHttp" , jako by to byla jediná možnost nebo povinnost pro Android.
​Cronet není žádná náhodná knihovna z rešerše, ale oficiální síťový stack přímo od Googlu.

DoT a DoH z veřejných Google DNS serverů (případně jiných velkých) prý zlepší ochranu našeho soukromí.

Snad to tak je a nejde jen o soustředění našeho soukromí k několika velkým hráčům, kteří budou znát ještě větší detaily a stoupnou ještě více na významu.

Snad i to ECH není ve skutečnosti cesta jak přesunout soukromí ještě vice ke Google a podobným.

Co vám brání použít DoH někoho jiného? Třeba DNS4EU, CZ.NIC ODVR nebo OpenDNS?

Snad i to ECH není ve skutečnosti cesta jak přesunout soukromí ještě vice ke Google a podobným.
Jak přesně by ten přesun soukromí přes ECH měl fungovat?

Nevim jak ta druha cast, ale "Co vám brání použít DoH někoho jiného?" ma jasnou odpoved - 99 % lidi to nebude delat protoze takovym detailum nerozumi, i kdyz by jim treba nikdo nebranil.

Nebo prostě nebudou vědět, že (jak) to lze v tom Androidu změnit.

Mohlo by to být třeba takto: uživatelé nic měnit nebudou; po letech EU začne Google vyšetřovat a pak bude nařízeno, že uživatelé si při prvním startu budou moci svobodně vybrat DoT či DoH schválený EK...

Nevíte proč když člověk zakáže ip adresy Google na routeru tak se všem na Androidu zobrazí u značky WiFi vykřičník? :-)

Zprávička přímo uvádí:
"Aby ECH bylo co platné, je samozřejmě potřeba používat i šifrované DNS dotazy."

ECH tlačí na použití DoT a DoH. Snad jsem objasnil své "snad" v posledním odstavci.

ECH tlačí na použití DoT a DoH.
Netlačí. Jenom se při popisu ECH konstatuje, že když chcete před světem skrývat, s jakými doménami komunikujete, je potřeba skrývat i DNS dotazy.

Spis "co vam brani DoH vypnout a blokovat vsude, kde je to mozne ?"

Funkcnost. Napriklad nastavil som nasim dochodcom jedneho z vyssie vymenovanych providerov DoH a mal som staznosti, ze casto "nefunguje internet". Po zmene na cloudflare vsetky problemy zmizli.

Takze aj to moze byt jeden z faktorov, preco sa to koncentruje u velkych poskytovatelov.

No asi nejblíž pravdě bude ta interpretace, která říká, že Google dělá všechno proto, aby byl jediný, kdo může neomezeně šmírovat, a ostatní to museli kupovat od nich.

Děkuji za pochopitelnější interpretaci. I když co všechno s těmi daty bude v době "AI" dělat je otázka.

Nedomnívám se, že směr - nahrazujeme mnoho lokálních šmíráků za několik globálních je dobrý. Lokální šmírák je špatný a globální taky.

Mírně bych to tvrzení poupravil - lokální šmírák je špatný a globální ještě podstatně horší.

DoH ma vyhodu, ze na rozdiel od DNS nejde blokovat alebo obmedzovat - je to proste nieco vnutri HTTPS. Je trivialne rozbehat si svoj DoH server.

Nevidim, ako by toto mohlo pomahat Googlu.

Tak Android nemá nativní podporu RFC 9230 (Oblivious DoH), a "shodou okolností" je Google jedním z největších poskytovatelů public DoH DNS resolveru...

Jak na zlatém podnose. (a to, že si někdo může rozjet vlastní DoH resolver je tu celkem irelevantní, nejde o pár frikulínů, ale většinu populace)

Nemoznost blokovat DoH je vyhoda aj nevyhoda zaroven.

Je to ok, ze kaviaren, z ktorej browsujete, nevidi kam sa pripajate.

Nie je to ok, ked to robi vas televizor (alebo ine domace zariadenie) a zatnut to ide leb hrubou zaplatou, po ktrorej prestane fungovat uplne.

Nice! U zakaznika akurat prehadzujem skriptom FW pravidla pouzivajuce FQDN (lebo FW povoli natvrdo prelozenu adresu a je mu jedno, ze to co tecie uz nematchuje to FQDN. co je problem v pripade reverzneho proxy) na SNI logiku. Kedze SNI vidim bez inspekcie, tak to funguje pre vsetku http/https komunikaciu. S tymto budem nahraty a bez dekrypcie neuvidim nic :)

Musím říct že to určitě má pozitivní stránky. Třeba ohledně sledování etc. Ale má to taky negativní stránky, kupodivu taky kolem ohledně sledování etc.
Tj. tři usecase:
- Jako uživatel nechci být sledován
- Jako uživatel chci sledovat svoji televizi a různá IOT zařízení které odesílají data buh-ví kam
- Jako admin chci mít přehled jestli někdo z mé infra nekomunikuje se stránkami prolezlými mallware etc.

Dřív, v začátcích internetu to bylo jednoduché. Každý server měl jednu adresu, na jednom serveru se provozovalo málo služeb. Horší to je teď, kdy všechno frčí přes globální CDNky a hostingy...

Přesně tak, tohle mě napadne skoro pokaždé, když tu čtu o nějakém dalším podobném mechanismu.
Na jednu stranu to úsilí, aby nikde nic neleakovalo, nezanechávalo žádné stopy, kompletně zachovávalo integritu a důvěrnost těch spojení.
A na druhou pak možná ještě intenzivnější snaha o pravý opak, když se vymění role a člověk má pak něco zabezpečit nebo kontrolovat. Ať už proaktivně bránit nebo zpětně analyzovat nějaké průšvihy, exfiltrace atp. může jít o malware, software/firmware třetích stran, BYOD.. a musí se uchylovat k čím dál náročnějším, složitějším (a dražším) řešením, které mohou být často velmi "heavy handed". Jak z hlediska zvýšené zátěže, latence spojení a operací, tak i v tom, jak se snaží obcházet tyhle mechanismy, vynucovat fallbacky atd.
Schizofrenie.

Jde o přesun od lokálních šmíráků ke globálním šmírákům. Také o přesun od lokálních správců ke globálním správcům. Jde o ztrátu lokální kontroly (pro jednotlivce, rodinu, firmu).