Vlákno názorů k článku
Seznam.cz zavádí dvoufaktorovou autentizaci pomocí OTP a ruší kontrolní otázky od Rovano - Takže všichni bez chytrého telefonu se nepřihlásí?

Pokud ten doplňek má vyplňovat kód do formuláře, potřebuje přístup k celé stránce. O jaký doplněk se jedná? Pokud to doporučuje Seznam, asi to nebude anonymní doplněk, ne?

Pre to pouzivam offline password manazera.

Seznam jako jednu z možností uváděl doplněk do prohlížeče. Nespecifikoval který. Když jsem to slovo hodil v doplňcích do vyhledávače, vypadl na mě jen 1.

https://github.com/Authenticator-Extension/Authenticator

Aha :). Tohle anonymní není, autoři jsou dlouhodobě známí a mají svoji historii.

Každopádně jako alternativa je třeba bitwarden (Kanada), 1password (Kanada), dashlane (Francie). Dříve byl třeba fajn lastpass, ale po jeho prodeji to už není ono.

A podle čeho vybírat a který je důvěryhodný? To je otázka za deset bludišťáků, kdo ví. Ani jeden ze jmenovaných není nový hráč, nemá za sebou velké skandály nebo úniky, pravidelně se staví čelem k bezpečnostním problémům.

Díky za praktické zkušenosti.
Zatím to chodilo spíše kolem mě.
Některé znám. Ale nepoužíval jsem ani jeden.

Snad se blýská na lepší časy s autentifikací obecně.

Bitwarden, uz umi bejt i v EU...https://www­.ghacks.net/2023/07­/27/how-to-migrate-your-bitwarden-vaults-from-us-to-eu-storage/

Jestli kvuli tomu musim vytvaret novy account, tak je to celkem naprd.

Jestli nekdo chcete pouzivat Bitwarden kvuli TOTP, tak vas to budestat $10/rok, viz https://bitwarden.com/pricing/

A jestli chcete mit integraci s browserem a v ni pouzivat biometrii, tak na Linuxu to nefunguje. Android s biometrii je v pohode.

Pokud chcete standalone OTP clienta na Linuxu, pak https://flathub.org/apps/com.github.paolostivanin.OTPClient funguje dobre. Na Androidu dobre funguje AndOTP https://github.com/andOTP/andOTP -- asi prestal byt udrzovany, ale na funkcnost to IMO nema vliv.

Případně bitwarden je opensource a jde rozject na vlastním serveru ;-)

Jestli nekdo chcete pouzivat Bitwarden kvuli TOTP, tak vas to budestat $10/rok, viz https://bitwarden.com/pricing/
Máte ve svém počítači něco cennějšího, než jsou hesla? Řešit u správce hesel méně než jeden dolar měsíčně je jako pořídit byt za miliony, do něj vybavení a elektroniku za stovky tisíc, a pak špekulovat, jestli pořídit bezpečnostní zámek.

Jak je velký Bitwarden klient na androidu? Na iOS to má skoro 300MB :-/. Password Manager 300MB? Ne, fakt ne. Mám limit 70MB a i to je hodně, na takovou funcionalitu.

android mi rika 77MB a to je v poradi nekde na chvostu aplikaci sezarezenych podle velikosti.

Mám limit 70MB a i to je hodně, na takovou funcionalitu.
Po mobilním bankovnictví asi druhý nejdůležitější program, který na mobilu máte, a posuzujete to podle velikosti? Zvláštní přístup. Já tedy u správce hesel hodnotím hlavně jeho bezpečnost a zda mi poskytuje takové funkce, abych s přístupovými údaji zacházel bezpečně.

Za mě je tohle celkem taky důležité. Nechápu proč by ta aplikace měla být takhle obří.

protože si s sebou nese celý prohlížeč, protože client je webová stránka, takový je bohužel dnes trend. Můžeš mít klienta jen jako http server a otevírat si ho ve svém prohlížeči.

Na to by měli sloužit něco jako WebView, nebo jak se to jmenuje, a pak by si nemusela nést celý prohlížeč. Tenhle argument je naprosto na hlavu.

MacOS desktop ale žádné webview nemá, proto to s sebou nese, Adroidí nebo ios aplikace už nemusí.

Saljack: Ano. Už proto, že čím víc balastu to s sebou táhne, tím větší šance na nějakou zranitelnost. A to by zrovna u správce hesel asi bylo dobré brát v potaz.

Právě o tom mluvím. Čím víc kódu, tím víc chyb. A tady se navíc jedná s ohledem na funcionalitu o zcela zbytečný kód. To, že je ten bloatware navíc pomalý resp. žere energii a příp. restore trvá neúměrně dlouho do toho nepočítám.

Právě o tom mluvím. Čím víc kódu, tím víc chyb. A tady se navíc jedná s ohledem na funcionalitu o zcela zbytečný kód. To, že je ten bloatware navíc pomalý resp. žere energii a příp. restore trvá neúměrně dlouho do toho nepočítám.
To je ovšem absolutní nesmysl. Ten kód, co velikost distribuované aplikace nafukuje, jsou knihovny. Takže ten kód navíc tam bude vždy, bude se spouštět vždy. Tím, že by se z toho stala systémová knihovna, nezmizí z kódu zázračně všechny chyby a ten kód se nebude provádět rychleji.

to ale platí jen za předpokladu, že ty svoje závislosti budou aktualizovat stejně tak rychle a často jako se aktualizují třeba v OS. Bitwarden neudělal aktualizaci u desktop klienta svých závislostí už dva roky.

Takže ano, když se z knihovny stane systémová knihovna, opravdu zázračně mohou zmizet všechny známé zranitelnosti :).

U Androidu hodně záleží na výrobci telefonu, ve spoustě případů fakt není žádný problém být rychlejší, než aktualizace OS. Je otázka, zda v těch závislostech je něco, co mělo od poslední aktualizace bezpečnostní problém, a hlavně zda je tam něco, co mělo bezpečnostní problém s dopadem na Bitwarden. Navíc nevím, kde jste vzal ty dva roky – mám Bitwarden 2023.10.1 vydaný před dvěma týdny. Je tam Electron 25.9.1 vydaný 11 října.

To je ovšem absolutní nesmysl.

To je elementární statistika platná pro jakýkoli kód. Navíc v případě electronu docela podpořena i reálnými bezpečnostními problémy z nedávné minulosti. A to není ani zdaleka tak sledovaný jako mainstream web browsery. A už vůbec nerozebírám knihovny jako ffmpeg, které jsou v tom zabalené.

V appstoru je třeba taky jedna aplikace na převod měn, která má přes 250MB místo akceptovatelných 2,5MB. Ona opravdu bere 100x víc zdrojů než by měla. Pro mne (a je mi jasné, že se mnou nebude řada lidí souhlasit) je electron příp. webview jen nástroj na prototypování resp. PoC. Pokud se dostane do produkce, tak takovou aplikaci považuji za odfláknutou. A dokonce mi to připadá od vývojáře jako drzost vůči uživateli. Ano, včetně slacku, discordu, teamsu a dalších.

To je elementární statistika platná pro jakýkoli kód.
Z elementární statistiky platné pro jakýkoli kód plyne, že počet chyb závisí na množství kódu a množství práce, které se věnuje opravám chyb. V žádném případě nezávisí počet chyb na to, zda kód linkujete staticky nebo dynamicky nebo zda se knihovna distribuuje s aplikací nebo zvlášť.

Navíc v případě electronu docela podpořena i reálnými bezpečnostními problémy z nedávné minulosti.
Electron má spoustu funkcí, na každá aplikace je všechny využívá. Bezpečnostní chyby týkající se nepoužívaných funkcí nejsou relevantní.

Jestli se nemýlím, Bitwarden komunikuje s jinými servery jen při stahování ikon webu, a může komunikovat se svým serverem skrze proxy server. Takže to jsou dva možné vektory útoku – to vskutku není velký prostor pro útok.

Pro mne (a je mi jasné, že se mnou nebude řada lidí souhlasit) je electron příp. webview jen nástroj na prototypování resp. PoC. Pokud se dostane do produkce, tak takovou aplikaci považuji za odfláknutou. A dokonce mi to připadá od vývojáře jako drzost vůči uživateli. Ano, včetně slacku, discordu, teamsu a dalších.
To je ovšem váš problém. Tak ty aplikace nepoužívejte. Electron výrazně usnadňuje vývoj těch aplikací, kdyby neexistoval, tak ty aplikace nebudou, nebo budou mít podstatně méně funkcí. Je to stejně absurdní, jako kdybyste tvrdil, že nebudete používat aplikace napsané v C++, protože v assembleru by to bylo efektivnější – akorát je to posunuté o dvě úrovně dál.

V žádném případě nezávisí počet chyb na to, zda kód linkujete staticky nebo dynamicky nebo zda se knihovna distribuuje s aplikací nebo zvlášť.

O statickém nebo dynamickém linkování jsem nikdy nepsal. Vaše poznámka je irelevantní.

To je ovšem váš problém. Tak ty aplikace nepoužívejte. Electron výrazně usnadňuje vývoj těch aplikací, kdyby neexistoval, tak ty aplikace nebudou, nebo budou mít podstatně méně funkcí.

Vždyť také já žádnou aplikaci s electronem nepoužívám, takže problém nemám, což se nedá tvrdit o mých kolezích.

Je to stejně absurdní, jako kdybyste tvrdil, že nebudete používat aplikace napsané v C++, protože v assembleru by to bylo efektivnější – akorát je to posunuté o dvě úrovně dál.

Vaše přirovnání je stejně absurdní, jako obhajoba kalkulačky distribuovaná v OVF/OVA balíku společně s operačním systémem, protože pro ten váš to programátor napsat nechtěl.

O statickém nebo dynamickém linkování jsem nikdy nepsal. Vaše poznámka je irelevantní.
Já jsem nepsal jen o statickém nebo dynamickém linkování.Přečtěte si tu citaci celou.

Vaše přirovnání je stejně absurdní, jako obhajoba kalkulačky distribuovaná v OVF/OVA balíku společně s operačním systémem, protože pro ten váš to programátor napsat nechtěl.
Absurdní to není a vaše přirovnání nesedí. Smiřte se s tím, že usnadnění vývoje je podstatné hledisko. To, že máme tolik softwaru s tolika možnostmi je právě díky tomu, že je snazší ho psát.

Já jsem nepsal jen o statickém nebo dynamickém linkování.Přečtěte si tu citaci celou.

Žádná část (ani ta o distribuci zvlášť či s aplikací) není relevantní. Nic z toho jsem nikde netvrdil. Přečtete si, prosím, pořádně, na co jste reagoval. Pravděpodobně jste se asi spletl.

Absurdní to není a vaše přirovnání nesedí.

Tak všechny aspekty, které jste zmiňoval jsou stejné. Že se vám to ve výsledku nehodí do teorie nemusí znamenat, že to přirovnání nesedí. To jsou jen plané řeči.

Smiřte se s tím, že usnadnění vývoje je podstatné hledisko.

Ale ne na úkor uživatele. A toto je na úkor uživatele. Já chápu, že se efektivita ve státní správě neřeší, protože se tím udá další zakázka s upgradem, školením atd., Ale je to ignoranství.

To, že máme tolik softwaru s tolika možnostmi je právě díky tomu, že je snazší ho psát.

Jistě, ale není třeba kvůli tomu psát bloatware. Ostatní ho také nepišou. Koukněte na konkurenční produkty.

Žádná část (ani ta o distribuci zvlášť či s aplikací) není relevantní. Nic z toho jsem nikde netvrdil. Přečtete si, prosím, pořádně, na co jste reagoval. Pravděpodobně jste se asi spletl.
Mám jiný návrh. Pravděpodobně nevíte, o čem píšete. Začal jste tím, že Bitwarden na iOS má 300 MB. Což je způsobené tím, že si sebou na iOS Bitwarden táhne celý prohlížeč, zatímco na Androidu používá WebView, které je součástí systému. V dalším komentáři jste psal, že čím víc kódu, tím víc chyb. Jenže rozdíl ve velikosti Bitwardenu pri Android a iOS je v tom, že Bitwarden pro Android používá systémový WebView, zatímco Bitwarden pro iOS si sebou přinese vlastní jádro prohlížeče. Je to tedy do značné míry ten samý kód (odvozený z WebKitu), jenom je jednou součástí systému a jednou je součástí distribuce aplikace. Pokud v té většinové společné části bude chyba, bude i v té systémové i v té přibalené verzi. Takže neplatí tvrzení, že čím větší distribuční balíček, tím víc možných chyb – které jste se pravděpodobně pokoušel dokázat. Pokud jste nechtěl dokazovat tohle tvrzení, pak nevím, proč do diskuse o velikosti instalačního balíčku motáte velikost kódu.

Tak všechny aspekty, které jste zmiňoval jsou stejné.
Nejsou stejné. Ve vašem příkladu není splněn ten nejdůležitější předpoklad – že to usnadňuje vývoj té aplikace.

Ale ne na úkor uživatele.
Máte na výběr dvě varianty: 1. uživateli nedáte nic 2. uživateli dáte k dispozici software, který dělá, co potřebuje, ale je tak „velký“, že by se mu do mobilu s nejslabší konfigurací takových aplikací vešlo „jen“ 200. Varianta č. 2 není „na úkor uživatele“, protože uživatel je na tom lépe, než ve variantě 1. A kdyby mu ta velikost jó vadila, tak aplikaci odinstaluje a bude na tom pořád stejně, jako ve variantě 1.

Já chápu, že se efektivita ve státní správě neřeší, protože se tím udá další zakázka s upgradem, školením atd., Ale je to ignoranství.
Irelevantní nesmysl.

Jistě, ale není třeba kvůli tomu psát bloatware. Ostatní ho také nepišou. Koukněte na konkurenční produkty.
Který konkrétně konkurenční produkt? Jaký správce hesel je bezpečný, podporuje Windows, Linux, macOS, Android, iOS, web, plugin do prohlížečů, má plnohodnotnou automatickou synchronizaci (ne jen ukládání souborů na síťový disk), podporuje import, export, 2FA (pro přístup ke správci hesel), umí ukládat klíče TOTP a generovat z nich hesla, podporuje vlastní atributy, umožňuje nouzový přístup, a to vše za 10 USD ročně nebo méně? A umožňuje případně upgrade na rodinný účet za 40 USD ročně?

Já software posuzuju podle toho, jaké má funkce, ne jak je velký. Zajímalo by mne, co s těmi ušetřenými 300 MB na mobilu děláte. Uložíte tam další čtyři fotky?

Začal jste tím, že Bitwarden na iOS má 300 MB.

Ano to jsem psal.

Což je způsobené tím, že si sebou na iOS Bitwarden táhne celý prohlížeč, zatímco na Androidu používá WebView, které je součástí systému.

Asi jste smýchal reakce několika přispěvatelů dohromady. Já jsem nikdy nestavěl proti sobě iOS s electronem a Android s webview. Jen jsem se ptal na velikost. Naopak jsem hodil electron a webview do jednoho koše. V té paměti totiž udělají podobnou kaši.

Ve vašem příkladu není splněn ten nejdůležitější předpoklad – že to usnadňuje vývoj té aplikace.

Napsat aplikaci pro jeden operační systém je zcela jistě jednodušší než psát aplikaci pro 2 nebo 3 operační systémy. Vážně se neshodneme ani na tomto?

Jaký správce hesel je bezpečný, podporuje Windows….

Tak pokud tím chcete říct, že vlastně nemáte jinou možnost, tak tomu se říká dělat z nouze cnost.

Jinak multiplatformních password managerů je celá řada a není moc těch, co by klienty stavěla na browseru. Řekl bych, že sám některé znáte. A pokud chcete agumentovat cenou, tak vás ubezpečuji, že jestli je aplikace zdarma, tak náklady na její vývoj nejsou opravdu nulové. Ergo podle ceny v *storu nelze porovnávat náklady.

Vysvětlovat vliv velikosti kódu aplikace na rychlost běhu, na latenci, přepínání kontextu, tlak na paměť atd. někomu, kdo považuje 300MB za ekvivalent 4 fotek pořízených mobilem je asi zbytečné. Tak snad jen, že o místo na flashce fakt (primárně) nejde. Vy jste třeba zvyklý na pomalé aplikace a ani vám to nepřijde. A webové aplikace prostě jsou pomalé i na rychlých strojích. Tečka. Z podobného důvodu jsou u uživatelů velmi „populární“ třeba desktopové multiplatformní Java aplikace (ideálně ve swingu „aby to bylo všude stejné‘).

