Názory k článku
Thunderbird plánuje během tří let kompletně předělat rozhraní

Kdybyste byl méně arogantní ňouma a obtěžoval jste se uvažovat, možná byste jednak zjistil, že jsem se k tomu vyjadřoval oběcně a o Thunderbirdu nemluvil a dál to, že problém je z hlediska UX nesmyslné kombinování snahy matlat po displeji a zároveň to něco používat profesionálněji. Dejte, vy boomere, účetní do do ruky tablet. Naschvál, jak daleko vás požene.

Řeči podobných matláků fakt miluju. Vůbec nevíte, která bije ale máte na všechno názor. Tomu domovu důchodců se v tom podobáte mnohem víc, než si myslíte :-D

Hmm, arogantní ňouma, slovník hodný gentlemana :)

Ok, nevím, která bije, pravil UX expert. Idem vrátiť diplom.

Ano, arogantní ňouma. Jestli je to slovník hodný gentlemana nebo není je mi ve vašem případě zcela srdečně jedno. A jestli vás uráží "ňouma", mnohem přesnější by bylo "individuum" ale to jsem původně nechtěl napsat. A arogantní a nafoukaný jste zcela bezpochyby. Ale když chcete, prosím.

martinpoljak: to bude projekcia.

Ne. To je popis toho, jak se projevujete.

Mimochodem, co takový unixový shell, ten je tak nemoderní? Vim bych kompletně redesignoval. Emacs taky. To je jasné. A koho napadlo používat pro sazbu LaTeX? Tak nemoderní... A Midnight Commander rovnou vaporizovat, vždyť se podobá Norton Commanderu! Takový dinosaurus.

To je právě ta dementizace/de­bilizace daná vám podobnými. Přesně takhle se projevuje. Děkuji za skvělý příklad.

Z latexu si pamatuju, že to selže, když v math mode použiju česká písmenka. Ale třeba ten problém mají jen některé „distribuce“ nebo už to v roce 2023 vyřešili…

Shell má problém v tom, že si programy přes pajpy předávají nestrukturovaný text, takže se pak ve skriptech dělají věci jako foo | grep bar | cut -d " " -f 5, a 80% skriptů selže když zpracovávají název souboru s mezerami a 99% skriptů selže když zpracovávají název souboru s newline.

Debilizace se projevuje i věkem.

Chcieť od použivateľov, aby používali unixový shell, je obyčajný gatekeeping. Vim a emacs sú retro editory, ktoré majú isté use casy a na ne sú dobré. Ja som zhodou okoľností písal vysokoškolské práce a príspevky na konferecie v LaTeX-u (Ktorý je sám o sebe debilizácia TeX-u) a používal som na to vim (machri používajú ed). Ale od svojej manky by som takéto veci nevyžadoval. Aj ten vim, LaTeX, a Emacs sa stále prerábajú a majú aj matlacie verzie :)

Asi viete dobre, aký som ja debilný :) Btw, midnight commander je hrozný. To je nástroj pre ľudí, čo nevedia používať shell. Majú tam 25 rokov neopravené glitche.

Kúpte si Geriavit, vraj je to dobré aj na nervy :) Človek potom neprská na v diskusii na root.

No hlavně že si to dokážete zdůvodnit.
Předně, jste to Vy / Vaši kolegové, kdo po uživatelích chce, aby používali to, co je podle Vás geniální, a ještě ostatním doporučujete Geriavit (a asi i chápu, kam míří ta poznámka o gatekeepingu, možná Vám křivdím, ale cítím v tom takové to já bych ty všechny shelly zrušila).

Nechť snad proboha uživatel pracuje v tom, co mu vyhovuje, ne? Někdo umí efektivně matlat, někdo další klikat, jiný je velmi efektivní v shellu - jediná stopka by měla být v otázce bezpečnosti - tam prohazovat plyn s brzdou nikdo svéprávný naštěstí ani nezkoušel, bohužel s dotykáčem v autě to prošlo i přes upozorňování odborníků na bezpečnost od samého počátku, a začíná se vracet k čudlíkům až teď, ale běžné práce na PC se to netýká.

10. 2. 2023, 22:02 editováno autorem komentáře