Podívejte, já fakt nemám potřebu vás o nečem nadmíru přesvědčovat. Jen jsem se vyjádřil ke způsobu implementace té aplikace a vy jste se toho chytil a zúžil si to jen na to místo na flashce. Ok. Vy ten dopad nevnímáte. Chápu a tím bych to uzavřel.

Jen jsem se ptal na velikost.
Jenže jste smíchal dohromady velikost distribuce a velikost zdrojového kódu. I když zanedbáme rozdíly v použitých nástrojích (např. programovací jazyk), pořád velikost distribuce neodpovídá počtu chyb v aplikaci.

Napsat aplikaci pro jeden operační systém je zcela jistě jednodušší než psát aplikaci pro 2 nebo 3 operační systémy. Vážně se neshodneme ani na tomto?
Ne, neshodneme. Napsat aplikaci s pomocí Electronu, která poběží na Windows, MacOS a Linuxu není těžké. Pro většinu vývojářů je to podstatně jednodušší, než napsat tutéž aplikaci v C++ s Windows API pro jeden OS.

Tak pokud tím chcete říct, že vlastně nemáte jinou možnost, tak tomu se říká dělat z nouze cnost.
Já jinou možnost nijak extra nehledám, protože jsem spokojen s tím, co mám. Pokud by se objevilo něco lepšího, asi se o tom dříve či později dozvím. Z nouze ctnost z toho nedělám, protože 300 MB aplikace není nic, co bych řešil.

Jinak multiplatformních password managerů je celá řada
Multiplatformnost je pro mne jenom jedno z mnoha kritérií.

není moc těch, co by klienty stavěla na browseru
Správce hesel používám především v prohlížeči. Takže musí být řešen jako plugin do prohlížeče, tudíž postaven na webových technologiích. Nějak nevidím výhodu v tom, že když jednou za čas výjimečně budu potřebovat použít desktopovou verzi, bude vypadat a chovat se jinak.

A pokud chcete agumentovat cenou, tak vás ubezpečuji, že jestli je aplikace zdarma, tak náklady na její vývoj nejsou opravdu nulové.
To je dobře, že to víte. Tak si také uvědomte, že náklady na vývoj jedné multiplatformní aplikace jsou menší, než náklady na vývoj několika nativních aplikací.

Vysvětlovat vliv velikosti kódu aplikace na rychlost běhu, na latenci, přepínání kontextu, tlak na paměť atd. někomu, kdo považuje 300MB za ekvivalent 4 fotek pořízených mobilem je asi zbytečné.
Fotky z iPhone mohou mít 80 MB, takže do 300 MB se vám ani čtyři nevejdou. Zbytečné by hlavně bylo vysvětlovat něco, čemu nerozumíte. Velikost distribuce aplikace neznamená, že je to vše načtené v paměti při běhu aplikace a že se to vše při běhu používá.

A webové aplikace prostě jsou pomalé i na rychlých strojích. Tečka. Z podobného důvodu jsou u uživatelů velmi „populární“ třeba desktopové multiplatformní Java aplikace (ideálně ve swingu „aby to bylo všude stejné‘).
Tohle už dávno není pravda. Dnešní aplikace jsou mnohem rychlejší (z pohledu uživatele), než tomu bylo dříve.

Podívejte, já fakt nemám potřebu vás o nečem nadmíru přesvědčovat. Jen jsem se vyjádřil ke způsobu implementace té aplikace a vy jste se toho chytil a zúžil si to jen na to místo na flashce. Ok. Vy ten dopad nevnímáte. Chápu a tím bych to uzavřel.
On ten dopad neexistuje. To jsou jen nějaké vaše dohady vycházející z toho, že nevíte, jak vlastně software funguje. Kdybyste měl vedle sebe stejnou aplikaci napsanou jednou nativně a jednou ve webových technologiích, nepoznáte rozdíl v rychlosti.
Měli jsme třeba mobilní aplikaci, která byla kombinací nativních obrazovek a WebView. Audit zákazníka doporučil nepoužívat WebView a vše přepsat do nativních obrazovek – a jako příklad nevhodné obrazovky uvedli nativní obrazovku. A není to jediný případ, kdy někdo kritizoval webové technologie, interpretovaný kód, Javu, C# apod. a vyzdvihoval nativní kód, ale když se šlo na konkrétní příklady, myslel si, že interpretovaný kód nebo web je nativní a nativní kód považoval za něco napsaného třeba v Javě. Ne že by to bylo 100% opačně, ale prostě nedokázal rozlišit, co je co.

Jenže jste smíchal dohromady velikost distribuce a velikost zdrojového kódu.

Aplikace jako celek je sice děravá a útočník získá kontrolu nad jejím během, ale podle vás je vše OK, protože v tom HTML/CSS/JS to není. Máte zvláštní přístup k bezpečnosti.

Ne, neshodneme.

K prokázání vaší teorie nestačí ukázat jeden příklad, který jí vyhovuje, když existuje jiný, který jí vyvrací.

Já jinou možnost nijak extra nehledám,

Vy jste se na jiné možnosti ptal.

náklady na vývoj jedné multiplatformní aplikace jsou menší, než náklady na vývoj několika nativních aplikací.

Ano, bude nákladnější. To jste nevěděl, že kvalitnější věci jsou holt nákladnější?
Jakým koeficientem se ty náklady promítnou do ceny výsledného produktu je úplně jiná otázka.

Nad to electron/webview resp. web UI není jedinou možností jak psát multiplatformní aplikace. Jen je tou nejméně kvalitní.

Velikost distribuce aplikace neznamená, že je to vše načtené v paměti při běhu aplikace a že se to vše při běhu používá.

Tak jste mě donutil to po letech nainstalovat. Na disku to má 345MB. Naimportoval jsem tam cca 536KB hesel a poznámek a výsledkem je cca 370MB v RAM. Po chvíli používání to atakuje hranici 400MB. Samotný electron framework soubor má 291MB. Vaše teorie zní sice krásně, ale realita je jiná. Vybraný řádek se záznamem nejde posunout kurzorovými klávesami, ty posouvají celé okno, mezi záznamy se skáče tabem zrovna jako po ostatních elementech, sidebar není přizpůsobitelný atd. atd.. Prostě webová stránka.

Jak říkám, jako nouzovka akceptovatelné. V ostatních případech na úkor uživatelů.

On ten dopad neexistuje.

Existuje, ale pokud se pohybujete pouze mezi webovými aplikacemi, tak to nejste ochoten nebo schopen vnímat. K vašim podnikovým aplikacím se z taktních důvodu vyjadřovat nebudu. Ostatně možná se to za těch 13-14 let změnilo. Ale když porovnáte podobné aplikace Atom/VSCode vs. Sublime/Espresso nebo webový vs. nativní excel/word…, Fusion360 atd. atd. ten rozdíl v chování UI je zřejmý i pro laika.

Kdybyste věděl jak opravdu funguje UI, tak takové nesmysly nepíšete.

Co to plácáte za nesmysly? Já jsem nic takového nepsal. Já se vám pouze snažím vysvětlit, že když bude chyba v jádru prohlížeče, aplikace tou chybou bude postižená vždy, když to jádro používá – nezávisle na tom, zda je to jádro součástí operačního systému, knihovny, která se stáhne pomocí závislostí, nebo přímo instalačního balíčku.

K prokázání vaší teorie nestačí ukázat jeden příklad, který jí vyhovuje, když existuje jiný, který jí vyvrací.
Já jsem žádnou svou teorii neprokazoval. Já jsem jen vyvrátil vaši teorii.

Vy jste se na jiné možnosti ptal.
Protože jste tvrdil, že existují.

Ano, bude nákladnější. To jste nevěděl, že kvalitnější věci jsou holt nákladnější?
Pravděpodobnější je, že se ty náklady ušetřené na vývoji jedné multiplatformní aplikace využijí na zlepšení kvality výsledného softwaru. Třeba přidání dalších funkcí, lepší otestování aplikace, lepší podpora.
Holt každý oceňujeme jiné kvality aplikací – já bezpečnost, potřebné funkce, funkčnost, vy zase to, že ušetříte 200 MB na disku. Gratuluju, ušetřil jste 0,05 halíře.

Nad to electron/webview resp. web UI není jedinou možností jak psát multiplatformní aplikace. Jen je tou nejméně kvalitní.
Je to možnost, která do těch podporovaných platforem zahrne i web. A mobilní platformy. Je to nejlevnější možnost. Můžete psát multiplatformní aplikace v C++ a Qt, nebo v Javě, ale tím nepokryjete tolik platforem a stejně nebudete mít nativní aplikace (Qt není na WIndows ani MacOS nativní).

Vaše teorie zní sice krásně, ale realita je jiná.
To ovšem váš pokus nedokazuje. To, že je něco namapované do RAM, neznamená, že je to tam nahrané a že se to používá.

V ostatních případech na úkor uživatelů.
Neposuzujte všechny uživatele podle sebe. Vaše požadavky jsou velmi specifické.

Existuje, ale pokud se pohybujete pouze mezi webovými aplikacemi, tak to nejste ochoten nebo schopen vnímat.
Donedávna jsem používal víc newebových aplikací než webových. Teď už se to možná přehouplo na opačnou stranu, ale nijak radikálně.

Ale když porovnáte podobné aplikace Atom/VSCode vs. Sublime/Espresso nebo webový vs. nativní excel/word…, Fusion360 atd. atd. ten rozdíl v chování UI je zřejmý i pro laika.
Laici ten rozdíl už pár let nepoznají. Ty podobné aplikace jste vybral dobře. Ještě bych přidal třeba GMail a Thunderbird. A teď si u těch aplikací porovnejte počty uživatelů.

Kdybyste věděl jak opravdu funguje UI, tak takové nesmysly nepíšete.
Já vím, jak funguje UI. V době, kdy už spousta lidí tvrdila, že všechno má být webové, jsem obhajoval nativní UI s tím, že pořád i běžným uživatelům poskytuje i běžným uživatelům více funkčnosti, než webové UI. Jenže doba pokročila a dneska už v drtivé většině případů není ve webovém UI nic, co by běžným uživatelům chybělo. Naopak je to UI často lepší, než nativní UI – protože docílit toho samého v nativním UI by bylo podstatně náročnější. Třeba responzivita nebo přístupnost. Není to proto, že by webové technologie byly na UI vhodnější – to, že se staví UI aplikací na objektovém stromu vytvořeném ze značkovacího jazyka pro hypertext, je šílenost. Je to proto, že na tom webovém UI už bylo odvedeno daleko víc práce – takže spoustu věcí stačí vzít a použít.

24. 11. 2023, 20:05 editováno autorem komentáře

Ten nesmysl o pravděpodobnosti výskytu chyb v kódu, vylučující knihovny jste psal vy.

Já jsem jen vyvrátil vaši teorii.

Tvrzení o existenci jevu A nelze vyvrátit existencí jevu B, který nevylučuje existenci jevu A.

náklady ušetřené na vývoji jedné multiplatformní aplikace využijí na zlepšení kvality výsledného softwaru

Ale prosím vás. Oba víme, jak to ve skutečnosti funguje. Co nejvíc funkcí za co nejmíň peněz. Kvantita se prezentuje jako kvalita.

To, že je něco namapované do RAM, neznamená, že je to tam nahrané a že se to používá.

To je sice pravda, ale s uvedenými fakty to nesouvisí.

Mimochodem po pár hodinách si to vzalo už přes 500MB (reálné paměti). Za čas by to asi část hodilo do swapu, ale nedostalo to šanci. Už je to pryč.

Vaše požadavky jsou velmi specifické.

Ano, velmi specifické. Shrnul bych je do specifikace: co nejvyšší bezpečnost a efektivita práce. To pochopitelně web UI aplikacím nevyhovuje. Neznám jedinou web UI aplikaci, která by dosahovala kvalit nativní. A pokud vůbec taková existuje, tak dala jistě víc práce než ta nativní.

Abych byl korektní tak nemohu mluvit za Windows prostředí. Ale zase si říkám, že MS nemůže snad být tak pozadu...

Laici ten rozdíl už pár let nepoznají.

Ale poznají a docela bezpečně, jen se jich nemůžete ptát po pár kliknutí.

Ten nesmysl o pravděpodobnosti výskytu chyb v kódu, vylučující knihovny jste psal vy.
Já jsem nepsal, že knihovny vylučují chyby. Já se vám jen marně snažím vysvětlit, že když knihovnu přesunete z distribuce aplikace mimo aplikaci, chyby v knihovně nezmizí.

Ale prosím vás. Oba víme, jak to ve skutečnosti funguje. Co nejvíc funkcí za co nejmíň peněz. Kvantita se prezentuje jako kvalita.
Tak to možná děláte vy.

To je sice pravda, ale s uvedenými fakty to nesouvisí.
Uvedená fakta ovšem neříkají nic o porovnnání zabrané fyzické RAM u webové a nativní aplikace se stejnými funkcemi.

co nejvyšší bezpečnost a efektivita práce
Efektivita práce vás naopak vůbec nezajímá. Klidně obětujete efektivitu práce za pár volných MB na disku.

Ale poznají a docela bezpečně, jen se jich nemůžete ptát po pár kliknutí.
Uživatelé si vybírají webové aplikace.

Já se vám jen marně snažím vysvětlit, že když knihovnu přesunete z distribuce aplikace mimo aplikaci, chyby v knihovně nezmizí.

O proč to děláte, když jsem nikdy netvrdil opak? To vy mi pořád vyčítáte, že míchám vlastní kód aplikace s jejich knihovnami.

Uvedená fakta ovšem neříkají nic o porovnnání zabrané fyzické RAM u webové a nativní aplikace se stejnými funkcemi.

Ale prosím vás. To už je trochu křečovité, nemyslíte? Bavíme se tady o password manageru. Když už nemáte odhad na zdrojovou náročnost core funkcionality takové ve své podstatě triviální aplikace, tak by vás aspoň mohlo zarazit, že to během pár hodin použivání (procházení menu, procházení záznamů) zabralo navíc dalších víc než 120MB. Nativní ekvivalent zabere max těch 120MB.

Efektivita práce vás naopak vůbec nezajímá. Klidně obětujete efektivitu práce za pár volných MB na disku.

Už jednou jsem říkal, že vůbec nejde o to zabrané místo na disku. Evidentně si neuvědomujete další důsledky zabraných zdrojů systému a jejich vliv na práci Řadu z nich, a rozhodně ne všechny, jsem již také uvedl. Ale navíc se ty web UI aplikace nechovají podle zaběhnutých rutin v daném prostředí. Konkrétní excesy toho bitwardenu jsem také už uvedl a mezi tím přišel i na další.

Uživatelé si vybírají webové aplikace.

… když jim nedáte na výběr, tak ano :-). Troufnu si tvrdit, že je výrazně více uživatelů nativních MS Office než webového ekvivalentu. To samé platí i u Apple aplikací jako jsou Pages, Numbers a Keynote.

To vy mi pořád vyčítáte, že míchám vlastní kód aplikace s jejich knihovnami.
Vždyť to děláte. Nelíbila se vám velikost aplikace a odůvodňoval jste to tím, že čím větší je distribuovaná aplikace, tím více chyb.

Když už nemáte odhad na zdrojovou náročnost core funkcionality takové ve své podstatě triviální aplikace
Jenže já se nechci omezovat jen na nějakou core funkcionalitu. Já chci, aby aplikace měla všechny funkce, které používám.

tak by vás aspoň mohlo zarazit, že to během pár hodin použivání (procházení menu, procházení záznamů) zabralo navíc dalších víc než 120MB.
Nezaseknul jste se v minulém století? Dnešní počítače mají dost RAM. To, že aplikace reagují rychle, je dané i tím, že si věci cachují v RAM. Když je v RAM dost místa, není důvod z ní vyhazovat věci, které už se jednou spočítaly a mohly by se hodit i později.

Nativní ekvivalent zabere max těch 120MB.
„Ekvivalent“, který ale umí polovinu funkcí.

Evidentně si neuvědomujete další důsledky zabraných zdrojů systému a jejich vliv na práci
Ale uvědomuju. Jenom používám ty nejlepší nástroje a nevadí mi, že jsou náročnější na zdroje – protože se to mnohonásobně vyplatí. A nemám obsesi, že bych se kochal prázdnou RAM.

Ale navíc se ty web UI aplikace nechovají podle zaběhnutých rutin v daném prostředí.
To žádná multiplatformní aplikace. A někdy ani nativní aplikace. Akorát se ukázalo, že to uživatelům nevadí, protože používají různá prostředí, a používají web, takže jsou zvyklí na to, že se různé aplikace chovají různě. Navíc když člověk používá jednu aplikaci na více platformách, ocení víc to, když se chová všude stejně, než kdyby se chovala pokaždé jinak.