Wasper: Stále sa bavíme o faceliftingu zastaralých aplikácii? To je proste vývoj. Ak nesúhlasíte s Mozillou, vytvorte si fork. Bude mať dvoch vývojárov, zároveň aj používateľov, ktorí sa spolu pohádajú kvôli flaštičku geriavitu a stane sa z toho mŕtvy fork.

Ja si budem matlať v novom thunderbirde lekvárovými prstami a makovými zubami sa vám budem smiať.

Tahle míra arogance je ve Vašem oboru kvalifikačním předpokladem? Nemusíte odpovídat...

Wasper: rotujúci karfiol.

Len som chcel na hlúpu otázku adekvátne odpovedať.

Nemyslím. Už vzhledem k tomu, co dělám, znám uixáků celkem dost a drtivá většina z nich je naprosto normálních; a to obvykle o dost víc, než vývojáři. S tímhle nebo něčím ppodobným bych ale tedy fakt chtěl spolupracovat...

martinpoljak: Ja som musel pracovať s kadejakými debilmi, takže vás by som nevylučoval. Nie som elitár.

Já od uživatelů nic nechci.

Jenomže problém není v tom, že to nějaká část uživatelů potřebuje. Problém je v tom, jak to pak někdo patlá do jednoho uživatelského rozhraní tak, že to nestojí za nic ani pro jedno, ani pro druhé. A to zvlášť u produktů, které k tomu prostě nejsou určeny.

Traktorem taky nevozíte (tedy většinou, párkrát jsem traktorem na oběd jel) děti ze školky. A to ani Fastracem. Protože prostě k tomu ta věc nikdy nebyla postavena a každý si radši sežene nějaké auto. Chcete-li matlat po displeji (taky občas matlám po displeji), matlám v jiných klientech, které jsou od začátku uzpůsobené matlání po displeji a ty zase nepoužívám doma na notebooku/desktopu.

A dementizace/de­bilizace produktu spočívá mimo jiné typicky v tom, že produkt bez ohledu na to, čím je přizpůsobuji debilním masám, které nejsou schopny používat správnou věc ke správnému účelu. Dalšími projevy pak je zahazování všeho, co tupou masu nezajímá takže pak je problém pořídit za rozumné peníze něco, co je profesionálně použitelné.

Na jednu stranu chcete aby byl linux desktop bezny, na druhou stranu prizpusobeni linuxoveho desktopu uzivatelum nazyvate debilizaci. Tak ted babo rad…

Já fakt nepotřebuju aby cokoliv bylo běžné nebo neběžné; je mi to v podstatě fuk. Potřebuju efeketivní pracovní prostředí, to hlavně.

Efektivní pracovní prostředí je na nic když pro něj není podpora aplikací a formátů z okolí. Naštěstí má Linux už mezi power-usery dostatečné zastoupení na to, aby na něj mysleli i výrobci specializovaného SW (a samozřejmě i toho běžného, což jsou většinou teda OSS projekty, ale masivně podporované firmami).

Jenže ono to není o tom přidáme myš ke klávesnici, ale dáme myš místo klávesnice, vždyť se dá psát i na obrazovce tak v čem je problém ne? Zpátečnickým vykopávkám nevadí "mobilní" rozhraní na mobilu, ale "mobilní" rozhraní na desktopu.

Ale to vůbec neodpovídá tomu popisu v článku a tomu na co jsem pochopil že má oauth být. Dle článku a jak jsem to pochopil i z jiných dříve studovaných materiálů:

- klient si vymyslí ID a secret a řekne scope (k jakým prostředkům chce přístup) a endpoint URI (kam se mu POSTne výsledek autentizace)
- já (majitel Google účtu) řeknu „ano tohle schvaluji“
- Google postne na endpoint URI token; na endpoint URI typicky poslouchá klient, uloží si token a ten pak používá pro přístup k prostředkům

Proč ty požadované údaje („co je v tokenu“ - mail, fotka? proč? myslel jsem že token je čistě něco jako „unikátní heslo“, a privilegia) neposílám v tom scopes?