Konkrétní excesy toho bitwardenu jsem také už uvedl
Akorát že se to týká naprosto minoritního užití – a vůbec není jisté, jak by to mělo být správně, jestli jak chcete vy, nebo jak to dělá Bitwarden, nebo jinak.

… když jim nedáte na výběr, tak ano :-)
Aha, a co přesně uživatele nutí používat VS Code a ne Sublime/Espresso?

Nelíbila se vám velikost aplikace a odůvodňoval jste to tím, že čím větší je distribuovaná aplikace, tím více chyb.

To jste si dovodil špatně. Napsal jsem: Čím víc kódu, tím víc chyb. Vůbec jsem nespecifikoval jak se to poskládá.

Jenže já se nechci omezovat jen na nějakou core funkcionalitu

Že je tlačítko zelené nebo bíle nepovažuji za core funcionalitu. Psal jsem o tom, že ta aplikace spravuje nižší jednotky tisíc jednoduchých záznamů. Řadí je, vyhledává, přidává/generuje, edituje, maže, synchronizuje. Ta kompletní správa dat co ta aplikace nabízí se dá napsat do 1MB. 498M (a víc) je jen režije špatně vybraného UI. A to je jen jeho paměťová náročnost. Je už jasnější, co jsem myslel tím „core“?

„Ekvivalent“, který ale umí polovinu funkcí.

Ekvivalent co umí jen část věcí není ekvivalent. Já mluvil o ekvivalentu.

Dnešní počítače mají dost RAM.

Jo tohle už jsme taky slyšeli ve variantě „640k paměti musí stačit každému‘. Ne nestačí, ne počítače nemají dost paměti a notebooky nemají dost baterie. Právě kvůli vašemu přístupu. Právě kvůli vašemu přístupu musí firmy i jednotlivci kupovat stále výkonější stroje, aby mohli dělat stále stejnou práci za stejných nebo dokonce horších podmínek, protože tvůrci svoji neschopnost přenáší na uživatele. Právě kvůli vašemu přístupu se na IT produkty (např. ty podnikové) nadává kde to jde. A právě kvůli vašemu přístupu nejsou tvůrci schopni sebereflexe tudíž se to ani nelepší.

S těmi uživateli jste se už jednou sekl a teď znova. Ne, opravdu uživatel při procházení záznamů nečeká, že mu šipky posouvají okno, ale select resp. focus nasledujícího/před­cházejícího záznamu. A ctrl/cmd+a nemá vybrat komplet text v tom dialogovém okně, ale všechny záznamy. Tady na diskusi „jak to má ve skutečnosti být“ není prostor.

Aha, a co přesně uživatele nutí používat VS Code a ne Sublime/Espresso?

Spousta jiných věcí než je web UI. Dva různé produkty s různými funkcemi, různou marketingovou podporou se porovnávají podstatně hůř než ten web/native office od jedné firmy. To se taky můžeme bavit proč umřel Atom.

To jste si dovodil špatně. Napsal jsem: Čím víc kódu, tím víc chyb. Vůbec jsem nespecifikoval jak se to poskládá.
Použil jste to jako argument, proč je větší software horší.

Že je tlačítko zelené nebo bíle nepovažuji za core funcionalitu.
Já v případě správce hesel také ne.

Psal jsem o tom, že ta aplikace spravuje nižší jednotky tisíc jednoduchých záznamů. Řadí je, vyhledává, přidává/generuje, edituje, maže, synchronizuje. Ta kompletní správa dat co ta aplikace nabízí se dá napsat do 1MB.
Ona toho ta aplikace dělá daleko víc. To, že se něco dá napsat do 1 MB pro mne není žádný argument, když nenapíšete, kolik to bude stát. Pořád jako absolutní měřítko uplatňujete velikost programu a všechno ostatní tomu podřizujete – omezujete funkce, zvyšujete náklady na vývoj. Když vás tolik trápí velikost programu, nepoužívejte žádný program – ten bude mít nulovou velikost. Vaše kritéria splní nejlépe.

Je už jasnější, co jsem myslel tím „core“?
Ano, myslíte tím tak málo funkcí, aby se to dalo napsat do 1 MB. Bez ohledu na užitečnost takové aplikace.

Ekvivalent co umí jen část věcí není ekvivalent. Já mluvil o ekvivalentu.
To je fajn, že jste zjistil význam slova „ekvivalent“. Takže se můžeme vrátit k tomu, že budete hledat nějaký ekvivalent, se kterým budete Bitwarden porovnávat.

Právě kvůli vašemu přístupu musí firmy i jednotlivci kupovat stále výkonější stroje, aby mohli dělat stále stejnou práci za stejných nebo dokonce horších podmínek, protože tvůrci svoji neschopnost přenáší na uživatele.
Jste úplně vedle. Dnes dělají lidé stejnou práci nesrovnatelně efektivněji díky tomu, že používají daleko rychlejší software, který jim navíc poskytuje daleko víc funkcí. Ano, je to díky tomu, že to hardware umožňuje. Ale přece když umíme vyrobit vlak, který jezdí přes 200 km/h, nebudeme jezdit volským povozem s argumentem, že když budeme jezdit vlakem, budeme moc zhýčkaní.

S těmi uživateli jste se už jednou sekl a teď znova. Ne, opravdu uživatel při procházení záznamů nečeká, že mu šipky posouvají okno
Pletete se vy. Uživatel správce hesel nepoužívá tak, že by procházel záznamy. To je ten zásadní problém, že vy nevíte, jak se správce hesel používá (a nedivil bych se, kdyby příčinou bylo to, že používáte špatný správce hesel, který správné používání neumožňuje).

Tady na diskusi „jak to má ve skutečnosti být“ není prostor.
Prostor by tu byl, ale to byste nejprve musel alespoň vzdáleně tušit, jaké jsou nejdůležitější funkce správce hesel.

Spousta jiných věcí než je web UI. Dva různé produkty s různými funkcemi, různou marketingovou podporou se porovnávají podstatně hůř než ten web/native office od jedné firmy. To se taky můžeme bavit proč umřel Atom.
S tím porovnáním jste přišel vy. Atom umřel, protože byl nahrazen lepším VS Code. Kdyby uživatelé tak toužili po nativním Office, používají jen to. Jenže oni začali používat Google Doc, přecházejí na webový Office. Nativní Office používají proto, že už ho mají nainstalovaný z dřívějška, nebo ho větší instituce rovnou instalují všem uživatelům. Ale nemyslím si, že by se nedělo, že uživatel nativního Office přejde na webový, nebo nový uživatel začne používat ten webový. A to si nejsem jist, zda webový Office už má všechny funkce toho nativního – on je rozdíl ve vytváření nové aplikace a rozvoje aplikace s více než dvacetiletou historií.

Použil jste to jako argument, proč je větší software horší.

Ne. Nikde jsem nediferencoval stejnou knihovnu v systému a v distribuci aplikace.

Ona toho ta aplikace dělá daleko víc.

:-) to jistě, dopady toho, co dělá, jsou vidět na všech zdrojích systému, ale ani jedno z toho „víc“ nesouvisí s funkcí password manageru.

To, že se něco dá napsat do 1 MB pro mne není žádný argument, když nenapíšete, kolik to bude stát.

Odborník by měl mít odhad. Přinejmenším u trivialit.

Pořád jako absolutní měřítko uplatňujete velikost programu a všechno ostatní tomu podřizujete – omezujete funkce,

Kterou funkci jsem omezil?

vy nevíte, jak se správce hesel používá

:-) Asi

Prostor by tu byl, ale to byste nejprve musel alespoň vzdáleně tušit, jaké jsou nejdůležitější funkce správce hesel.

A já bláhový se domníval, že správce hesel je na správu hesel. Tak pojďte, vyveďte mě z temnoty.

používají daleko rychlejší software,

Vy fakt nemáte nejmenší tušení, co se děje v browseru pro vykreslení toho UI.

přecházejí na webový Office.

Nikoli. V podnicích i akademické sféře jede jen nativní verze. Občas někteří studenti používají nejprve webovou. Dříve či později ale drtivá většina přejde na nativní verzi se školní licencí.

PS. Tak 2 reakce zpět přemýšlím, jestli si na mne netestujete nějakou jednoduchou implemetaci jazykového modelu neuronové sítě. Některá opakující se argumentace začíná být podezřelá. A pokud je to tak, tak mě to docela pobavilo a připisuji vám body.

Nikde jsem nediferencoval stejnou knihovnu v systému a v distribuci aplikace.
Psal jste o velikosti aplikace. Když je knihovna přibalená k aplikaci, je aplikace o tu knihovnu větší.

:-) to jistě, dopady toho, co dělá, jsou vidět na všech zdrojích systému, ale ani jedno z toho „víc“ nesouvisí s funkcí password manageru.
Výše jsem uváděl, jaké požadavky mám na fungování správce hesel. DOkonce jsem některé samozřejmosti ani neuvedl.

Odborník by měl mít odhad. Přinejmenším u trivialit.
Když vy ten odhad nemáte, znamená to, že nejste odborník?

Kterou funkci jsem omezil?
Zatím jste radši neuvedl, jaké funkce má podle vás mít správce hesel. Z toho, co tu naznačujete, se zdá, že jste omezil i jednu ze základních funkcí – vyplňování hesel do webových stránek. Pak také asi vyhledávání. A pravděpodobně i mnohé další, když jste se podivoval, jaké funkce po správci hesel požaduji já – a to nechci nic extra.

A já bláhový se domníval, že správce hesel je na správu hesel. Tak pojďte, vyveďte mě z temnoty.
Musí zajišťovat bezpečný přístup k heslům, tj. aby e k heslům nedostal nikdo jiný a zároveň aby se k nim dostal vlastník hesel, kdykoli potřebuje. To druhé podle mne vyžaduje automatickou synchronizaci hesel mezi více zařízeními a také to, aby byl správce hesel dostupný na každé platformě, kterou uživatel používá. Dále je potřeba, aby správce hesel sám nabízel ke vložení relevantní hesla v internetovém prohlížeči (ochrana proti phishingu). Také musí být použití správce hesel jednoduché, aby ho uživatel opravdu používal. A podle mne musí správce hesel umožňovat i export hesel v čitelném formátu kompatibilním s dalšími správci, aby uživatel nezůstal zamčen v jednom správci hesel.

Vy fakt nemáte nejmenší tušení, co se děje v browseru pro vykreslení toho UI.
Nebojte se, vím, co bláznivého se děje, aby se vykreslilo UI v prohlížeči. Ale zároveň vím, že je to dost rychlé, aby to pro uživatele bylo nerozeznatelné od nativního UI. Pokud se vám webové UI všude vykresluje pomalu, je to nějaký problém vaší instance, ne obecný problém.

Nikoli. V podnicích i akademické sféře jede jen nativní verze. Občas někteří studenti používají nejprve webovou. Dříve či později ale drtivá většina přejde na nativní verzi se školní licencí.
Jasně, takže Microsoft vyvíjí webovou verzi Office proto, že ji nikdo nepoužívá.

Některá opakující se argumentace začíná být podezřelá.
Kdybyste neopakoval stejné nesmysly, nemusel bych vám to opakovaně vyvracet.

Když je knihovna přibalená k aplikaci, je aplikace o tu knihovnu větší.

A když tu knihovnu linker vezme jinde, tak je v té paměti, světe div se, stejně velká.

Když vy ten odhad nemáte

Na tu cenu jste se ptal vy mne. Já si ten odhad jsem schopen udělat.

Zatím jste radši neuvedl, jaké funkce má podle vás mít správce hesel.

Uvedl jsem zcela konkrétní a vy jen reagoval, že to nestačí. Ničím konkrétním; tedy do teď. Tak se pojďme na ně podívat. Zabezpečené úložiště a synchronizace – tu jsem zmiňoval a zahrnul jsem i potřebné šifrovací funkce i práci se soubory. Kdybyste měl nezvladatelnou touhu trvat na HTTPS protokolu a trochu si to ulehčit, tak s použitím libcurl to nafouknete o nějaký 1-2MB, ale veskrze to není nutné.

Takže ve skutečnosti tu máme „relevantní hesla“ – jasně, najít příslušné heslo podle url, když ho předem získám z atributu url z properties stránky, chce fakt fištróna a hodiny vývoje a „export hesel v čitelném formátu kompatibilním s dalšími správci” – všichni podporují CSV. To je školní úloha pro středoškoláka pro samostatnou práci, kterou odevzdá ještě tutéž vyučovací hodinu. Bez jakýchkoli knihoven. Ad Jednoduchost – to je UI doména, kterou jsem jasně a explicitně oddělil od výkonných (core) funkcí. Takže suma sumáru jsme se s náročností jak na zdroje, tak na vývoj nepohnuli.

Tak mě napadá, jestli vás ti vaši programátoři tzv. netahají za fusekli, když dostáváte podklady….

Když si vybavím to UI bitwardenu, tak bych neřekl, že to obsahovalo něco extra netypického – formulářové prvky, listy, tlačítka, sidebar, nějaký další dialogy. Ty jo, to bych si klidně i vsadil, že třeba ve SwiftUI, Gtk i Qt to bude jednodušší než to řešit v CSS a JS, aby to vypadalo jako nativní aplikace. Ale co to povídám, vy si to UI zjednodušíte, ořežete a pak budete tvrdit, že jste to takhle vlastně chtěl od začátku, protože to i uživatele takhle chtějí a nebo je jim to jedno.

takže Microsoft vyvíjí webovou verzi Office proto, že ji nikdo nepoužívá.

Oba můžeme jen spekulovat. Má to třeba ochránit ty stávající uživatele, kteří jsou nuceni využívat Google doc, a za další přilákat nové uživatele, ze kterých by se rekrutovali noví platící.

Kdybyste neopakoval stejné nesmysly, nemusel bych vám to opakovaně vyvracet.

Když vám některé informace nedávájí smysl a považujete je za nesmysly, tak ten problém nemusí být v těch informacích. Někdy stačí si ty informace pořádně přečíst a nedomýšlet si něco, co v nich není,

A když tu knihovnu linker vezme jinde, tak je v té paměti, světe div se, stejně velká.
Jenže vy jste nepsal o paměti, ale o velikosti distribuce. Nebylo by na čase, kdybyste místo kličkování konečně přiznal, že jste napsal nesmysl a velikost distribuce nemá žádnou přímou souvislost s počtem chyb?

Na tu cenu jste se ptal vy mne. Já si ten odhad jsem schopen udělat.
No tak si ho udělejte. Zjistíte, že by stejná funkcionalita byla neuvěřitelně drahá.

Uvedl jsem zcela konkrétní a vy jen reagoval, že to nestačí.
Uvedl jste akorát správu záznamů (obecně). To opravdu pro správce hesel nestačí.

Zabezpečené úložiště a synchronizace – tu jsem zmiňoval a zahrnul jsem i potřebné šifrovací funkce i práci se soubory.
Nezmiňoval. A pro synchronizaci nestačí práce se soubory, potřebujete tam práci se změnami.

jasně, najít příslušné heslo podle url, když ho předem získám z atributu url z properties stránky, chce fakt fištróna a hodiny vývoje
Já jsem nikde nepsal, že je to nějak složité. Jenom podle vašich komentářů to vypadá, že to váš správce hesel neumí. Nebo ho vy neumíte používat.

„export hesel v čitelném formátu kompatibilním s dalšími správci” – všichni podporují CSV
Opět, nepsal jsem, že je to složité. Psal jsem, že to považuju za nezbytnou součást správce hesel.

To je školní úloha pro středoškoláka pro samostatnou práci, kterou odevzdá ještě tutéž vyučovací hodinu. Bez jakýchkoli knihoven.
Jasně, a vznikne z toho další nekompatibilní formát, který selže, když bude v hesle mezera nebo v nějakém textu diakritika. Nejdřív píšete o chybách v kódu, a pak chcete dát přednost vlastní implementaci před použitím ověřeného kódu z knihovny.

Ad Jednoduchost – to je UI doména, kterou jsem jasně a explicitně oddělil od výkonných (core) funkcí.
Za prvé, jednoduchost UI nelze oddělit od toho, čemu říkáte core. Za druhé, neoddělil jste to jasně, „core“ v tomto kontextu klidně mohlo znamenat ty nejpodstatnější funkce, které musí mít každý správce hesel.

Tak mě napadá, jestli vás ti vaši programátoři tzv. netahají za fusekli, když dostáváte podklady….
Já žádného správce hesle nevyvíjím.