Výsledek tedy je, že když vyrobím emailového klienta, a ten má podporovat všechny možné poskytovatele (stejně jako dříve podporoval všechny poskytovatele co měli „normální IMAP s heslem“) - GMail, MS365, různé MS365 hostované u každé firmy on-premise - tak si musím u každého založit účet, „appku“, a co teda vlastně ta appka přesně dělá? Přesněji, založení aplikace mi dá client id (které nemůže být tajné, protože je třeba nahardcodované v Thunderbirdu a každý si ho může přečíst) a to pak zadávám když žádám o autentizaci (tj. client ID není ID „počítače“ ale appky?), secret je předpokládám unikátní vygenerovaný na „počítači“, a co dělá online část té aplikace? Uloží token zašifrovaný secretem(?) který dostane POSTnutý od Authorization serveru a pak ho mému emailovému klientovi poskytne poté co se zeptá jestli už autorizace proběhla?

> Aplikaciu musis pouzit pretoze nikto nevie ako ty konkretne mas nastavenu autorizaciu, login/pass, 2nd factor, aky 2nd factor, crossdomain autorizaciu, rozne dalsie vyzvy, ...

Ne, to mě přece nezajímá, pointa je že klient požádá o autorizaci a pak uživatel toto schvaluje libovolným způsobem (ideálně ve svém browseru, v horším případě - Thunderbird - v embedded browseru), klientovi je úplně jedno jak.

(díky moc jestli mi tohle vysvětlíš, už jsem to chtěl dlouho nastudovat a přišlo mi to právě hrozně komplikované)

Ano je to komplikovane ;-)
Token nie je plain random cislo ale tzv JWT token pretoze google podporuje OIDC. Vo vseobecnosti token MOZE byt random cislo ale v pripade OIDC to musi byt podpisany kus informacie. Viac napriklad tu:
https://stackoverflow.com/questions/20159782/how-can-i-decode-a-google-oauth-2-0-jwt-openid-connect-in-a-node-app
Ak si ho chces dekodovat skus toto:
https://jwt.io/

Google nic nepostne urobi redirect (302). To co posle google zalezi od nastaveneho FLOW. Tych flow je niekolko:
https://darutk.medium.com/diagrams-of-all-the-openid-connect-flows-6968e3990660

No a to ako funguje Thunderbird je prave dovod preco je prehlaseny za nebezpecnu aplikaciu pretoze si drzi access_token (a refresh_token) u seba a je to tucna aplikacia. Nefuguju tam aspon zakladne ochrany ako napr CORS v browseri. Ktorykolvek doplnok moze 'uniest' refresh_token a tym padom tvoj account aj ked nema pristup k login/password-u.

Pokial tvoja aplikacia podporuje viacero IdP (Identity Provider) musi si tam zalozit account aby mal ten client_id a client_secret ktorym tam bude pristupovat a ano aj ten by mal byt tajny za beznych okolnosti ale v Thunderbirde bude nahardkodovany takze dalsi dovod preco je prehlaseny za nebezpecny. Normalne ide redirect cez browser takze ten client_id/cli­ent_secret tiez vidis ale naspat ide iba 'code' takze cez tvoj browser access_token nejde. Ak nedoverujes klientskej aplikacii v browseri ze si z code ten token nevypyta mozes pouzit specialny flow 'code flow with pkce'.

No oAuth a OIDC je dost komplikovane ale aspon nejako standardizovane takze sa to da pouzivat cross domain. Odporucam citat zdroje na auth0 ti to maju dobre spracovane a je to napriklad centralizovany IdP co by sa v minulosti nedalo urobit. Ak by si chces nejaky open source IdP odporucam keycloak.

Aha, díky, snad chápu.

A že Google vyžaduje tu registraci aplikace, tak to je z "politických důvodů" aby mohl admin GSuite třeba říct "uživatelům nepovolíme Thunderbird"? Protože „normální IMAP“ přece funguje tak, že uživatel dostane heslo, a jakého mail klienta použije, to už je na něm… (ale jakmile uživateli povolíme jakoukoli desktopovou aplikaci, tak si stejně může použít libovolnou jinou, protože si z té první ukradne buď získané tokeny, nebo rovnou client id pokud je to ten „thunderbirdí“ flow)

> No oAuth a OIDC je dost komplikovane

No a to je právě ten problém, že se jako uživatel bojím že když nerozumím tomu, co který token znamená, který mám chránit a na co vlastně klikám (podpořeno tou UX embedded browseru, který bohužel Thunderbird používá, a vypadá to úplně jak phishing), tak se dostávám do pozice BFU který neví co dělá a bude z toho průšvih. A přitom si myslím že pro naprostou většinu normálních použití by úplně stejně fungovalo „app specific password“, které před rokem zrušili…

Je to podobná situace jako naprosto jasné oprávnění klíčů třeba v SSH nebo keyslotů v LUKSu v linuxovém světě vs. celá ta tragédie kolem pass-the-hash a klíče pro Bitlocker ve Windows světě…

Podobný „dark pattern“ jsem zažil když jsem třeba chtěl otevřít soubor z Google Drive v https://app.diagrams.net/ - zaboha jsem nedokázal rozlišit, jestli tomu dávám přístup jenom k vybranému souboru, nebo k celému drive, a navíc se celá ta interakce odehrává v „iframe“, takže netuším, jestli mi ta aplikace nekreslí divadlo. Upřímně, naprosto to nechápu, jak se počítá, že se v tomhle zorientuje BFU, když já, byť s těmito konkrétními technologiemi nemám zkušenosti, ale jinak si myslím že jsem technicky dost znalý, nedokážu zjistit co se děje? Nebo se spoléhá na to že „google schválil diagrams.net aplikaci a tak nebude evil“?

(no a pak je tu ještě ten problém s funkcionalitou, já naštěstí používám Thunderbird, kde je to nějak, byť tragicky, implementované, ale kdybych používal třeba fetchmail+mutt, tak vyletím z kůže…)

Furt mi přijde divné, že kdyby tohle zavedl ještě Seznam a Centrum a Vodafone a já nevím kdo ještě, tak budou autoři emailových klientů konfigurovat 10000 služeb na světě a registrovat nějaké aplikace, zatímco teď to bylo „zjistěte si od poskytovatele adresu IMAP a SMTP serveru a zadejte to do tohoto políčka“. Nebo se očekává že se „aplikace“ registrovat nebudou a většina to bude mít nějak „otevřené“ a emailovému klientovi se řekne adresa endpointu a on se připojí s nějakým svým client_id a nazdar?

No je to technologia na WEB/browser, akonahle opustite tuto zahradku tak to zacina byt komplikovane. Keby napriklad aplikacia bezala v browseri tak ani nezbadate ze ta aplikacia pristupuje na nejake API googlu vsetko je to single sign on.
Na klasicke IMAP api podla mna nadalej staci username/password. Problem je ze thunderbird (myslim, nepouzivam ho) chce pristupovat aj na ine Google API za ucelom ziskavania dalsich informacii (calendar, ...) takze tam uz potrebuje tie tokeny. A ano teoreticky by stacilo preniest refresh_token do thunderbirdu a mozete fungovat.
Tu je nahlad na tie API:
https://developers.google.com/workspace

Kdyby běžela v prohlížeči, tak buď musím plně důvěřovat poskytovateli služby (který musí řešit úplně ty stejné problémy které jsem popsal - jak to připojit na GMail, MS365, Seznam, … - ne, ve skutečnosti navíc místo IMAPu bude používat nějaké provider-specific API?), nebo si ji provozuju lokálně a pak to řeším taky ;)

> Na klasicke IMAP api podla mna nadalej staci username/password.

Bohužel nestačí, minimálně pro GSuite účty zakázali i app-specific password a enforcují oauth.

Ale já nechci speciální Google API, já chci používat poštovní klient přes POP3/IMAP jako to funguje všude jinde na světě… (a říkám že teď mám štěstí že to za mě naštěstí nějak vyřešili vývojáři Thunderbirdu)

Ak to bezi v browseri celkom tak nemusite pretoze ked sa pouzije ta PKCE extension tak v browseri tokeny nemate, dokonca vdaka PKCE to viete garantovat ze sa tam ani nikdy nedostanu (neviete CODE premenit refresh_token), su tam iba session ID ulozene ako cookie ku ktory sa JS ani nedostane.