Když si vybavím to UI bitwardenu, tak bych neřekl, že to obsahovalo něco extra netypického – formulářové prvky, listy, tlačítka, sidebar, nějaký další dialogy. Ty jo, to bych si klidně i vsadil, že třeba ve SwiftUI, Gtk i Qt to bude jednodušší než to řešit v CSS a JS, aby to vypadalo jako nativní aplikace. Ale co to povídám, vy si to UI zjednodušíte, ořežete a pak budete tvrdit, že jste to takhle vlastně chtěl od začátku, protože to i uživatele takhle chtějí a nebo je jim to jedno.
Možná byste si spíš místo hloupých keců měl prohlédnout nějakého rozumného správce hesel, abyste viděl, co dělá. Pro zadávání nových záznamů a jejich editaci potřebujete formulářové prvky a tlačítka, pro zkopírování či vložení loginu, hesla, OTP potřebujete tlačítka, pro zobrazení seznamu hesel potřebujete list, pro zobrazení skupin potřebujete list. Sidebar se používá v desktopovém GUI pro zobrazení skupin. Nevím, co je na čemkoli z toho pro vás překvapivého.

Když vám některé informace nedávájí smysl a považujete je za nesmysly, tak ten problém nemusí být v těch informacích. Někdy stačí si ty informace pořádně přečíst a nedomýšlet si něco, co v nich není,
Já předpokládám, že informace, které píšete, se vztahují k této diskusi. Pokud píšete něco úplně mimo téma, pak se nedivte, že mi ty informace nedávají smysl.

jste napsal nesmysl a velikost distribuce nemá žádnou přímou souvislost s počtem chyb?

Jenže ona má. Víc kódu => víc chyb. A dokonce jste to potvrdil.

Zjistíte, že by stejná funkcionalita byla neuvěřitelně drahá.

Nikoli. To jen vy nevíte, kolik času zabere otevřít soubor a zapsat do něj šifrovaná data. Je to velmi jednoduché a levné. Stejně jako ostatní funkce, které jsme spolu probrali.

A pro synchronizaci nestačí práce se soubory, potřebujete tam práci se změnami.

Ale zmínil. Koukněte na reakci 25. 11. 2023 20:10.

Děláte z komára velblouda. Pro vás je všechno problém. I jednoduché věci, které se učí studenti středních škol, jsou pro vás složité a nákladné.

Trváte na tom, že jsem nezmínil všechny funkce a pak doplníte pouze 2 a k tomu takové, které jsou jednoduché a s bezvýznamným dopadem na vývoj.

Pro zadávání nových záznamů a jejich editaci potřebujete formulářové prvky a tlačítka, pro zkopírování či vložení loginu, hesla, OTP potřebujete tlačítka, pro zobrazení seznamu hesel potřebujete list, pro zobrazení skupin potřebujete list. Sidebar se používá v desktopovém GUI pro zobrazení skupin. Nevím, co je na čemkoli z toho pro vás překvapivého.

Máte problém s chápáním psaného textu. Psal jsem: Když si vybavím to UI bitwardenu, tak bych neřekl, že to obsahovalo něco extra netypického...

Jediné, co mě překvapuje, že ze vcelku jednoduché aplikace děláte komplikovaný program, který zkrátka musí v paměti zabrat půl giga..

Jenže ona má. Víc kódu => víc chyb. A dokonce jste to potvrdil.
Nic takového jsem nepotvrdil, protože je to nesmysl. Vy jste měl možnost s toho nesmyslu vycouvat, místo toho na něm trváte. Není pravda ani to, že více kódu znamená více chyb. A není pravda, že větší distribuce znamená více kódu.

To jen vy nevíte, kolik času zabere otevřít soubor a zapsat do něj šifrovaná data.
Vím, jenže na rozdíl od vás také vím, že tohle nezajistí synchronizaci hesel napříč více zařízeními.

Pro vás je všechno problém. I jednoduché věci, které se učí studenti středních škol, jsou pro vás složité a nákladné.
Nikoli. Problém je, že vy netušíte, co se za kterými funkcemi skrývá. Škoda, že jste neporadil třeba Linusovi, když psal git, že nic takového není potřeba, protože pro synchronizaci změn napříč zařízeními stačí zapsat do souboru a je hotovo.

Psal jsem: Když si vybavím to UI bitwardenu, tak bych neřekl, že to obsahovalo něco extra netypického...
Ano, máte pravdu, přehlédl jsem se.

Jediné, co mě překvapuje, že ze vcelku jednoduché aplikace děláte komplikovaný program, který zkrátka musí v paměti zabrat půl giga..
Za prvé, ta aplikace není zas až tak triviální, jak si myslíte. Za druhé, ta aplikace samozřejmě nemusí zabrat v paměti půl giga. Můžete ji samozřejmě napsat místo jednoho kódu sdíleného napříč platformami šestkrát, pro každou platformu extra. Nebo radši osmkrát, pro Linux by bylo vhodné mít to v Gtk, Qt a ještě aspoň v wxWidgets , ať je na výběr. A pro každou platformu nativně. Sice bude vývoj dvacetkrát dražší, ale on to někdo zaplatí…

Není pravda ani to, že více kódu znamená více chyb.

Tak jsem se pro zajímavost kouknul, kdo je autorem této všeobecně známé (kromě vám) poučky. Takže vedete válku proti Tannenbaumovi, Gatesovi, Knuthovi a pravděpodobně dalším. Potopeno. Kruh už vám házet nebudu.

tohle nezajistí synchronizaci hesel napříč více zařízeními.

Jistě a synchronizace nezajistí export a export nezajistí generování atd. atd. Práce s úložištěm je jedna funkce a synchronizace jiná. Není potřeba to míchat nesmyslně dohromady.

ta aplikace není zas až tak triviální, jak si myslíte.

Ani jedna část nebo funce, která tu byla zmíněna, není komplikovaná, jak si myslíte vy. Vesměs se jedná o středoškolskou úroveň.

Tak jsem se pro zajímavost kouknul, kdo je autorem této všeobecně známé (kromě vám) poučky. Takže vedete válku proti Tannenbaumovi, Gatesovi, Knuthovi a pravděpodobně dalším. Potopeno. Kruh už vám házet nebudu.
Vysvětlení je daleko jednodušší. Prostě jste je nepochopil. Což není zas tak překvapivé, když tvrzení o velikosti distribuce softwaru zkoušíte dokazovat tvrzením o velikosti kódu.

Jistě a synchronizace nezajistí export a export nezajistí generování atd. atd. Práce s úložištěm je jedna funkce a synchronizace jiná. Není potřeba to míchat nesmyslně dohromady.
Vážně mne nenapadlo, že jednoduchost aplikace budete dokazovat tím, že si vyberete tu nejjednodušší funkci aplikace a o ní budete tvrdit, že je jednoduchá.

Ani jedna část nebo funce, která tu byla zmíněna, není komplikovaná, jak si myslíte vy. Vesměs se jedná o středoškolskou úroveň.
To, že si nedovedete představit nic složitějšího, než co zvládnou napsat středoškolští studenti, neznamená, že nejde nic udělat na lepší úrovni. Já bych třeba studenty střední školy nenechal psát vážně míněnou aplikaci pro správu hesel. Protože tam nejde jen o databázi hesel, ale jde i o to, aby ta hesla z aplikace neunikala nebo aby útočník nezmanipuloval snadno uživatele, že mu heslo prozradí.

Vysvětlení je daleko jednodušší. Prostě jste je nepochopil. Což není zas tak překvapivé, když tvrzení o velikosti distribuce softwaru zkoušíte dokazovat tvrzením o velikosti kódu.

Vám pořád nedochází, že střílíte slepými. Přestaňte se točit pořád dokolečka kolem té „distribuce”, kterou jste si sám vymyslel. Nezachrání vás. Tahle kapitola je uzavřená.

Vážně mne nenapadlo, že jednoduchost aplikace budete dokazovat tím, že si vyberete tu nejjednodušší funkci aplikace a o ní budete tvrdit, že je jednoduchá.

Práci se soubory jste z celého mého výčtu vybral vy. Kdyby to nebylo jasné, tak opakuji – vy. Opět podsouváte něco, co jste udělal sám.

Já rozebíral všechny vaše funkce, které měly mít negativní dopad na náklady vývoje, což se ovšem neukázalo a navíc jste to u některých z nich přiznal.

To, že si nedovedete představit nic složitějšího, než co zvládnou napsat středoškolští studenti, neznamená, že nejde nic udělat na lepší úrovni

Tak ve vašem duchu: To, že vy s takovou aplikací máte problém neznamená, že by to nezvládl středoškolák. Znalosti na to mají. Zbytečně je podceňujete. Drtivou většinu těch funkcí i ve školách dělají vč. bezpečnosti.

Přestaňte se točit pořád dokolečka kolem té „distribuce”, kterou jste si sám vymyslel.
Ne, o distribuci jste začal psát vy, v komentáři, který celé tohle nesmyslné vlákno začal.

Tahle kapitola je uzavřená.
Ano, je to dávno uzavřené, ukázalo se, že píšete nesmysly. Akorát vám to pořád ještě nedošlo. Tak že by konečně?

Práci se soubory jste z celého mého výčtu vybral vy. Kdyby to nebylo jasné, tak opakuji – vy. Opět podsouváte něco, co jste udělal sám
Nemyslím si, že bych tenhle komentář psal já.

Já rozebíral všechny vaše funkce, které měly mít negativní dopad na náklady vývoje, což se ovšem neukázalo a navíc jste to u některých z nich přiznal.
Ne, nerozebíral jste ani zdaleka všechny nutné funkce správce hesel. Stále ještě není jisté, zda vůbec víte, které funkce to jsou.

Tak ve vašem duchu: To, že vy s takovou aplikací máte problém neznamená, že by to nezvládl středoškolák. Znalosti na to mají. Zbytečně je podceňujete. Drtivou většinu těch funkcí i ve školách dělají vč. bezpečnosti.
Chybí jim znalosti, které chybí i vám, takže o tom nemůžete vědět, že jim chybí. Bezpečnost správce hesel totiž nespočívá v tom, jak se zašifrovaná data zapíšou do souboru. To je na tom to nejjednodušší. Bezpečnost je všechno to okolo – jak se zachází s heslem, jak se zašifrovanými a dešifrovanými údaji, jak se komunikuje s uživatelem, jak se data synchronizují přes cloud aby k nim provozovatel neměl přístup… Máte přesně ten naivní přístup, že když data před uložením zašifrujete AESem, máte zajištěnou bezpečnost. Jenže tak to není.

Ne, o distribuci jste začal psát vy, v komentáři, který celé tohle nesmyslné vlákno začal.

Zase se pletete. První zmíňka o distribuci byla od vás zde. Já jsem jen upozorňoval na velikost té aplikace a že vzhledem k tomu, co má dělat, je neúměrně nafouklá a má logicky i vyšší pravděpodobnost výskytu chyb, než by mohla mít. Což jste označil za nesmysl, s odůvodněním, že to nafukují knihovny a začal jste se zamotávat do svých vlastních konstrukcí systémové vs. aplikační knihovny, dynamické vs. statické linkování, které jsem nikdy nerozporoval. Ten problém jste si vytvořil vy. Pravděpodobně tím, že jste nepochopil postatu tvrzení „čím víc kódu, tím víc chyb“.

Nemyslím si, že bych tenhle komentář psal já.

Pomohu vám se v tom trochu zorientovat. V tomto komentáři píšu, že
a) nemáte odhad o práci se soubory a šifrováním dat
b) práce se soubory se šifrovaním dat je jednoduchá a implementace není nákladná
c) a teď pozor – doslova: „Stejně jako ostatní funkce, které jsme spolu probrali.“

Na což jste reagoval, že zápis do souboru nezajistí synchronizaci.

Stále ještě není jisté, zda vůbec víte, které funkce to jsou.

V tom případě máte stejný problém, když je nejste sám schopen na několik výzev doplnit. Vy vůbec rád argumentujete práznými bublinami.

Bezpečnost je všechno to okolo – jak se zachází s heslem, jak se zašifrovanými a dešifrovanými údaji, jak se komunikuje s uživatelem, jak se data synchronizují přes cloud aby k nim provozovatel neměl přístup… Máte přesně ten naivní přístup, že když data před uložením zašifrujete AESem, máte zajištěnou bezpečnost. Jenže tak to není.

Ne, naivní přístup nemám, jen s tím mám i praktickou zkušenost a nejen teoretickou jako vy, a všechny tyhle okolnosti, které uvádíte, mi přijdou jaksi … normální, logické, přirozené. Zrovna tak, jako spoustu jiných věcí, které jsme tu detailně nerozebírali. Hlavně je řešíte všude a web UI resp. JS vám v tom nepomůže. Naopak JS tu bezpečnost komplikuje.

Já jsem jen upozorňoval na velikost té aplikace
Ano, takže velikost aplikace jste začal řešit vy. Jestli je to velikost distribučního balíčku nebo velikost nainstalované aplikace je celkem jedno, protože tam je rozdíl akorát v kompresi pro přenos.

vzhledem k tomu, co má dělat, je neúměrně nafouklá a má logicky i vyšší pravděpodobnost výskytu chyb, než by mohla mít
Přičemž z vašich vyjádření vůbec není jisté, že víte, co ta aplikace má dělat. No a na tom, že velikost aplikace znamená i větší výskyt chyb, právě logického není nic. Protože, jak už jsem vám mnohokrát vysvětloval, např. to, zda k aplikaci přibalíte nějakou knihovnu, nebo zda se ta aplikace na cílový systém dostane nějak jinak, má na velikost aplikace zásadní vliv. Na počet chyb v aplikaci to nemá absolutně žádný vliv. Počet chyb v aplikaci můžete snížit také třeba tak, že místo nízkoúrovňového C napíšete aplikaci ve vyšších jazycích – třeba Python, Java, JavaScript. A aplikace tím zase nabobtná. Nebo počet chyb v aplikaci snížíte tak, že použijete ověřenou a často používanou knihovnu, místo abyste si ten kód psal sám. Jenže tím aplikace opět nebobtná, protože ta knihovna bude obsahovat i funkce, které nepoužijete. Nebo-li je mnoho situací, kdy zmenšení počtu chyb v aplikaci způsobí zvětšení aplikace.

Navíc to, co tady celou dobu propagujete – tedy nativní aplikace – by naopak znamenalo zvětšení množství kódu, protože to, co je teď napsané jednou a běží to na všech platformách, byste musel napsat pro každou platformu zvlášť.

Takže se přestaňte tvářit jako největší expert, a radši si nastudujte, co se dá dělat proto, aby software obsahoval méně chyb.Napovím vám, že nechávání průchodu NIH syndromu a psaní v nízkoúrovňových jazycích to není.

Pomohu vám se v tom trochu zorientovat. V tomto komentáři píšu, že
a) nemáte odhad o práci se soubory a šifrováním dat
b) práce se soubory se šifrovaním dat je jednoduchá a implementace není nákladná
c) a teď pozor – doslova: „Stejně jako ostatní funkce, které jsme spolu probrali.“
Zbývá už vyřešit jenom tři záhady: 1. na základě čeho jste zjistil, že nemám odhad o náročnosti takové implementace, když o tom předtím vůbec nebyla řeč 2. proč jste si k odhadování náročnosti vývoje aplikace vybral tu jednodušší funkci 3. jak jste přišel na tu bláznivou myšlenku, že bezpečnost aplikace je daná jednom tím, jak bezpečné jsou dílčí programové funkce a vůbec nezáleží na celém komplexu, jak se jednotlivé části aplikace ovlivňují.

V tom případě máte stejný problém, když je nejste sám schopen na několik výzev doplnit.
Ale já už jsem je doplnil. Že vy jste je stále nevzal na vědomí, to není můj problém.

Ne, naivní přístup nemám, jen s tím mám i praktickou zkušenost a nejen teoretickou jako vy, a všechny tyhle okolnosti, které uvádíte, mi přijdou jaksi … normální, logické, přirozené.
Jasně, tak proto pitváte nepodstatné detaily a tím podstatným se nezabýváte.

web UI resp. JS vám v tom nepomůže
POmůže vám např. v tom, abyste nenapsal triviální buffer overflow chybu, která by způsobila spuštění cizího kódu v rámci procesu správce hesel.

Ano, takže velikost aplikace jste začal řešit vy. Jestli je to velikost distribučního balíčku nebo velikost nainstalované aplikace je celkem jedno, protože tam je rozdíl akorát v kompresi pro přenos.

Zdá se, že jste to konečně pochopil. Ano řešil jsem velikost aplikace přesněji řečeno kódu, protože o tom to tvrzení o chybách je.

No a na tom, že velikost aplikace znamená i větší výskyt chyb, právě logického není nic.

Aha, tak nepochopil. No nic. Tady nepomůže ani Tanenbaum.

Navíc to, co tady celou dobu propagujete – tedy nativní aplikace – by naopak znamenalo zvětšení množství kódu

Do kódu se počítá veškerý kód aplikace. Nejen ten co, si vy vyberete. Chyby totiž mohou mít i ty knihovny, pro které platí stejná úměra. Můžete se bít do prsou jak chcete, že bitwarden nemá jedinou chybu, ale pokud ji mají knihovny (jako, že měly a pravděpodobně mají), tak je dědí celá aplikace. Jestli by tím byl postihnut i bitwarden nemůžete z principu dopředu vyloučiit. Kompletní kód by byl u nativní aplikace zlomkový sečteno přes všechny platformy.

protože to, co je teď napsané jednou a běží to na všech platformách, byste musel napsat pro každou platformu zvlášť.

Jenže vy mluvíte jen o části kódu nad nějakou více-či méně sjednocenou vrstvou a vůbec si neuvědomujete, že kompletní kód té aplikace má platformě závislé části, které musely být napsané pro každou platformu zvlášť. A především ten browser tam přidává enormní složitost. A zcela zbytečnou.

na základě čeho jste zjistil, že nemám odhad o náročnosti takové implementace, když o tom předtím vůbec nebyla řeč

Na základě toho, že jste kritizoval, že jsem vám nenapsal cenu. Byla o tom řeč zde

proč jste si k odhadování náročnosti vývoje aplikace vybral tu jednodušší funkci

Náhodný výběr zástupce většiny takových. Nemyslím, že byste reagoval jinak na jiný výběr z té většiny.

jak jste přišel na tu bláznivou myšlenku, že bezpečnost aplikace je daná jenom tím, jak bezpečné jsou dílčí programové funkce a vůbec nezáleží na celém komplexu, jak se jednotlivé části aplikace ovlivňují.

Tato myšlenka není moje.

Ale já už jsem je doplnil. Že vy jste je stále nevzal na vědomí, to není můj problém.

K tomu, co jste doplnil, jsem se beze zbytku vyjádřil.

Pomůže vám např. v tom, abyste nenapsal triviální buffer overflow chybu, která by způsobila spuštění cizího kódu v rámci procesu správce hesel.

To jste se moc netrefil. Buffer overflow chyby se nevyhýbají ani v8. Electron bohužel obsahoval chybu, která umožňovala spustit cizí kód.

Ano řešil jsem velikost aplikace přesněji řečeno kódu, protože o tom to tvrzení o chybách je.
No to je právě hlavní váš problém v této části diskuse, že volně zaměňujete velikost kódu a velikost aplikace. Stále jste nepochopil, že to není jedno a to samé.

Aha, tak nepochopil. No nic. Tady nepomůže ani Tanenbaum.
OK, nevyvrátil jste žádný můj argument. Takže to chápu tak, že proti nim nic nemáte, považujete je za správné. Akorát se nechcete smířit se závěry, které z toho plynou. To je ale váš problém, že vědomě odmítáte něco, o čem víte, že je to správně.

Do kódu se počítá veškerý kód aplikace. Nejen ten co, si vy vyberete. Chyby totiž mohou mít i ty knihovny, pro které platí stejná úměra.
Výborně, jste na dobré cestě, možná to pochopíte. Když chcete měřit velikost kódu včetně použitých knihoven, nemůžete to odvozovat od velikosti aplikace (nainstalované nebo distribučního balíčku), protože tam jednou ta knihovna může být a podruhé ne – ale pořád se používá, takže velikost kódu je pořád stejná. To se vám tu marně snažím vysvětlit už asi ve stém příspěvku.

Jinak dobrá a používaná opensource knihovna má daleko méně chyb, než aplikační kód stejného rozsahu. Prostě proto, že je pod daleko větším drobnohledem, provede se na ní daleko víc testů, věnuje se tomu kódu daleko víc práce.

Kompletní kód by byl u nativní aplikace zlomkový sečteno přes všechny platformy.
To je nesmysl. U multiplatformní aplikace máte ten kód napsaný jednou, u nativních aplikací by musel být napsaný opakovaně. Mohl byste argumentovat tím, že u multiplatformní aplikace je tam zbytečný kód v podobě celého prohlížeče. No jo, jenže jedna z vašich platforem (ta nejdůležitější) je webový prohlížeč, takže tam ten webový prohlížeč jaksi je tak jako tak.

Jenže vy mluvíte jen o části kódu nad nějakou více-či méně sjednocenou vrstvou a vůbec si neuvědomujete, že kompletní kód té aplikace má platformě závislé části, které musely být napsané pro každou platformu zvlášť. A především ten browser tam přidává enormní složitost. A zcela zbytečnou.
To je ovšem úplně mimo realitu, viz předchozí bod.

Na základě toho, že jste kritizoval, že jsem vám nenapsal cenu.
Nic takového jsem nepsal.

Náhodný výběr zástupce většiny takových.
A úplně náhodou vám to vyšlo na triviální funkci, která je stejně implementovaná ve spoustě jiného softwaru a pro správce hesel je vlastně nezajímavá (ne že by se obešel bez ní, ale v té jednoduchosti, jak jí popisujete, na ní vlastně není co zkazit).

Tato myšlenka není moje.
No ale řídíte se jí. Protože složitost vývoje správce hesel odvozujete od triviálních funkcí a ty podstatné ignorujete.

To jste se moc netrefil. Buffer overflow chyby se nevyhýbají ani v8. Electron bohužel obsahoval chybu, která umožňovala spustit cizí kód.
Napsat buffer overflow chybu vedoucí ke spuštění cizího kódu v JavaScriptu je podstatně složitější, než napsat ji v C/C++. A takový kód má podstatně omezenější možnosti, než nativní kód.

Ano, v samotné knihovně také může být chyba. Jenže její pravděpodobnost je daleko menší, než u aplikačního kódu. Protože kód (používané) knihovny je daleko používanější, vidí ho daleko víc lidí, projde daleko větším množstvím testů, než kód aplikace. To samozřejmě nezapadá do vašeho absolutně zjednodušeného modelu, že množství chyb je z drtivé většiny závislé jen na množství kódu. Ale je to fakt. Dokud nepochopíte, jak chyby v kódu vznikají a jak se jim dá předcházet, nalézat je a odstraňovat, jsou veškeré vaše úvahy o chybách v softwaru k ničemu.

No to je právě hlavní váš problém v této části diskuse, že volně zaměňujete velikost kódu a velikost aplikace. Stále jste nepochopil, že to není jedno a to samé.

Co tím chcete o 381MB electron frameworku říct?

protože tam jednou ta knihovna může být a podruhé ne – ale pořád se používá, takže velikost kódu je pořád stejná. To se vám tu marně snažím vysvětlit už asi ve stém příspěvku.

Marně, protože to je irelevantní. Tenhle tvrzení vůbec nic ohledně velikosti kódu a počtu chyb nedokazuje ani nerozporuje. Bavíme se o aplikaci, jejíž drtivou část zabírá 381MB electronu.
tak ještě jednou
a ještě jednou
a ještě jednou

Jinak dobrá a používaná opensource knihovna má daleko méně chyb,

Já vím, že tvrzení „víc kódu => víc chyb“ známých osobností IT, a které má údajně i přesah do ekonomie, nerozumíte. To už jsme si vyjasnili - tedy to, že tomu nerozumíte. Není nutné na to stále upozorňovat.

U multiplatformní aplikace máte ten kód napsaný jednou, u nativních aplikací by musel být napsaný opakovaně

Něco ano, něco ne. Určitě ne tolikrát, kolik je platforem.
Ne každé multiplatformní prostředí musí mít 381MB s převahou zbytečného kódu a být špatně integrované do prostředí operačního systému a browseru.

Nic takového jsem nepsal.

Ale psal: 1 MB pro mne není žádný argument, když nenapíšete, kolik to bude stát.

A úplně náhodou vám to vyšlo na triviální funkci,

Kdybyste něco věděl o pravděpodobnosti, tak by vás to nepřekvapilo.

No ale řídíte se jí.

Vašimi myšlenkami se vážně neřídím.

To samozřejmě nezapadá do vašeho absolutně zjednodušeného modelu, že množství chyb je z drtivé většiny závislé jen na množství kódu.

To byste mi lichotil. Ten model není můj. Ale pokud nepochopíte jeho podstatu, tak se nemá smysl o tom bavit. Pro detail vám uniká celek.

30. 11. 2023, 12:44 editováno autorem komentáře

Co tím chcete o 381MB electron frameworku říct?
O čem píšete? O velikosti zdrojáků nebo o velikosti sestavené aplikace/knihovny?

Snad není tak těžké odlišit zdrojáky a sestavenou aplikaci/knihovnu, tak proč vám to pořád dělá takový problém?

Tenhle tvrzení vůbec nic ohledně velikosti kódu a počtu chyb nedokazuje ani nerozporuje. Bavíme se o aplikaci, jejíž drtivou část zabírá 381MB electronu.
Zase. První věta o kódu, druhá o sestavené aplikaci/knihovně. Vážně je pro vás tak těžké to rozlišit?

Já vím, že tvrzení „víc kódu => víc chyb“ známých osobností IT, a které má údajně i přesah do ekonomie, nerozumíte. To už jsme si vyjasnili - tedy to, že tomu nerozumíte. Není nutné na to stále upozorňovat.
To není tvrzení známých osobností, je to vaše tvrzení. A je nepravdivé, jak jsem na mnoha příkladech ukázal.

Něco ano, něco ne. Určitě ne tolikrát, kolik je platforem.
Jasně, napíšete kód v C++ pro Linux, a pak ho spustíte v pluginu prohlížeče, který umí jen JavaScript.

Ne každé multiplatformní prostředí musí mít 381MB s převahou zbytečného kódu a být špatně integrované do prostředí operačního systému a browseru.
Kolik je těch multiplatformních prostředí, která pokryjí všechny hlavní platformy – tedy web, iOS, Android, Windows, MacOS, Linux? Web+Electron, a asi ještě Flutter? Do prostředí operačního systému je Electron integrován dostatečně – a není žádné jiné multiplatformní prostředí, které by to dělalo výrazně lépe. Ono to totiž ani moc nejde, protože pak už se vám ztrácí výhody multiplatformnosti – protože pak stejně UI musíte psát pro každý systém jinak. Navíc dokonalé zapadnutí do prostředí OS je věc, kterou jsou posedlí někteří vývojáři – ale uživatele to absolutně nezajímá.

Ale psal: 1 MB pro mne není žádný argument, když nenapíšete, kolik to bude stát.
Takže nepsal. Nešlo o to, že bych tu cenu potřeboval vědět já. Jde o to, že si to musíte uvědomit vy.

Kdybyste něco věděl o pravděpodobnosti, tak by vás to nepřekvapilo.
Fajn. Tak když to víte, tak už vám snad konečně došlo, že náročnost implementace programu nemůžete posuzovat podle těch triviálních úloh, ale podle těch nejsložitějších.

Vašimi myšlenkami se vážně neřídím.
Ano, ke své škodě.

To byste mi lichotil. Ten model není můj. Ale pokud nepochopíte jeho podstatu, tak se nemá smysl o tom bavit. Pro detail vám uniká celek.
Podstata toho modelu je, že je chybný. Já jeho podstatu chápu. Dokonce rozumím i tomu, proč někdo, kdo nemá o vývoji softwaru moc představu, dojde k představě, že tenhle model funguje. Ale vysvětlil jsem vám několik důvodů, proč ten model nefunguje, proč je hrubě nedostatečný.

O čem píšete? O velikosti zdrojáků nebo o velikosti sestavené aplikace/knihovny?

Ten electron framework je v aplikaci ve spustitelné podobě. Ale u vás mě taková otázka nepřekvapuje.

První věta o kódu, druhá o sestavené aplikaci/knihovně.

Možná mi nebudete věřit, ale sestavená aplikace/knihovna je plná spustitelného kódu.

To není tvrzení známých osobností, je to vaše tvrzení.

Tanenbaum: Computer Networks 5. vydání, strana 16 https://imgur.com/a/ZXZGMRa

Jasně, napíšete kód v C++ pro Linux, a pak ho spustíte v pluginu prohlížeče, který umí jen JavaScript.

Pluginy prohlížeče nemusí být v JS. Na některých platformách vůbec nepotřebujete plugin do prohlížete, abyste v něm vyplňoval hesla.

Ale ano, něco zvlášť píšete.

Kolik je těch multiplatformních prostředí, která pokryjí všechny hlavní platformy

Takové, které mají v pořádku integraci do okolního prostředí, tak takové neexistují.
Tak ještě jednou. Buďto to odfláknete a problém přehodíte na uživatele a nebo to uděláte pořádně a bude to něco stát.

Ale psal: 1 MB pro mne není žádný argument, když nenapíšete, kolik to bude stát.
Takže nepsal. Nešlo o to, že bych tu cenu potřeboval vědět já. Jde o to, že si to musíte uvědomit vy.

To tvrdíte teď :-) Sám jste později tvrdil, že jsem si vybral pouze jednoduché části. Což rozporuje, že by to bylo nákladné. Když byste věděl, že to, co jsem uvedl, není nákladné, proč byste mě naváděl, abych si to uvědomil? Kdepak, daleko jednodušší vysvětlení je, že jste si to neuvědomil a nebo nemáte tušení o psaní nativního kódu.

Tak když to víte, tak už vám snad konečně došlo, že náročnost implementace programu nemůžete posuzovat podle těch triviálních úloh, ale podle těch nejsložitějších.

Tak tohle je vážně blbost. Úplně stejná, jako tvrdit opak. Což jsem nikdy netvrdil.

Podstata toho modelu je, že je chybný. Já jeho podstatu chápu. ...kdo nemá o vývoji softwaru moc představu,...

Označovat Knutha nebo Tanenbauma, že nemají o vývoji představu… Ale jo, nikdo vás nenutí s nimi souhlasit. Jen to vypadá směšně.

Ten electron framework je v aplikaci ve spustitelné podobě.
Výborně, bavíme se tedy o spustitelné podobě. Tak to zkuste podržet v hlavě a neargumentovat tvrzeními, která se týkají zdrojového kódu.

Ale u vás mě taková otázka nepřekvapuje.
Když nechápete elementární věci, musím vás otázkami navést k tomu, abyste si rozdíl mezi zdrojovým kódem a sestavenou aplikací uvědomil.

Možná mi nebudete věřit, ale sestavená aplikace/knihovna je plná spustitelného kódu.
Jenže spustitelný kód je něco jiného než zdrojový kód.

Tanenbaum: Computer Networks 5. vydání, strana 16 https://imgur.com/a/ZXZGMRa
Víte o tom, že je tam napsáno něco jiného, než tvrdíte vy?

Pluginy prohlížeče nemusí být v JS.
Pro desktopové prohlížeče musí. Prohlížeče nic jiného nepodporují. Na mobilech prohlížeče obvykle ani žádné pluginy nepodporují.

Na některých platformách vůbec nepotřebujete plugin do prohlížete, abyste v něm vyplňoval hesla.
Podstatné je to, že na některých platformách potřebujete plugin do prohlížeče, abyste v něm správně vyplňoval hesla z externího správce hesel.

Buďto to odfláknete a problém přehodíte na uživatele a nebo to uděláte pořádně a bude to něco stát.
Uživatel ale chce jednu aplikaci ovládat stále stejně, bez ohledu na to, na jakém systému ji zrovna spustí. Špatně by bylo naopak vaše řešení, kdyby se aplikace chovala pokaždé jinak.

Když byste věděl, že to, co jsem uvedl, není nákladné, proč byste mě naváděl, abych si to uvědomil?
Protože ani to, co jste napsal, není zadarmo. A vy zjevně náklady ignorujete úplně. Na to jsem se vás snažil upozornit – že každý vývoj něco stojí. A že sice můžete psát správce hesel rovnou ve strojovém kódu, aby tam nebyl ani bit navíc, ale nikdy se při takovém vývoji nedoplatíte.

Tak tohle je vážně blbost. Úplně stejná, jako tvrdit opak. Což jsem nikdy netvrdil.
Z náročnosti implementace jedné triviální úlohy se nedozvíte vůbec nic. Z náročnosti implementace těch nejnáročnějších úloh si uděláte rámcovou představu. Může se pak stát, že těch triviálních úloh bude spousta a to množství způsobí, že to bude podstatné i vedle těch nejnáročnějších úloh. Takže se může ukázat, že odhad podle těch nejnáročnějších úloh je nedostatečný. Ale pořád je to alespoň nějaký odhad, který nějak souvisí s realitou.