Pavel Tavoda
chce pristupovat aj na ine Google API za ucelom ziskavania dalsich informacii (calendar, ...) takze tam uz potrebuje tie tokeny

GMail od 30.5.2022 neumoznuje pouzit name+passwd pro pristup k mailum, resp. ani pro odeslani, pouzivam gmail na notifikace ze serveru a "musel" sem resit prechod na OAuth2:

- zaregistrovat si u nej nejakou vymyslenou aplikaci, abych ziskal client_id a client_secret (povolit ji gmail api, scopes gmail.compose, credential oauth2)

- pro ziskani oath2_token pomoci refresh_tokenu pak pouzit jejich gmail-oauth2-tools/oauth2.py

- protoze nemam workspace musela "app" byt jako externi (ne interni) a v rezimu testing, coz omezuje platnost refresh_token na 7dni

- msmtp pak misto jmeno+heslo autorizovat pres passwordeval volane bash script vyuzivajici ten oauth2.py

- ale pro obnoveni refresh_token po 7dnech musim pustit skript co mi vygeneruje url na kterem musim rucne v web prohlizeci 2x potvrdit ze jde o neoverenou aplikaci, ziskam verification_code, z ktereho skript dale ziska ten refresh_token a zmeni v configu/profilu

to vse "jen" pro "odesli mail z meho gmail uctu pres smtp"

btw: snazil sem se pochopit/probrat, zda mi neco neunika nebo je to opravdu takto "uchylne" a jen na 7dni tu, bez vysledku:
https://www.abclinuxu.cz/poradna/linux/show/479886

Proč by nešlo použít to řešení s impersonací Thunderbirdu? (ale samozřejmě nevím jak ho technicky realizovat a jestli na to už existuje nějaký program, nebo by to bylo potřeba nahackovat)

priznam se ze to sem nezkousel...
ted zkusil, z thunderbird source zjistil jeho hardcodovane client_id a client_secret, to nastavil do meho oauth2 profilu, zkusil s tim ziskat pres url refresh_token (pres oauth2.py, postup jak delam pro ty sve client_*) a zarvalo...

patral sem dal a zjistil ze refresh_token si uklada thunderbird jako heslo k uctu, v Thunderbird/Nas­taveni/Zobrazit­Hesla, radek s Poskytovatel oauth://accou­nts.google.com, zkopiroval ho, pridal do oauth2 profilu a msmtp diky temto 3 udajum si pres ty skripty vytahl oauth2_token s platnosti 60m

takze by to takto asi fungovalo, jen nevim jak dlouho, zahlidl sem info ze long time refresh_token je na 2roky, mozna 200dni, tim ze thunderbird normalne nepouzivam nevim zda se po teto dobe znovu zada pres ten web popup prihlaseni k GMail...

Napadl mě třeba další UX problém:

> Ak nedoverujes klientskej aplikacii v browseri ze si z code ten token nevypyta mozes pouzit specialny flow 'code flow with pkce'.

I pokud jako uživatel vím, že taková věc existuje a že některé flows umožňují takové zneužití a některé ne (na jednu stranu mi tohle přijde jako příšerně složitá problematika na vysvětlení, na druhou stranu můžeme očekávat, že „desktopové aplikace“ v dnešní době používají spíš power-useři), jak poznám, který flow se zrovna teď používá? Maximálně studiem protokolu a zkoumáním fragmentů otevřené URL… Google to tam myslím fakt nikde nepíše…

Ved google to vyriesil za vas, prehlasil ze ta aplikacia je neporiadne zabezpecena ;-).
To za vas v principe riesi ciastocne google zas na druhej strane je zodpovednost aplikacie. V principe nic nebrani zneuzitiu ale zas na druhej strane ak k tomu dojde google dokaze dohladat komu token vydal a pozerat ci sa to deje casto a pripadne taku aplikaciu zakazat.
Pripadne ak odovzdavate tieto tokeny dalej tak si to mozte riadit aj sam cez AUD (audition).
V reale sa IdP obvykle sustreduje na tu cast ktora bezi v browseri respektive na strane klienta. To ze server niekomu praskne vas token sa zabranit neda ale da sa velmi presne zistit komu (ktore aplikacii client_id+aud) bol token vydany.