Označovat Knutha nebo Tanenbauma, že nemají o vývoji představu…
Já neoznačuju Knutha ani Tanenbauma, označuji vás. Vy tady diskutujete, žádný Knuth ani Tanenbaum. Ti se akorát chudáci nemohou bránit tomu, co jim podstrkáváte, bez jediné citace. Když jste konečně něco citoval, ukázalo se, že je tam napsáno něco jiného, než tvrdíte vy.

Výborně, bavíme se tedy o spustitelné podobě. Tak to zkuste podržet v hlavě a neargumentovat tvrzeními, která se týkají zdrojového kódu.

Zase to plete. Já jsem o zdrojovém kódu mluvil pouze v souvislosti s implementací funkce programu.

Z hlavy vám ale vypadlo, na co jste to reagoval, tak připomínám:

No to je právě hlavní váš problém v této části diskuse, že volně zaměňujete velikost kódu a velikost aplikace. Stále jste nepochopil, že to není jedno a to samé.

Co tím chcete o 381MB electron frameworku říct?

https://imgur.com/a/ZXZGMRa
Víte o tom, že je tam napsáno něco jiného, než tvrdíte vy?

Ano. Je to v angličtině. Tolik k rozdílům.

Pluginy prohlížeče nemusí být v JS.
Pro desktopové prohlížeče musí.

Nemusí. Safari podporuje Swift příp. ObjC a drtivá většina podporuje webassembly. Jen připomínám, že se bavíme o implementaci funkcí password manageru, protože už vidím, jak do toho začnete motat, že to pouští JS.

Navíc v tom browseru uživatel IMHO nepotřebuje kompletního klienta.

Uživatel ale chce jednu aplikaci ovládat stále stejně, bez ohledu na to, na jakém systému

To je klasická alibistická výmluva vývojářů takových odfláknutých produktů. Rozhodně se to netýká standardních ovládacích prvků, klávesových zkratek, struktury menu, standardních dialogových oken, notifikací atd. Příklad s označením obsahu dialogového okna jako webové stránky místo označení všech prvků listu už jsem uváděl zde. A víte proč to mají špatně? Protože je to moc práce (ne-li nemožné), dát to v tom web UI dopořádku.

Protože ani to, co jste napsal, není zadarmo. A vy zjevně náklady ignorujete úplně. Na to jsem se vás snažil upozornit – že každý vývoj něco stojí.

Zase ten váš problém s psaným textem: tady nebo tady

Každý vývoj něco stojí. Ten odfláknutý třeba za starou bačkoru.

Z náročnosti implementace jedné triviální úlohy se nedozvíte vůbec nic. Z náročnosti implementace těch nejnáročnějších úloh si uděláte rámcovou představu.

Z náročnosti jedné nejnáročnější úlohy si uděláte stejnou špatnou představu jako z jedné nejtriviálnější, když neznáte jejich zastoupení v celém projektu.

Když jste konečně něco citoval, ukázalo se, že je tam napsáno něco jiného, než tvrdíte vy.

Ukázal se jedině fakt, že té problematice moc nerozumíte, zaměňujete spustitelný kód se zdrojovým kódem, nemáte moc odhad na náročnost vývoje, čtete tak napůl, libujete si v odfláknuté práci, upřednosňujete kvantitu před kvalitou, výroková logika vás taky minula, zvýšení počtu instrukcí na stejnou funkci považujete za zrychlení softwaru, rád druhým podsouváte svoje dohady, často popíráte, co jste dřív tvrdil, základní věci jsou pro vás komplikované, počítače mají podle vás dost RAM, atd. atd.

Pokud s tím problematickým čtením máte nějakou diagnózu, tak se vážně omlouvám. Kdybyste to zmínil na začátku, tak bych byl býval taktnější.

Ano. Je to v angličtině. Tolik k rozdílům.
Tak si to nechte přeložit nějakým překladačem, jestli tomu nerozumíte. Tvrzení na obrázku je výrazně odlišné od vašeho tvrzení.

Nemusí. Safari podporuje Swift příp. ObjC a drtivá většina podporuje webassembly. Jen připomínám, že se bavíme o implementaci funkcí password manageru, protože už vidím, jak do toho začnete motat, že to pouští JS.
OK, Safari je výjimka. WebAssembly pořád není nativní kód, navíc bez JavaScriptu je vám v prohlížeči k ničemu.

Rozhodně se to netýká standardních ovládacích prvků
Standardní ovládací prvky nepoužívají vždy ani produkty od stejné firmy, která produkuje ten operační systém. A uživatelé určitě nejsou zvědaví na to, aby stejná aplikace vypadala pokaždé úplně jinak podle toho, kde ji spustí.

klávesových zkratek, struktury menu, standardních dialogových oken, notifikací atd.
To všechno se dá s Electronem zařídit.

Příklad s označením obsahu dialogového okna jako webové stránky místo označení všech prvků listu už jsem uváděl zde. A víte proč to mají špatně? Protože je to moc práce (ne-li nemožné), dát to v tom web UI dopořádku.
Mýlíte se. „Špatně“ to mají z toho důvodu, že je to funkce, která nedává žádný smysl, nikdo jí nikdy nepoužil ani nechtěl použít. Když omylem zmáčknete Ctrl+A, označí vám to veškerý obsah. No bóže. Tak to nemačkejte.

Z náročnosti jedné nejnáročnější úlohy si uděláte stejnou špatnou představu jako z jedné nejtriviálnější, když neznáte jejich zastoupení v celém projektu.
Nikoli. Z nejtriviálnější se nedozvíte nic. Z náročnosti těch nejnáročnějších úloh se dozvíte dolní odhad pracnosti, a odvodíte z toho i celkový odhad – protože ve většině aplikací je rozložení triviálních a náročných úloh podobné.

zaměňujete spustitelný kód se zdrojovým kódem
Ne, to já fakt nedělám. To děláte vy, když soustavně píšete o „kódu“, aniž byste specifikoval, zda myslíte zdrojový nebo spustitelný.

Abychom se někam posunuli. Tady máte tři příklady zdrojového kódu:

A:

#include <stdio.h>
#include <stdlib.h>

#define bsize  32768

int main() {
    FILE *sfile = fopen("source.txt", "rb");
    FILE *tfile = fopen("target.txt", "wb");
    byte buffer[bsize];
    size_t read = fread(buffer, 1, bsize, sfile);
    fwrite(buffer, 1, read, tfile);
    fclose(tfile);
    fclose(sfile);
    return 0;
}

B:

#include <stdio.h>
#include <stdlib.h>

#define bsize  4096

int main() {
    FILE *sfile = fopen("source.txt", "rb");
    FILE *tfile = fopen("target.txt", "wb");
    byte buffer[bsize];
    size_t read;
    while ((read = fread(buffer, 1, bsize, sfile)) > 0) {
        fwrite(buffer, 1, read, tfile);
    }
    fclose(tfile);
    fclose(sfile);
    return 0;
}

C:

#!/bin/sh
cp source.txt target.txt

Seřaďte je 1. podle velikosti kódu 2. podle množství chyb.

Jestli ten shellový skript zařadíte doprostřed, tak už fakt nevím.

Tvrzení na obrázku je výrazně odlišné od vašeho tvrzení.

Není. Pokusím se to, alespoň částečně, vysvětlit na vašem příkladu dole.

OK, Safari je výjimka. WebAssembly pořád není nativní kód,

Když si přečtete můj první příspěvek ve vlákně, tak zjistíte, že jsem si přimárně stěžoval na něco jiného. Ale ano, ani ve WA bych nedělal kompletní UI. Do browseru bych dal jen tu část, která se bezprostředně týká toho automatického generování a vyplňování hesel. (nejsem si jist, jestli by to s něčím nekolidovalo, omlouvám se, nechce se mi teď nad tím přemýšlet; vycházím jen z alternativních řešení a neznám detailně chování všech platforem)

A uživatelé určitě nejsou zvědaví na to, aby stejná aplikace vypadala pokaždé úplně jinak podle toho, kde ji spustí.

Tak ona nemusí vypadat úplně jinak i když bude používat nativní GUI toolkit. Ano, je to jedna z věcí, na které se neshodneme.

To všechno se dá s Electronem zařídit.

Možná ano, ale neviděl jsem. Každopádně to bude znamenat větší úsilí než s nativním GUI toolkitem, kde jsou takové věci hotové (přípravené).

Když omylem zmáčknete Ctrl+A, označí vám to veškerý obsah. No bóže. Tak to nemačkejte.

Problém je, že já to nezmáčkl omylem. Já chtěl označit všechny záznamy. Naprosto nevinně.

Seřaďte je 1. podle velikosti kódu 2. podle množství chyb.

Prosím vás, to tvrzení o velikosti kódu a počtu chyb je z oblasti statistiky. Je o pravděpodobnost výskytu chyb. Nikoli o výskytu chyb. To by byl z jejich úst opravdu nesmysl. Ano v tom výroku to explicitně uvedeno není, ale IMHO to z kontextu jasně vyplývá. Pravděpodobnost výskytu jevu nesouvisí s výsledkem pozorováním jednoho konkrétního jevu. A my většinou nejsme schopni určit a dokázat, že daný program neobsahuje chyby. Proto je třeba takové případy zkoummat statistickými metodami. K vašemu příkladu:

Velikost: První je shell skript. Zjednodušeně shell a cp k tomu skriptu potřebujete. Jinak ta funkce nebude fungovat. Samozřejmě je potřeba i operační systém atd., ale to u všech variant.

-rwxr-xr-x 1 root   root   1265648 Apr 23  2023  /usr/bin/bash
-rwxr-xr-x 1 root   root    151152 Sep 20  2022  /usr/bin/cp
-rwxr-xr-x 1 tom5   tom5     16104 Dec  2  00:25 A
-rwxr-xr-x 1 tom5   tom5     16104 Dec  2  00:25 B

Nepřipočítával jsem tam knihovny, protože ty nůžky by se jen víc rozevřely.

Jestli ten shellový skript zařadíte doprostřed, tak už fakt nevím.

Pst chyby: Teď už asi tušíte, že nebude druhý, ale bude první. A to právě z toho důvodu, že je do toho nutné počítat i ten bash (i cp). A shodou okolností není to tak dávno, co měl bash nějaký bezpečnostní problém přes proměnné prostředí. (Mám takový pocit, že snad umožňoval i spustit kód.) Navíc bash načítá rc/profile skripty. To je další stupeň volnosti pro vznik chyby. Zjednodušeně – v případě toho skriptu je tam daleko víc míst, které mohou obsahovat chybu (nelze to vyloučit)

Nevím jestli se mi to podařilo vysvětlit. Ale je to vlastně jedno. Myslím, že k tomu bylo řečeno z obou stran vše. Navrhuji jít dělat něco produktivnějšího.

Do browseru bych dal jen tu část, která se bezprostředně týká toho automatického generování a vyplňování hesel.
Takže část věcí by uživatel řešil v pluginu v prohlížeči, ale pro zbytek by si musel pustit externí aplikaci. Proč? Co by tím uživatel získal? Pořád tu argumentujete kvalitou softwaru a pohodlím uživatele, ale všechny vaše návrhy na změny by znamenaly výrazné zhoršení uživatelského komfortu.

Tak ona nemusí vypadat úplně jinak i když bude používat nativní GUI toolkit.
Pokud ho bude používat správně podle style guides, bude vypadat podstatně jinak. Ale hlavně, tahle otázka, jestli uživatelé upřednostňují nativní look and feel platformy, je už dvacet let zodpovězená: neupřednostňují. Je jim to úplně jedno.

Každopádně to bude znamenat větší úsilí než s nativním GUI toolkitem, kde jsou takové věci hotové (přípravené).
Nebude.

Já chtěl označit všechny záznamy.
Proč?

Prosím vás, to tvrzení o velikosti kódu a počtu chyb je z oblasti statistiky. Je o pravděpodobnost výskytu chyb. Nikoli o výskytu chyb.
Prima, že vám to konečně došlo. To ovšem na mém zadání nic nemění.

A my většinou nejsme schopni určit a dokázat, že daný program neobsahuje chyby.
To po vás také nikdo nechce.

Zjednodušeně – v případě toho skriptu je tam daleko víc míst, které mohou obsahovat chybu (nelze to vyloučit)
Dobře. Takže vám nejvyšší pravděpodobnost chyby vyšla u shellového skriptu, u kterého nevíte o žádné známé chybě a jehož kód používají denně miliony lidí na celém světě. Jako druhý vám tedy předpokládám vyšel program B, ve kterém jsou na první pohled chyby, protože neošetřuje okrajové situace jako neexistující soubor, nedostatečná oprávnění, plný disk a jiné chyby volaných funkcí. A jako program s nejmenší pravděpodobností chyby vám vyšel program, který zjevně nezvládne zkopírovat větší soubory.

Buď si programy, které používáte, vůbec nevybíráte podle toho, jakou pravděpodobnost chyby u nich vidíte. Nebo se tím řídíte, a pak je mi vaše hodnocení kvality programů úplně jedno, protože program, který hodnotíte nejlépe, já bych považoval za bezcenný šrot, který v žádném případě nebudu používat.

Co by tím uživatel získal?

On by hlavně tím nic neztratil.

už dvacet let zodpovězená: neupřednostňují.

To, že se mýlíte, jsme už uzavřeli.

Každopádně to bude znamenat větší úsilí než s nativním GUI toolkitem, kde jsou takové věci hotové (přípravené).
Nebude.

Realita je jiná. Nezužujte si GUI toolkit na grafickou podobu tlačítka.

To ovšem na mém zadání nic nemění.

Je zřejmé, že nechápete obor, který se nazývá matematická statistika.

Máte pravdu. Opravdu nechápu váš svět, ve kterém dáte přednost programu se známými chybami, kvůli kterým není možné ho používat, před programem, který podle vašich chybných úvah má statisticky více chyb. Naštěstí ale žiju v jiném světě, než vy.

Důvod je ten, že vaše úloha je fundamentálně jiná, než ta, na které vzniklo toto vlákno. Vy ji pravděpodobně tak nevidíte, chápu to, já ale ano. Tak jen snad abychom se profesně nepotkali a ušetřili se dalších zbytečných konfliktů.

Vaše tvrzení o velikosti kódu a chybách nebylo nijak omezené, tvářilo se, že je univerzálně platné. Tedy by muselo platit i pro tu mou fundamentálně jinou úlohu. Pokud pro ni neplatí, znamená to, že to tvrzení minimálně není platné univerzálně. Pokud platí jen za určitých podmínek, pak je potřeba specifikovat, za jakých – a pak ověřit, zda jsou ty podmínky splněné v případě správců hesel.

Koukněte na zeleného ufouna, v kategorii tlačítkových tejden vydrží prakticky každý s novou baterkou. Spíš je tam občas problém najít tlačítkový, ale nedůchodcovský.

[Wasper]
Ale ano, to urcite najdete.

Ja mam tlacitkovy CAT B30 a na jedno nabiti funguje klidne i ten tyden. Ovsem taky bez internetu, s mini displayem, na kterem tak tak zobrazite nenarocny obrazek. O kvalite zvuku asi nema cenu se bavit. Softwarove par zkladnich aplikaci a rozsireni maximalne tak nejaka ta jednoducha apka v Java ME a konec (a kdo vi, jestli si ji dneska nebude muset uzivatel naprogramovat sam, myslim, ze uz moc bezne nejsou). Takze o proti smartphone hodne omezeny sluzby a moznosti, tak se neni co divit, ze baterka vydrzi. Tedy pokud nezapnete bluetooth. To je nenazrane vsude.

Jenze prerecnik jasne specifikoval (aspon ja jej tak chapu), ze pozaduje smartphone, kteremu baterie vydrzi tyden. No nerikam , ze bych se zlobil, ale osobne si myslim, ze je to z technickeho hlediska dost nerealne. Alespon zatim.

21. 11. 2023, 16:29 editováno autorem komentáře

"z technickeho hlediska dost nerealne"

Ehm ... nokia + symbian. Byly na to i aplikace tretich stran, samozrejme wifi, data, ... a bez problemu to vydrzelo 200+hodin hovoru a 14 dnu iddle.

A kdyby se ten soucasny patlafoun udelal misto 3mm 6mm tlusty, tak by ta baterka mela kapacitu kupodivu taky dvojnasobnou.

Takze technicky to vubec problem neni.

Reálné to (smartphone s týdenní výdrží) je. Tedy: pokud se člověk smíří s Androidem... Jen musíte zapomenout na značkové přístroje.
Mně prošel rukama echt čínský Unihertz telefon, který ten tejden vydržel (bez BT...) fungovat vcelku běžně (Titan Pocket nebo Titan Slim), malý Jelly 2 zvládal na jedno nabití od pondělí do pátku.

[RRŠ]
No, nemuzu oponovat, ja ten telefon nevidel ani z rychliku. Faktem je, ze muj huhnavej nabizi 3 rezimy: normal, usporny a ultra. Na ten ultra je schpny i s tim BT vydrzet zhruba 20h v provozu, coz povazuji (ze svych zkusennosti) za velmi slusny vykon. Bez BT tak cca 35 - 38 h.

Osobne mam v planu, ze bych pristi rok sel do PinePhone a jsem zvedavy, jestli budu schopny jej v tomto smeru nejak vyznamne poladit, kdyz bych mel mit kontrolu jak nad systemem v telefonu tak pristup i k informacim o hw a schematu zapojeni. (coz u Androidu dneska nemam ani jedno).

21. 11. 2023, 17:03 editováno autorem komentáře

Ty telefony od Unihertzu jsou takové řešení stylu cena/výkon. Oproti PinePhone stojí půlku, ale zase je to Android místo Linuxu - pod kontrolou to člověk moc nemá.
Na druhou stranu tam není nabalené tolik balastu, jako na značkových telefonech, takže to tolik nežere baterku. Každopádně: výdrž v kolem jednoho dne mi přijde směšná - jsem zvyklý mít telefon na nabíječce někdy o weekendu a přes tejden se o nabíjení nestarat. (Byť je pravda, že vlastně nevím, kdy přesně mu ty baterky došly - prostě v pátek jsem telefonoval a v neděli to dám na nabíječku.)
Ale zkusím na některém (jsou v rodině) zapnout úsporný režim - to by mohl ten tejden dát i ten Jelly 2.

Každopádně: ten malý (Jelly) je telefon na telefonování - vejde se do ruky i do (té malé) kapsičky na kalhotách, ale na nějaké čtení, brouzdání, vyhledávání, případně sledování videa to má příliš malý display.
Člověk si musí rozmyslet, co od telefonu chce. ;o)

Spíš je tam občas problém najít tlačítkový, ale nedůchodcovský.

Občas? Já už rozumný tlačítkový telefon sháním roky... :-(

To jsme dva.
Ty Unihertzové Titany sice tlačítkové jsou, ale zase je tam těch tlačítek poněkud moc - jak na BlackBerry: celá klávesnice. ;o(
Nicméně na psaní SMS či e-mailů... - se to hodí. A ještě můře dítko machrovat, že má klávesnicovej mobil.

[RRŠ]
"A ještě můře dítko machrovat, že má klávesnicovej mobil."

Trochu OT - ale pripomel jste mi doby, co jsem, jakozto ditko skolou povinne, zavidel elektronicke diare (myslim, ze je vyrabelo Casio), ktere meli nekteri spoluzaci z ponekud ... rekneme movitejsich pomeru. :-D

[D.A.Tiger]
Taky jsem jedním (už co dospělý) disponoval. Ale pozor: já měl ještě předtím k disposici i EPSON HX-20 - takže nějaká CASIO databanka, to byla prostě jen moderní hračka pro děti. ;oD

[RRŠ]
Hele, nerikalo se, nahodou, pozdeji tehle masince "prvni notas"? Osmibitak s displyaem a paskovou tiskarnou v kufriku, hadam 16K RAM a mam ten dojem ze to dokonce melo disponovat vlastnim os a interpreterem BASICU. Cely to muselo byt na dnesni pomerny celkem tezky.

Husty, to uz je uplne jina liga. :)

Co si pamatuju, tak to vlastní OS nemělo, nebo bych tomu tak neříkal. Ale interpret BASICu tam byl. Programoval jsem si v tom nějakou databázi kontaktů...

To je pravděpodobné, ale já ty ostatní neznám.

Já jen chtěl zmínit, že to nemusí být jen na jednom telefonu, ale lze to uložit na více zařízení. Právě pro případ problému s jedním zařízením. Ona bezpečnost není zadarmo.

Problem hesiel je to, ze ich ludia pouzivaju vsade rovnake (takze nepomoze ze je dlhe) a prave voci tomu chrani TOTP, dnes je druhy fakto v lepsich sluznach standard.

No ked mas autentifikator of googlu na androidu, alebi Microsoft autentifikator tak si danu vec vies zalohovat k svojmu accountu jednym klikom.

"Problem hesiel je to, ze ich ludia pouzivaju vsade rovnake"

To neni problem hesel, to je problem tupcu, kteri hesla vyzaduji. Naprosto s klidem si treba tady nastavim 123465 ... a co jako. A s naprostym klidem pouziju presne stejny heslo i na 150ti dalsich webech.

Mimochodem ... Password0) ... jeste se mi nestalo ze by to neproslo pres kontrolu "bezpecnosti" hesla ...velky, maly, cislo, specielni znak ... OK, ubersecure a jedem dal.

Takze misto toho, aby si BFU (coz je 99% vsech) pamatoval jedno, byt hloupy heslo, bude muset jeste resit nejaky zalohovani(to je sprosty slovo?) neceho cemu vubec nerozumi ... uzasny ...
Ochrana jenom heslem, které si uživatel pamatuje, je nedostatečná. A není to problém jenom pro uživatele, ale i pro provozovatele. Takže takový způsob „zabezpečení“ můžete z porovnání rovnou vyřadit, není to přípustná alternativa.

I bez podobnych volovin za mnou zcela pravidelne chodi s tim, ze jim umrel telefon, a heslo si nepamatujou, protoze ho meli prece zcela bezpecne ulozene a prihlasovali se ksichtem.
Nebylo by tedy lepší, kdybyste jim pomohl rozchodit správce hesel, nějakého, kterého mohou mít na počítači i na mobilu a synchronizuje data? Ono se jaksi není co divit, že většina lidí nemá své počítačové účty dobře zabezpečené, když „IT odborníci“, na které se obrací, jim neumí správně poradit.

Ochrana jenom heslem, které si uživatel pamatuje, je nedostatečná.
Nemusí být. Uživatel si může klidně pamatovat heslo 2fr2xgf*pc+pcB2t - a na zabezpečení e-mailu běžného BFU je to dostatečně silné heslo. (Ano, když se budete hodně snažit a namáhat mozkové závity, možná přijdete na to, kde jsem zrovna tohle heslo vzal, což nic nemění na tom, že ani hrubou silou ani slovníkem to v rozumné době prolomit asi nepůjde.)

Nemusí být. Uživatel si může klidně pamatovat heslo 2fr2xgf*pc+pcB2t - a na zabezpečení e-mailu běžného BFU je to dostatečně silné heslo.
Sice je to dostatečně silné heslo, ale pořád je to nedostatečná ochrana. Protože uživatel takovéhle heslo klidně napíše do podvodné stránky. Aby byla ochrana dostatečná, je nutné také vyhodnotit, zda je heslo zadáváno na správný web. A to udělá správce hesel, který podle adresy webu vyhledá správné heslo, ale neudělá to uživatel (resp. je velké riziko, že to uživatel udělá špatně).

Navíc takovýchhle hesel si uživatel těžko bude pamatovat desítky, pro každý web jiné.

Uživatel si může pamatovat jedno silné heslo (ke správci hesel), ale správce hesel zajistí, aby hesla byla unikátní a aby se heslo vložilo jen na tu správnou stránku. To jsou dvě nejdůležitější funkce správce hesel. To, že jsou hesla ve správci hesel silná, je ta méně důležitá věc.

Když odhalíte, jak jsem to heslo vygeneroval, seznáte, že si jich uživatel je schopen pamatovat dostatek. ;o)
Ale BFU takové heslo potřebuje v podstatě jen jedno, maximálně jen několik málo. Když pominu důležité služby typu bankovnictví či slevové apky obchodních řetězců, případně eGov klíč (ale ten mít nebude - má bankovní), v podstatě jen potřebuje přihlásit se na Seznam a přečíst si drby a e-maily.
To je to, co drtivá většina uživatelů dělá. A pak se ještě přihlašují na sociální sítě, ale to je tak nějak automatické, takže netuší, jaké heslo a kam se vlastně má zadat
To my ostatní potřebujeme password managery, protože se hlásíme do diskusí na rootu či lupě, na rozličná místa, nákupní servery, odborné weby, případně přímo na servery své či pracovní.

Ale BFU takové heslo potřebuje v podstatě jen jedno
Ano – ke správci hesel.

v podstatě jen potřebuje přihlásit se na Seznam a přečíst si drby a e-maily.
To je to, co drtivá většina uživatelů dělá. A pak se ještě přihlašují na sociální sítě, ale to je tak nějak automatické, takže netuší, jaké heslo a kam se vlastně má zadat
To, že se někdo neživí IT, neznamená, že žije v jeskyni. Přihlašuje se k e-mailu, k sociálním sítím, k e-shopům, k poskytovatelům služeb (internet, telefon, televize, elektřina, plyn, voda, správa domu), k odborným webům (ve svém oboru), k rozvozu jídla, k rozvozu potravin, do aplikace pro MHD, do aplikace pro vlak…

Jenže průměrný BFU správce hesel nepoužívá, používat neumí a hlavně nechce. Věřte mi - už jsem učinil hodně pokusů nainstalovat to uživatelům od důchodců, přes pracující dospěláky, po školáky. Úspěšně to používají jen ti poslední. Ostatní to dílem ignorují, dílem odinstalovali.
Ne, nežijí v jeskyni. jsou aktivní na sociálních sítích, nakupují ve slevách, jezdí MHD i vlakem, sledují videa na YuouTube, Netflixu a Prima+. Platí kartou, někdy kartou v mobilu.
Je jen velmi málo služeb, kam skutečně musí napsat nějaké přihlašovací údaje. A zcela určitě si nechtějí přístup k těm službám dalším zabezpečením nebo používáním nějaké tajemné aplikace na hesla. Dělají to nejméně bezpečné, co mohou: uloží si hesla v prohlížeči nebo napíší na papírek.
Pokud (dejme tomu, čistě teoreticky!) zavede Seznam 2FA pro přihlašování na své stránky, velká, ale menší část z nich se prostě přestane přihlašovat a bude se vztekat, že se nedostanou k e-mailu. A nechají si to nastavit tak, aby jim to chodilo do mobilu, protože tam se přihlašovat nemusí.
Správce hesel je dobré řešení - ale ne pro běžného Frantu uživatele. Ne, že by byl neinteligentní či hloupý - jen to nechce a půjde cestou, která se bez toho obejde.

> Dělají to nejméně bezpečné, co mohou: uloží si hesla v prohlížeči nebo napíší na papírek.

Jenže jak se někdo dostane k jejich počítači, nebo k papírům tak to vždycky je velký špatný. A hesla jsou jen část větších škod. Takže na ochranu před tímhle druhem útoku buď kašlou, nebo to mají nějak pořešené o úroveň výš.

Jenže průměrný BFU správce hesel nepoužívá, používat neumí a hlavně nechce.
Proto se zavádí WebAuthn.

A zcela určitě si nechtějí přístup k těm službám dalším zabezpečením nebo používáním nějaké tajemné aplikace na hesla.
Problém bude v tom, že „IT odborníci“ často používají šílené aplikace, mají na ně požadavky jako že v žádném případě nesmí hesla synchronizovat přes cloud apod. A pak zkouší tyhle aplikace nutit ostatním. Rozumný správce hesel jako Bittwarden není žádná „tajemná aplikace na hesla“.

Dělají to nejméně bezpečné, co mohou: uloží si hesla v prohlížeči
Ono to není tak nebezpečné, největší problém je asi v tom, že se k těm heslům těžko dostává třeba v mobilu.

Jinak to, že jsou správce hesel v prohlížečích velmi odfláknuté, patří k největším problémům práce s hesly. A hezky to ilustruje, jak autoři prohlížečů pořád mluví o bezpečnosti, ale reálně kašlou na věci, které by znamenaly velký posun vpřed ohledně bezpečnosti. Navíc to prohlížeče ještě komplikují tím, že neumožňují pluginům napojit se na infrastrukturu prohlížeče pro práci s hesly na stránce – takže pluginy se musí do stránek pracně vlámávat.

Třeba do některých prohlížečů se generování bezpečných hesel přidalo letos nebo loni. Takovou funkci má mít správce hesel od začátku. Atd.

nebo napíší na papírek
To je paradoxně velmi bezpečný způsob uložení hesla – pokud ten papírek máte doma, kde se pohybují lidé, kterým důvěřujete. Problém je, že takové heslo pak musíte přepsat ručně – takže nejste chráněn proti phishingu. Navíc asi budete takové heslo používat na více místech. Kvůli ručnímu přepisování taky budete mít tendenci nedělat to heslo zbytečně dlouhé.

Ne, že by byl neinteligentní či hloupý - jen to nechce a půjde cestou, která se bez toho obejde.
Nechce to, protože IT lidé kolem něj mu to nedokážou dobře nastavit. Na používání správce hesel fakt není nic složitého – pro mne přihlášení s 2FA znamená stisknout Ctrl+Shift+L na přihlašovací stránce, Enter pro odeslání, Ctrl+V pro vložení druhého faktoru a znovu Enter. Zbrzdit to může akorát situace, kdy UX řešil nějaký osoba s deficitem inteligence a políčko pro druhý faktor nemá automaticky focus (což je mor, který je z nepochopitelného důvodu na mnoha stránkách – když je na celé webové stránce jediný input, který musí uživatel vyplnit, aby se dostal dál, je asi strašně těžké určit, co má mít focus…).

Proto se zavádí WebAuthn.
Což je přesně věc, kterou ti lidé nechtějí - vidí to spíš jako šmírování a odmítají to z principu. ;o(

Nechce to, protože IT lidé kolem něj mu to nedokážou dobře nastavit.
Můžete to klidně nastavit úplně správně a bezobslužně, ale těm uživatelům se to časem samo přenastaví (při aktualizaci, nevědomým zásahem...) a bez opětovné pomoci to nevyřeší - část z nich si ani o pomoc neřekne, aby nevypadali jako hlupáci. A je jen otázkou času, kdy k tomu u koho dojde.

Ti uživatelé některé funkce reálně ani nepotřebují (nevědí, že by je mohli potřebovat, nechtějí ...). Například synchronisaci mezi počítačem a telefonem: jsou místa, kam se hlásí pouze z mobilu (obchody, slevové apky, platební apka...), a místa, kam lezou pouze z počítače (stránky energetických firem, e-mail, bankovnictví) jednou za dlouhou dobu (kromě toho e-mailu), třebas po měsíci či po roce. Pak je lísteček s heslem prostě uživatelsky přívětivé řešení, zatímco password manager za tu dobu nemusí být aktuální či funkční.

> nevědí, že by je mohli potřebovat

Jakoukoliv featuru, o které ani netuším, nepotřebuju tak nějak implicitně. Ne? To není specifické jen pro hesla nebo IT obecně, ale platí to všude.

Jakoukoliv featuru, o které ani netuším, nepotřebuju tak nějak implicitně. Ne? To není specifické jen pro hesla nebo IT obecně, ale platí to všude.
Ne, neplatí to obecně nikde. Čím komplexnější systém, tím častější je, že něco potřebujete, ale nevíte o tom. Představte si třeba dnešní auta – je tam spousta věcí, o kterých vůbec nevíte, že tam jsou ani k čemu jsou, ale auto by se bez nich třeba ani nerozjelo.

Nutná součástka o které nevím je spíš implementační detail než featura. A navíc se tu bavíme o věcech, co uživatelé můžou nechtít. Ne o věcech, co ten mobil dělá skrytě v pozadí.

Bezpečnostní pásy v autech nebo ABS jsou podle mne featury a ne implementační detail. Přesto lidé v době jejich zavedení nevěděli, že to mají chtít. Ostatně Henry Ford údajně prohlásil, že když se zeptáte lidí, co chtějí, řeknou vám, že rychlejší koně.

Což je přesně věc, kterou ti lidé nechtějí - vidí to spíš jako šmírování a odmítají to z principu. ;o(
Ne, nechtějí to „IT odborníci“. Běžní uživatelé akorát chtějí, aby bylo snadné to zprovoznit.

Můžete to klidně nastavit úplně správně a bezobslužně, ale těm uživatelům se to časem samo přenastaví (při aktualizaci, nevědomým zásahem...) a bez opětovné pomoci to nevyřeší - část z nich si ani o pomoc neřekne, aby nevypadali jako hlupáci.
Ne, to se opravdu neděje, rozhodně ne nijak často. A pokud by se to stalo, tak si o pomoc samozřejmě budou muset říct – protože bez funkčního správce hesel se nikam nedostanou.

Ti uživatelé některé funkce reálně ani nepotřebují (nevědí, že by je mohli potřebovat, nechtějí ...).
Od toho mají být právě IT odborníci, aby jim vysvětlili, že to potřebují.

Například synchronisaci mezi počítačem a telefonem
To je naprostá nutnost, protože to funguje jako záložní instance správce hesel, když se s jedním zařízením něco stane. V jiném vlákně se tu o tom diskutuje.

Pak je lísteček s heslem prostě uživatelsky přívětivé řešení,
Ale není to bezpečné řešení – kvůli phishingu a kvůli tomu, že to vede k opakujícím se heslům.

password manager za tu dobu nemusí být aktuální či funkční.
To je nesmysl. Běžný uživatel se heslem někam přihlašuje minimálně několikrát měsíčně. Takže password manager bude mít funkční. Nejjednodušší je používat password manager úplně na všechno – a pak nehrozí, že bude heslo neaktuální nebo že bude uživatel řešit, jestli je tohle heslo na papírku nebo v password manageru.

Pořád dokola uvádíte příklady, kdy je použití password manageru nepohodlné nebo dokonce nebezpečné – protože se používá špatně. Když uživatele naučíte používat ho správně, bude to pro něj obvykle jednodušší, než jeho současné řešení. Jenom je potřeba vybrat dobrý správce hesel, nainstalovat ho na minimálně dvě zařízení a zařídit automatickou synchronizaci mezi nimi. A pak do něj převést hesla a vypnout ukládání hesel v prohlížeči. To je vše, tím skončila ta komplikovaná část a pak už to uživatel může jenom používat.

Pak uživateli můžete prozradit, že si tam může uložit třeba PIN ke kartě a nemusí ho mít nebezpečně na lístečku v peněžence. Že si tam může uložit rodné číslo, číslo občanky, pasu – a nejen svoje, ale i svých blízkých. Že si tam může uložit fotku občanky, průkazu pojištěnce – opět včetně třeba dětí. Najednou mu to usnadní spoustu situací. A bude se vás ptát, proč jste mu to neporadil dřív.

> A pokud by se to stalo, tak si o pomoc samozřejmě budou muset říct – protože bez funkčního správce hesel se nikam nedostanou.

Nebo si ta hesla nějak horko těžko zachrání sami a o nějakém správci už nebudou chtít v životě slyšet.

je potřeba vybrat dobrý správce hesel, nainstalovat ho na minimálně dvě zařízení a zařídit automatickou synchronizaci mezi nimi
Drtivá většina těch, se kterými přijdu do styku, to na dvou zařízeních nechce - potřebují to jen na počítači, protože z mobilu se nikam nepřihlašují (na to je to příliš malé zařízení). Jestli něco na mobilu řeší v prohlížeči, tak jsou to drby na nějakém bulváru - a tam se nepřihlašují.

Většina z nich nechápe (nechce chápat), proč by si tam měli ukládat rodná čísla (svoje mají na OP, příbuzných nepotřebují nebo je mají jako poznámku u kontaktu v telefonu), čísla průkazů neukládají vůbec, fotka občanky je v mobilu v Galerii a PIN ke kartě se nesmí psát vůbec nikam, ten si musí pamatovat (říkala to ta paní z banky!).
Máte pravdu v tom, že uvádím příklady, kdy to je nepohodlné, nepraktické, nebezpečné - ale jsou to přesně případy, se kterými se velmi, velmi často setkávám. A argumentovat tím, k čemu všemu se to dá ještě použít - oni tu potřebu prostě necítí a přijde jim to takové samoúčelné.
Ano, používají ho špatně, ale zároveň to nechtějí umět používat správně.
Někdo (já...) jim nutí něco, co nepotřebují a nechtějí potřebovat. Potřebují aplikaci typu fire and forget, o kterou se nebudou muset vůbec starat, která se nebude připomínat, otravovat s aktualizací, bezpečnostními upozorněními, bude fungovat na 110 % - a o které budou zároveň vědět, že tam je a funguje.
Žádné kopírování hesel, žádné kombinace kláves, žádné další potvrzování, žádné neustálé psaní hesla k heslům.

> Většina z nich nechápe (nechce chápat), proč by si tam měli ukládat rodná čísla (svoje mají na OP, příbuzných nepotřebují nebo je mají jako poznámku u kontaktu v telefonu), čísla průkazů neukládají vůbec, fotka občanky je v mobilu v Galerii a PIN ke kartě se nesmí psát vůbec nikam, ten si musí pamatovat

Jasně, že nechápou. Svoje RČ si pamatuju, ostatní nepotřebuju (resp. potřebuju tak málo, že se můžu klidně podívat doma nebo zeptat). Čísla ostatních průkazů mám na těch průkazech a obvykle k nim potřebuju i ten průkaz. Jak často někam posíláte fotku občanky, že vám vadí si ji vyfotit podle potřeby?

A ten pin přece zadáváte na klávesnici, kam vám ho ten správce stejně nevyplní. A zadáváte ho tak často, že se vryje do paměti. Trochu platíte kartou a znáte svůj pin líp, než datum narození. :)

Svoje RČ si pamatuju, ostatní nepotřebuju (resp. potřebuju tak málo, že se můžu klidně podívat doma nebo zeptat).
Zkuste někdy jít s dítětem k lékaři. A až se vás budou ptát na jeho rodné číslo, uvidíte, zda je uspokojí odpověď, že se doma zeptáte.

Čísla ostatních průkazů mám na těch průkazech a obvykle k nim potřebuju i ten průkaz.
Tak v polovině případů mi stačí to číslo. A průkaz musím někde hledat, mobil mám při ruce pořád.

Jak často někam posíláte fotku občanky, že vám vadí si ji vyfotit podle potřeby?
Nejde o to, že bych ji někam posílal. Jde o to, že ji můžu ukázat, když někdo potřebuje údaje z ní – a já ji třeba u sebe ani nemám.

A ten pin přece zadáváte na klávesnici, kam vám ho ten správce stejně nevyplní.
Ale aspoň si ho ten správce pamatuje a nemusím to mít napsané na lístečku v peněžence.

A zadáváte ho tak často, že se vryje do paměti.
Asi jste nikdy neměl víc karet, třeba i firemní. Navíc už pár let platím bezkontaktně a mobilem, takže PIN karty jsem už nezadával několik let. A je výborné, když třeba pospícháte před odjezdem na dovolenou a potřebujete vybrat z bankomatu – a přijdete k bankomatu a v hlavě máte prázdno. Nebo stojíte u pokladny, za vámi fronta a v hlavě okno. Já v klidu vytáhnu telefon a na pár kliknutí najdu PIN.

Zrovna s dítětem u lékaře jsem neměl problém, dokonce ani v případě, že jsme neměli kartičku pojištěnce a to číslo neznali - umí si to dohledat sami podle data narození. (Jen je potřeba předvést etudu na téma blbec tatínek na to ani nepomyslel, když vyrážel na tu pohotovost - a maminka to nepřipomněla. To funguje spolehlivě. Aspoň k něčemu ty kursy sociálního inženýrství jsou. ;oD )

Vzhledem k tomu, že tahle diskuse je o skupině uživatelů, kteří jsou rádi za jednu kartu, a spíš zapomenou doma ten mobil, než občanku, tak mi to zadávání do nějaké aplikace přijde pro ně opravdu poněkud nadbytečná featura - to je zřejmě neohromí natolik, aby to začali používat.
Navíc - když někam zadávají hesla, tak na počítači. Na mobilu to bývá vyřešené jinak. Což je přesně ten důvod, proč takovou aplikaci na mobilu nechtějí potřebovat.

RRŠ: Takže jste měl problém, ale s určitým úsilím z vaší strany a hlavně ze strany zdravotní sestry jste to vyřešil. Není lepší umět to vyřešit rychle a sám?

Vzhledem k tomu, že tahle diskuse je o skupině uživatelů, kteří jsou rádi za jednu kartu, a spíš zapomenou doma ten mobil, než občanku
Ne, bavíme se o běžných uživatelích. Někteří z nich možná spíš zapomenou mobil než kartu, ale někteří z nich u sebe naopak běžně nosí dva mobily, nebo mobil a tablet. Zkrátka ta množina je hodně velká a to, že se někdo neživí IT, neznamená, že neumí IT používat.

to je zřejmě neohromí natolik, aby to začali používat.
Taky jsem to zmiňoval jako bonus navíc, který získají, když to začnou používat z jiných důvodů.

Navíc - když někam zadávají hesla, tak na počítači. Na mobilu to bývá vyřešené jinak.
Spousta aplikací na mobilu po vás to heslo chce alespoň poprvé. Ty obzvláště bezpečnostně citlivé – jako třeba slevová kartička do drogerie – po vás to heslo chtějí jednou za čas znovu, protože proč placení u pokladny neprodloužit, že, hlavně když je za vámi fronta.

Ti, kteří nosí mobil a tablet, mne obvykle neotravují, abych jim něco nastavil. Obecný poznatek: kdo používá tablet, obvykle si ví rady sám.

Dvoumobilové uživatele potkávám v drtivé většině v kombinaci mobil soukromý + mobil služební; na tom druhém si nic nenastaví a jakákoliv synchronisace se soukromým strojem bývá krajně nežádoucí. Jen jeden pán má mobily tři a všechny soukromé, ale zase jsou dva z nich tlačítkové dumbphony - a on se ve svých 79 letech nehodlá zabývat nějakým password managerem, když na noťasu leze jen jednou za měsíc do bankovnictví a jinak se nikam nepřihlašuje (krom jednou - dvakrát do roka na Seznam potvrdit podmínky, kvůli čemuž mi zatelefonuje a předá mi slavnostně papírek s heslem).

Uznávám, že je to dané výběrovým kritériem, ale pokud do kategorie BFU někoho řadím, tak tyhle uživatele. Ostatní jsou IT gramotní.

23. 11. 2023, 16:58 editováno autorem komentáře

> Taky jsem to zmiňoval jako bonus navíc, který získají, když to začnou používat z jiných důvodů.

K napsání rodných ani jiných čísel do mobilu nepotřebuju správce hesel. Dokonce k tomu není potřeba ani smartphone. Psát poznámky uměl jeden každý mobil, co mi prošel rukama.

Lidi jako jsem já ohromí spíš to, že něco takového vůbec vnímáte jako bonus. Protože to můžu mít kdykoliv se mi zachce, jen to nestojí za námahu.

> Zkuste někdy jít s dítětem k lékaři.

Kdykoli jsem to "zkoušel", tak chtěli kartičku pojišťovny. A nebo nás už znali, takže nechtěli nic. Samotné rodné číslo jsem u doktora v životě nepotřeboval.

> Tak v polovině případů mi stačí to číslo. A průkaz musím někde hledat

Po mně vždycky chtějí občanku/..., neptají se jen na číslo Možná bych to ukecal, ale je jednodušší vytáhnout z peněženky kartičku než v mobilu lovit číslo. I v dnešní bezkontaktní době se peněženka s trochou hotovosti pořád hodí.

> Asi jste nikdy neměl víc karet

Mám víc karet. A větší problém je že automaticky zadám pin ke špatné kartě, než že bych si ho nepamatoval.
Mobilem teda neplatím, ale při bezkontaktním placení po mně chcou pin pravidelně. Od 500 nahoru vždycky.

> pro mne přihlášení s 2FA znamená stisknout Ctrl+Shift+L na přihlašovací stránce, Enter pro odeslání, Ctrl+V pro vložení druhého faktoru a znovu Enter

Pokud necháte 2FA na jedné appce na jednom zařízení, tak z toho máte efektivně zase jednofaktor. Akorát s bonusovým kargokultem.

Tak tohle naučte uživatele, který to potřebuje jednou za měsíc nebo méně často. ;oD Koledujete si o pravidelný telefonát, co má dělat, protože nerozumí zápisu, který si udělal na papírek posledně.

A ještě přidejte požadavek, aby si přikoupil ještě jedno redundantní zařízení. Tam zase riskujete, že si ho koupí jen aby vám ho mohl narvat do ... ;)

Potkal jsem uživatele, který léta používal osmiznakové heslo, navíc ne úplně komplexní (malá písmena+číslice+pár nealfanumerických znaků) - měl je napsané na notebooku lihovkou.
Jednoho dne byl donucen heslo změnit, jinak prý přijde o přístup k e-mailům... Problém nastal s tím, že bylo natolik zažrané do toho notebooku, že nešlo odstranit ani poměrně agresivními rozpouštědly, aby je mohl přepsat na nové.
Naprosto vážně se mne ptal, zda kvůli tomu bude muset koupit nový notebook...


(Nedal na dobré rady, ale našel takové heslo, kdy to původní natáhl na 14 znaků, několik písmen přepsal na velká, a dopsal to k tomu původnímu.)

Pokud necháte 2FA na jedné appce na jednom zařízení, tak z toho máte efektivně zase jednofaktor. Akorát s bonusovým kargokultem.
Nikoli. Vícefaktorová autentizace nezávisí na počtu zařízení, ale na počtu různých faktorů. Už jsem to tady v diskusi vysvětloval, proč má 2FA smysl i když je vše uložené v jednom správci hesel.

Jenže reálně pak často hrozí degradace tofo dalšího faktoru, protože dalším faktorem bývá vestavěná biometrie, která selže zhruba dvakrát, než ji uživatelé vypnou.
Není nad to, když potřebujete zaplatit v lékárně za mast na nateklé oko, a platební aplikace nepozná obličej a odmítá načíst otisk prstu... (To není výmysl: takhle se kolega vracel minulou zimu z hospody a narazil na namrzlé schody. Od té doby zase nosí kromě mobilu i normální platební kartu.)

RRŠ: Možná by pro kolegu bylo jednodušší, kdyby si zapamatoval PIN k mobilu.

Žádný tam nemá! ;oD
To ověření požadovala přímo aplikace - zřejmě s variantou pořád odemčený mobil počítají.

Jestli je nějaké oficiální pravidlo-omezení nevím, ale mám tam asi 10 různých emailů ( = seznam účtů) jak klasické, tak emailprofi uvnitř kterého je dalších asi 20+ emailů a není problém, že mám všude stejné tel. číslo.

O té nutnosti přihlášení nevím při používání IMAPu nevím, znám minimálně dva lidi, co to takhle používali/používají přes klienta roky (senioři, starý Outlook) a neřekl bych, že je to nutilo k přihlášení přes web.
Máte nějaký odkaz na stránku, kde třeba specifikují tu dobu, než to zruší, jak zmiňujete.

Jinak pořád nevím, co je s tím teď za problém. TOTP je jen další možnost ověření s 2FA, kterou můžete a nemusíte využít. V porovnání s tím, jak fungovalo cca 5 let nazpátek, když zavedli 2FA, se v základu nic nemění. SMS, co vím, nikdy nebyla využívána pro běžné přihlašování, pouze pro obnovu hesla a následné změny nastavení účtu.
Jen pro 2FA už nemusíte nutně používat jejich mobilní aplikaci nebo jejich prohlížeč. Mě přijde dobré, že si uživatel může vybrat i nějakou offline (KeePass), webovou variantu, mobilní variantu (Authy, Google Authenticator, Oracle Authenticator) a navíc jich může být víc naráz.

To s tím stejným telefonem, netuším, asi jsem nikdy neřešil tolik účtů na jeden telefon nebo nějakou specifickou kombinaci starých účtů z jiných služeb, aby se mi tohle projevilo.
https://napoveda.seznam.cz/forum/threads/140188/1

Odkaz nemám, ale třebas e-mail s Neradi otravujeme, ale musíte odsouhlasit podmínky přišel letos asi dvakrát.
Větička o tom, že telefonní číslo je teď povinné, se zobrazuje po každém přihlášení, nemáte-li je (historicky) vyplněné; lze odkliknout Připomenout příště.

Pevně doufám, že to zůstane, tak, aby 2FA nebyla využívána pro běžné přihlašování, pouze pro obnovu hesla a následné změny nastavení účtu. ;o)

"O té nutnosti přihlášení nevím"

Cas od casu prisel do mailu spam, kterym porusovali svoje vlastni pravidla, a vyhrozovali, ze mi ten mail, zrizeny dle uzavrene smlouvy na dozivoti (moc dobre si to pamatuju) zrusi. Pokud se .. do XYZ neprihlasim na web a neodsouhlasim nejake nove podminky.

Naprosto sklidem bych dal vyuzival tech 10MB mailboxu. Stejne to obratem stahne a smazne muj srv.