Názory k článku Jak funguje ověřování identifikačních údajů podle Zákona o právu na digitální služby

Chapu.... i nadale budeme udrzovat pri zivote postupy z dob cisare pana... a tim budeme obhajovat nutnost existence identifikatoru. Tohle muze vymyslet leda nekdo, kdo je na statni sprave a soucasne forme jeji pseudodigitalizace nejak prisaty :-)

Nechápete. Neexistence jednotného identifikátoru konzervuje ty postupy z dob císaře pána. Aby mohla veřejná správa projít digitální transformací, potřebuje mít mimo jiné k dispozici údaje z různých systémů online. K tomu potřebujete jednoznačnou identifikaci osob a potřebujete umět údaje k osobě získat rychle (skutečně online). Mám takový pocit, že o tom, jak má vypadat digitální transformace veřejné správy nevíte vůbec nic.

Vas pristup neni jediny spravny :-) A CUZK je prakticky priklad, ze to jde...

Danny: Kdybyste věděl, jak to udělat lépe, tak už byste to dávno napsal – místo neustálého teoretizování.

A proc bych mel vynalezat kolo? Na CUZK to funguje bez jednotneho identifikatoru a mate to tu popsane, navzdory vasemu mudrovani.

Danny: škoda, že jste nepochopil, o čem je řeč. Jednotný identifikátor by samozřejmě nijak nepomohl jednomu IS. Pomohl by komunikaci mezi více IS různých správců, zejména mezi IS v komerční sféře nebo mezi IS státní sféry a komerční sféry.

A stale dokola - vzdyt tu mate popsane v praxi fungujici reseni, ktere se bez toho jednotneho identifikatoru obejde. Ale vam proste nevoni. To je cele.

Danny: Ano, stále dokola – stále jste totiž nepochopil, že reálný život je složitější a nestačí pro něj jediné řešení. A také to, že v roce 2022 jsou jiné požadavky na v praxi fungující řešení, než jaké byly za císaře pána. Ono to v praxi fungovalo bez jakýchkoli počítačů – akorát že dnes byste rád některé věci třeba vyřídil z domova, nebo byste třeba některé věci nechtěl vyřizovat vůbec a mohly by si je za vás vyřídit přímo dotčené instituce.

No, ale na CUZK to bez identifikátoru taky nefunguje. Jednak tam mají hromadu nemovitostí, u kterých neumí určit majitele - ukazuje se, že dřívější zápis jen se jménem a adresou je naprosto nedostačující. Proto dnes zveřejňuje tyto nemovitosti s nedostatečně identifikovaným vlastníkem ÚZSVM a oprávnění majitelé se hledají. A pak, při zápisu čehokoliv do katastru musíte prostě své rodné číslo uvést do návrhu na vklad či zápis. Bez něj Vám to vrátí, resp. nepřijmou.

Za prvé: nepamatuji si rodné číslo. ;oD
Ale ten začátek si umím odvodit a ty čtyři poslední číslice najdu na občance. A při svých schopnostech starého diskalkulika se obávám, že opsání delší řady číslic by se bez chyby neobešlo (jak se přesvědčuji skoro vždy, když platím složenky), takže prostě odevzdám občanku, ať si chybu při opisování udělá někdo jinej.
Znám málo lidí, kteří by si pamatovali číslo své občanky - a oba se zlobí, že po přestěhování se musí učit nové.

8. 7. 2022, 19:08 editováno autorem komentáře

Podstatný rozdíl je ovšem jenom v tom, že rodné číslo se používá relativně často, takže se vyplatí si ho pamatovat, zatímco číslo dokladu se nepoužívalo prakticky vůbec, takže nebyl důvod si ho pamatovat. Navíc se číslo dokladu pořád mění. Jinak jsou samozřejmě lidé, kteří si nezapamatují ani rodné číslo, a naopak lidé, kteří si pamatují i licenční klíče Windows XP.

Nize mate komentar Kamila Zmeskala, ktery to vase "nejde to" dost pekne vyvraci. A CUZK je co se digitalnich agend tyce vcelku dobre fungujici urad, to neni zadna teorie - jak tam v naslednem komentari tvrdite.

Pod komentářem Kamila Zmeškala je moje reakce vysvětlující, proč tohle sice funguje pro stát, ale nefunguje to vůči občanům.

Nikoliv. Podle te Vasi "teorie" by treba Novy Zeland nemohl vubec fungovat. Tam je vytvareni takoveho identifikatoru primo zakazane. Stejne jako treba v Portugalsku, kde to maji i v ustave.

Já jsem ale nepsal, že to nemůže fungovat. Já jsem jenom vysvětloval, proč je to pro občany nepohodlné.

Dá se to samozřejmě zlepšit tím, že služba pro překlad AIFO bude mít garantovanou a bryskní dobu odpovědi. Dá se to zlepšit tím, že systémy, že který jiný systém potřebuje čerpat data, budou mít rychlé funkce vytvořené na míru jednotlivým aplikacím. A pak se dá také zamyslet nad těmi jednoznačnými identifikátory a přijít na to, že univerzální jednoznačný identifikátor hodně pomůže občanům, zatímco jeho zákaz prakticky nijak neomezí záškodníky, legitimní zpracování ale dost komplikuje.

Mimochodem, o tom, jak skvělé jsou ty tajné agendové identifikátory, svědčí i to, že agendové systémy mají pro osoby AIFO, nově k nim přibylo BSI, které je v něčem podobné a v něčem jiné, a pro reálné použití se teď doporučuje používat číslo osobního dokladu, které je zase globální, ale není trvalé. (Což je opět perfektní pro záškodníka, který si přes něj osoby spojí – a je mu jedno, že se za půl roku ID změní. Oprávněnému uživateli, který s tím musí pracovat dlouhodobě, to akorát přináší komplikaci.)

Nepohodlne je to predevsim pro vyvojare obdobnych systemu (takze pro vas, zejo). Nazyvejme veci pravym jmenem ;-) Takze vas hejt je pochopitelny.
Zminovane propojeni pres auditovane referencni rozhrani s kontrolou opravnenosti pristupu az na uroven jednotlivych atributu je jediny spravny pristup.

Bohužel vůbec netušíte, o čem je řeč. Zadávat se samozřejmě něco musí. Uváděl jste jako příklad katastr, tak se podívejte třeba na převod nemovitosti. Ten nemůže zahájit úřad jen tak sám od sebe, že se jednoho dne rozhodne vaši nemovitost převést někomu jinému. Ten podnět musí vyjít od vás, jako současného vlastníka nemovitosti, případně od budoucího vlastníka nemovitosti. Když to budete dělat vy, digitálně, někam se přihlásíte – tím je známá vaše identita. Pak potřebujete vědět, které se to týká nemovitosti – to si katastr dokáže ve svém IS dohledat. A pak je potřeba zadat, komu tu nemovitost převádíte. Dnes se to dělá tak, že zadáte jméno, příjmení, adresu trvalého pobytu a datum narození, a doufáte, že to bude jednoznačná identifikace. Navíc je to docela dost údajů, můžete v tom udělat překlep, většina lidí ani neví, jak správně vypadá adresa jejich bydliště. Můžete místo toho zadat číslo dokladu, jenže až se kupující do nové nemovitosti přestěhuje, změní si adresu trvalého pobytu, tím se mu změní i občanka a ten identifikátor přestane být platný. Opravdu chcete mít smlouvu o prodeji nemovitosti vázanou na něco, co za pár měsíců přestane platit? Když se tomu člověku změní občanka jen jednou, ještě ho podle ní dohledáte. Ale pak se třeba vdá, změní si jméno a tím znovu i občanku a podle toho původního čísla už ho nedohledáte. Opravdu chcete mít v ruce 2 roky starou smlouvu na prodej nemovitosti, kde je kupující identifikován způsobem, u kterého nejste schopen ověřit, kdo to je?

Jak jsem psal výše, těch strojových dotazů je několik a volají se jeden po druhém, protože další závisí na výstupu předchozího. Pokud jde o stručné údaje, které uživatel zadá rychle, je pro uživatele rychlejší, když je rovnou zadá ručně, než když se bude 5 vteřin čekat, jestli se náhodou nepodaří rychle získat data, a pak to stejně přepnout do režimu, kdy to uživatel musí zadat ručně.

Ja dobre chapu, ze budete krecovite obhajovat soucasne reseni, ktere vas chlebodarce statni sprave dodava. Kdybyste to musel od zakladu predelavat, nemel byste tolik casu na vykecavani se na internetu ;-)

To, že žádné lepší řešení nemáte, už víme, nemusíte to pořád dokola opakovat.

Reseni tu popsane bylo. Ale vam nevyhovuje. Jeho implementace je pro vas pracnejsi a to by pak bylo mene casu na zvaneni po internetech, ze? :-)

Dobře, já to zde popsané řešení neumím najít, tak pro vás jistě nebude problém popsat, jak by takové řešení mělo vypadat. Pořád se oháníte ČÚZK, tak dejme tomu, že ČÚZK dostane zákonem novou povinnost všem studentům do 26 let poskytovat 50 % slevu na veškeré zpoplatněné úkony. Takže student se přes NIA přihlásí do portálu ČÚZK, tam si něco vybere a bude to chtít zaplatit – moderně, takže hned a tedy platební kartou. Takže je potřeba před vyčíslením částky zjistit, zda je student. Za císaře pána byste se dotyčného zeptal, zda je student, a pokud ano, poslal byste ho s papírem na školu, ať přinese potvrzení. To není úplně vhodné řešení do digitálního světa. Tak popište, jak by to mělo podle vás fungovat. Můžete to zkusit dvěma variantami – ideální, jak by to podle vás mělo vypadat. A pak variantu se současnými reáliemi, tj. např. neexistuje žádný registr žáků a studentů.

No tak ja vam dam odkaz na konkretni prispevek v diskuzi, kdyz mate potize i se zrakem :-)

Pokud CUZK takovou povinnost formalne dostane, tak pres v tom prispevku popsane rozhrani si ty informace pochopitelne overit bude moct (konkretne asi dotazem do SIMS zprostredkovany referencnim rozhranim) - a samozrejme bude auditovane kazdy pristup k temto udajum. Samozrejme pusobnost SIMS bude nutne legislativne rozsirit minimalne i na zaky strednich skol, dnes tam jsou vedeni jen vysokoskolaci. A pro potreby CUZK v danem prikladu bude stacit podpoved, zda dotycny je/neni student, naopak k nicemu nepotrebuje informaci napr. o tom, jakou skolu a jaky studijni program studuje (ktera je v SIMS take zanesena)...

Jenže ono se to postupně hromadí. Jeden dotaz na převod BSI na AIFO, druhý dotaz do ISEO (který stojí trochu bokem, kdyby to byl standardní nový AIS, musíte ještě před tím vytvořit úložku a cílový AIS by si ji musel vyzvednout – to už máte celkem 4 volání).

„Zneužít RČ“ je nonsens. Bavíme se o identifikátorech, což jsou z principu veřejné údaje. Místo RČ se může použít jméno, datum narození a adresa trvalého pobytu. Když to někdo „zneužije“, mám se přestěhovat? Ne, stačilo by identifikátor používat jako identifikátor a netvářit se, že je to tak trochu i zabezpečení.

Správným směrem se to posunulo až v okamžiku, kdy se vám podařilo prosadit používání čísla dokladu jako identifikátoru pro soukromou sféru. Teď už zbývá dotáhnout jenom ten poslední krok – zjistit, že číslo dokladu se mění, což je pro jednoznačný identifikátor podstatná komplikace, a vytvořit nový bezvýznamový identifikátor, který se na rozdíl od čísla dokladu nebude měnit.

Ctyri volani, strasna tragedie. Podle vasi teorie "je to strasny problem" by se musela spousta sluzeb provozovanych v soukromem sektoru davno zhroutit (v podstate jakykoliv vice navstevovany eshop). Ale nehrouti se... cimpak to asi bude? ;-)

Danny: netvařte se, že jste tak hloupý a nechápete rozdíl mezi různými voláními, která probíhají během několika minut když uživatel prochází stránky e-shopu, a postupným voláním čtyř služeb v rámci interakce s UI, kdy první službu zavoláte na základě interakce uživatele (třeba kliknutí na tlačítko) a výsledek té čtvrté služby v pořadí potřebujete uživateli na téže stránce nabídnout.

Jen pro vaši informaci, e-shop typicky volá svoje vlastní služby, u kterých si může nastavit parametry podle potřeby. Služby základních registrů mají v nejvyšší kategorii garantovánu odpověď do 2 sekund v 90 % případů volání. Třeba ty služby převodu AIFO patří do nejnižší kategorie.

A copak asi dela treba takovy mimozemstan na pozadi, kdyz vam pri nakupu podbizi dalsi zbozi ci sluzby kontextove spadajici ke kupovanemu artiklu, hmm? :-) Principielne je to obdobna vec, na zaklade interakce uzivatele se neco vraci...

Parametry SZR zrovnatak nejsou staticka vec a podle definovanych potreb se muzou v case upravovat - a sluzby dnes vedene v nejnizsi kategorii se muzou napr. posunout do kategorie vyssi. Samozrejme je to spojene mj. s financemi, ona i ta rychlejsi odpoved neco stoji. Takze je to cele o tom, jak se nastavi priority...

Jasně, Alza se kvůli zobrazení doporučeného zboží dotazuje základních registrů… Navíc teda nabídka dalšího zboží či služeb k výrobku může být předpočítaná dopředu a může to být jen vrácení statického obsahu. A do třetice, nabídka dalšího zboží či služeb je v hierarchii důležitosti prvků na stránce dost nízko, protože když se to načte později nebo vůbec, uživateli to nijak nenaruší jeho práci.

Principiálně aspoň trochu podobná věc je třeba výběr místa uložení zásilky v košíku (když volíte Zásilkovnu, Uloženku, Balík na Poštu apod.). Tam volá e-shop externí službu (jenom jednu). Nevím,jak vy, ale já jako uživatel jsem vyloženě nadšený z toho, když chci zásilku uložit tam, jako vždycky, ale musím čekat, než se načte celá mapa ČR se všemi místy, pak můžu zadat PSČ a pak si konečně můžu vybrat pobočku. Kterou vím už od začátku. To je zrovna ten případ, kdy je ruční zadání rychlejší než volání služby a následný výběr. (A i kdyby to fyzicky rychlejší nebylo, z pohledu uživatele je to rychlejší rozhodně. Pocitově je výrazně rychlejší něco vyplňovat, než čekat, abyste mohl něco vyplnit možná rychleji.)

Technicky vzato je jedno, ceho se dotazujete. Je legitimni vest debatu o tom, jak moc je ZR optimalizovany na vyssi zatez, ale princip fungovani jako takovy spatny neni - neb jsou tam vyresene i veci jako auditovany a standardizovany pristup k informacim pri sdileni informaci napric ruznymi registry, kdy se kontroluje i opravnenost vyzadani dane informace... drobnost, kterou stale boharovne prehlizite.

A samozrejme, aplikace mohou byt navrzeny suboptimalne - typicky jsou to prave vyvojari (ci analytici pred nimi), co si v nejakem bode ponekud usnadni svuj zivot (asi aby tim nezabili tolik casi a meli vice casu na naslednou prokrastinaci)... a vyslednym produktem je nejaky paskvil. Coz zrovna mapa nacitajici vsechny koncove body do jedne mapy naraz samozrejme svym zpusobem je - a napsat to lepe zadny problem neni, staci chtit. Jenze ted strilite do vlastnich (vyvojarskych) rad... ;-)

Technicky vzato ovšem není jedno, jestli se dotazujete jedné vlastní služby, nebo jestli se dotazujete sekvenčně tří cizích služeb. I kdybyste na ty cizí služby nastavil super SLA, to, že jsou to tři sekvenční volání, prostě neokecáte. Na auditování žádné ZR nepotřebuju, standardizovaný přístup také ne, oprávněnost vyžádání dané informace ZR neřeší.

Optimální řešení jste tu zatím nenavrhl, přičemž příležitostí jste měl dost. Takže zatím to vypadá, že rozdáváte knížecí rady „jde to i lépe“, aniž byste alespoň tušil, jak by to lépe mělo vypadat.

A vy ty tri sekvencni dotazy pokladate po 2400-baudove lince a cely system provozujete na 8080 CPU a data nacitate z dernych stitku, nebo v cemze presne ma byt ten vas pseudo-problem? Raceji si vsimnout, ze vykon co do rychlosti sitove komunikace, IOPS ulozist i procesorovy vykon za poslednich deset let vyrazne vzrostl... zatimco obyvatelstvo se zas tak rychle nemnozi. Cely vas argument s tremi sekvencnimi volanimi je nicotny a z pohledu koncoveho uzivatele (obcana) irelevantni.
Prihlaste se na Portal obcana, tam se natahuji na uvodni strance data z hned nekolika nezavislych agend. Funguje to. Hledate problem, tam kde neni.

Danny: Vaše schopnost argumentovat příkladem, který se v podstatných parametrech liší od problému, je obdivuhodná.

Zkuste se podívat vedle na Root na článek Našeptávač: šikovný rádce, který má na práci 50 milisekund. Na začátku článku se řeší, jak rychle musí našeptávač odpovídat, aby byl k něčemu užitečný. Můžete jít pánům do Seznamu vysvětlit, že řeší nesmysly, protože rychlost odpovědi GUI je z pohledu koncového uživatele irelevantní. A nebo něco jednoduššího – zkuste přestat psát o UX nesmysly, které odporují elementárním zásadám UX.

Srovnavat naseptavac ve vyhledavacim poli (ktery kdyz nebude fungovat, tak se nic nedej, pouze clovek ten dotaz musi dopsat cely) se standardni transakci na eGov portalech (kdy i par sekund pockat nicemu nevadi) je fakt zcestny. Priklad ze zivota - transakce na platebnich branach zrovnatak nejsou behem milisekund, a nikdo z toho zadnou aferu nedela.

Na druhou stranu - jak vidite, vyhledavace prohrabujici se obrovskymi baliky dat zvladnou behem jedne vteriny (!) klidne dvacet transakci. Je to jen o tom, jak se system optimalizuje. Takze si vyrazte od programovani molochoidnich aplikaci pro statni aparat na staz do toho Seznamu - a naucte se od nich, jak to delat, aby to nebyl ten problem. Myslim ze frontpage Seznamu snasi podstatne vetsi uzivatelskou zatez nez ty systemy, co matlate vy.

přijede velké SUV k řece, řidič stáhne okénko a ptá se nedaleko stojícího Dannyho: „Tady někde by měl být brod. nevíte, kde přesně je?“ Danny odpoví: „Přímo tady jak stojíte, normálně přejedete řeku, úplně v pohodě.“ Řidiči se to nezdá, ale Dannyho ho přesvědčí, že je místní a zná to tu jako svoje boty. Řidič tedy vjede do řeky, auto se okamžitě potopí a zavře se nad ním voda. Danny kroutí hlavou, odchází a mumlá si: „Vůbec neumí řídit. Před chvilkou tam šla kačena s mladýma a vody měly sotva po břicho.“

Ale věřím vám, že opravdu upřímně nechápete, v čem spočívá rozdíl v interakci uživatele s našeptávačem a s platební branou. Že opravdu upřímně nechápete, v čem spočívá rozdíl v síťové latenci a v objemu zpracovávaných dat. Že opravdu upřímně nechápete, v čem je rozdíl mezi jedním systémem a komunikací mezi více systémy. Akorát je teda smůla, když chcete diskutovat o něčem, o čem nevíte vůbec nic.

No jeste ze vas tu mame, abyste publiku vysvetlil, jak strasny problem to je... :D

Zrovna napojeni platebnich bran na eshopy je prakticka ukazka komunikace mnoha systemu mezi sebou. To, co je podle vas strasne komplikovany problem bezne pouzivaji davy lidi kazdy den. A funguje to...

Zkuste ještě víc rozmyslet, jestli opravdu z hlediska uživatele není rozdíl mezi platební bránou a našeptávačem. Třeba si zkuste představit, že vám našeptávač neodpoví do 0,5 sekundy a že se vám do 0,5 sekundy nenačte platební brána. Jestli v tom pro vás jako pro uživatele nebude nějaký rozdíl, jak třeba budete dál tu službu používat nebo jestli budete nebo nebudete čekat.

Mimochodem, já jsem o žádném strašně komplikovaném problému nepsal. Psal jsem o komplikacích a psal jsem, jaké mají řešení – akorát vy jste ještě stále nepochopil, v čem ta komplikace spočívá. Protože jste stále ještě nepochopil, v čem se liší našeptávač od platební brány.

Jenze my se bavime o eGov portale, a to ze musi odpovidat bleskurychle jste sem zakomponoval vy. Ja nic takoveho nerekl. Byl jste to vy, kdo tu ze ctyr transakci v ramci komunikace eGov komponent udelal buhvijaky problem.

Já jsem to uváděl jako klasický příklad pro „proč musím vyplňovat údaje, které o mně stát už ví“. Protože když ty údaje nedokážete získat bleskurychle, aby si z nich mohl uživatel vybrat, je rychlejší, když to uživatel zadá sám. Přesně takhle funguje i ten našeptávač Seznamu – má smysl jedině tehdy, pokud bude zřetelně rychlejší, než když to uživatel sám napíše.

Pan z CUZK prakticky dolozil, ze to jde (provozuji to)
Nikoli. To jste jenom vy nepochopil, o čem je řeč.

Aplikace uvnitr mozna slozitejsi je, ale uzivatelsky navenek se to nikterak projevit nijak nemusi. Je to jen o sikovnosti programatoru...
Jasně, třeba taková latence sítě, to je jen věc šikovnosti programátora. Šikovný programátor dostane po síti odpověď dřív, než pošle dotaz.

lanek popisuje, jak i soukromy sektor ma moznost ziskat jednoznacny identifikator osoby. Aniz by u toho bylo naruseno soukromi v situaci, kdyby nejakemu soukromnikovi jeho databaze unikla
Chápu, že pro vás je k ničemu databáze, kde máte jméno a příjmení, datum narození, adresu trvalého pobytu a číslo dokladu. Že v ní nenajdete žádná osobní data natož abyste je uměl spojit s jinou databází, kde jsou tytéž údaje. To ale není tou databází, ale vámi – píšete o něčem, čemu vůbec nerozumíte.

umoznit jednoduchy merge posbiranych dat mezi Facebookem a Googlem proste nechcete
Ano, pro vás je takový merge neřešitelný problém. Pro nás nešikovné programátory je to jednoduché, prostě to spojíme přes e-mail, který bude v těch dvou databázích pro drtivou většinu osob stejný.

Mimochodem, všimněte si takového drobného rozdílu mezi námi. Vy tvrdíte, že něco nejde, a já vám na to konkrétně odpovím, jak to udělat. Já tvrdím, že něco nejde, vy na to nikdy neodpovíte, jak to konkrétně udělat, místo toho začnete blábolit o tom, že by to někdo určitě dokázal.

Prosimvas a kde ty aplikace provozujete? V ramci CR jsou latence site po optickych vlaknech v radu jednotek milisekund, v ramci datacentra se budeme bavit spise o max. stovkach mikrosekund. To je mozne celkem v klidu zanedbat.

U tech soukromych databazi je to o tom, co si ulozite - proc by si mel do databaze ukladat zrovna cislo dokladu? To je potreba jen pri overeni totoznosti, ale ukladat se nutne nemusi. Ano, spousta lidi tihne k tomu, ze shranuje udaje, ktere k nicemu realne nepotrebuje, tak trosku z alibismu. Presne to resi BSI - mate tenhle identifikator spolehlive identifikujici konkretni a prave jednu osobu pro pripad jakehokoliv problemu a do sve databaze vubec to cislo osobniho dokladu cpat rozhodne k nicemu nepotrebujete (ten pouzijete jen pri overovani vuci ROB, pak ho proste muzete zahodit). Svou argumentaci jen dokazujete, ze neumite zmenit zpusob mysleni - a nejradsi byste vsecko delal stejne jako pred dvaceti lety (kdy se stalo zvykem sbirat vsecko). Chybna je uz samotna uvaha, ze do svych lokalnich databazi musim sbirat vsecky udaje, co mi projdou rukama - i kdyz tam neni zadny racionalni argument pro jejich ulozeni...

Jaká je skutečná latence síťové služby ZR při dohledání AIFO (když jsou ZR v dobré kondici) uváděl výš Kamil Zmeškal.

Číslo dokladu ukládáte např. proto, abyste mohl osobu příště snadno dohledat. Také proto, abyste měl doklad, na základě čeho jste tu osobu vlastně hledal. A také proto, abyste měl identifikaci té osoby v případě, když v ROBu nebude dohledatelná, třeba kvůli duplicitě.

Údaje, se kterými systém pracuje, má uložené ve svých databázích kvůli bezpečnosti (je potřeba počítat s tím, že jiný systém může být nedostupný), kvůli rychlosti (nemůžete se ptát na každý údaj někam ven, zejména u dávkových operací), kvůli konzistenci (často potřebujete pracovat s entitami mimo ZR a nedává smysl mít osobní údaje cizince uložené ve vlastním systému a na občana ČR se pokaždé dotazovat) a kvůli historii (ZR poskytují akorát aktuálně platné údaje, ale systémy často potřebují znát údaje ke konkrétnímu okamžiku v minulosti).

Pro vaši informaci, ZR vůbec nejsou dimenzované na to, aby se jich někdo ptal pokaždé, když potřebuje nějaký údaj vedený v ZR. Představa, jak banka generuje měsíční výpisy z účtů a na každého klienta se přitom ptá do ZR je vskutku zábavná.

Skutecne latence ROBu nejsou vubec zadny problem. Tech par sekund nikoho nezabije.

A gratuluji, prave jste krasne popsal zbytecnost shromazdovani osobniho udaje. V momente, kdy je nekdo prokazatelne ztotoznen uz neni treba resit, na zaklade ceho to bylo. Pripominate hoteliery, co si z podobne lenosti kopiruji obcanky, i kdyz to delat vubec nemaji.

Jasně, uživatelé milují čekat pár sekund (v lepším případě) na vyplnění jména a příjmení do formuláře, protože sami by to v žádném případě nenapsali rychleji.

To, že nemusíte řešit, na základě čeho jste vyhledával osobu, vysvětlujte vnitru nebo ÚOOÚ, až se vás přijdou zeptat, proč jste tu osobu hledal.

Pokud resite spravnost vstupu, tak nebudete tupe spolehat na to, co vam do toho formulare nekdo rucne napise. Spechat se ma pomalu...

Aha. A co s tím vstupem teda budete dělat? Uživatel vám do formuláře napíše číslo občanky, a vy, ještě než se na ni zeptáte ZR, uděláte co, abyste se nespoléhal tupě na to, co vám uživatel napíše? Necháte uživatele to číslo napsat ještě podruhé? Nebo pro jistotu i potřetí?

Nabehli jste si sami, zrovna Facebook ci Google jsou realne ukazky databazi, ktere jsou co do objemu/poctu polozek rozsahlejsi nez databaze naseho pidistatu a bez spolecneho jednotneho identifikatoru se v klidu obejdou. Ono taky k cemu by jim byl, kdyz kazdy stat to ma jinak... pokud teda nejaky identifikator dany stat vubec ma.

Jistě, protože je tady velká poptávka po tom, aby si Facebook s Googlem o lidech vyměňovali data a jedna z nejčastějších výtek lidí vůči Google+Facebook je „proč tohle po mně chtějí vědět, když už tuhle informaci Google+Facebook má“.

A pak taky samozřejmě Facebook a Google potřebují spolehlivé propojení vaší elektronické identity s tou fyzickou, například protože ten nejdražší majetek, který máte, je evidován u Facebooku, když nebudete platit daně, tak vám Google napaří pokutu.

Až vás zase někdy napadne nějaký příklad, zkuste nad ním nejdřív přemýšlet. Jestli se třeba vůbec týká toho, co chcete ilustrovat.

Delate z toho akorat peknou bramboracku. Na jedne strane tu tvrditel, jak je par sekund na zpracovani transakce neprekousnutelny problem a pak tu zacnete zvatlat neco o (ne)spolehlivosti. Ano, pokud resim spolehlivost, tak se nebudu rozcilovat nad tim, ze do 50ms nemam odpoved dle vasi argumentace vyse. Vemte si stopky a zmerte si, jak dlouho trva platba kartou s overenim dle soucasne verze PSD2.
Pointa byla jina - databaze tech korporatu jsou vyrazne vetsi, jenom lidi se tam pocitaji v miliardach. Zatimco vy tu fnukate u usmudlanych deseti milionu, kdy navic cetnost uziti bude vyrazne mensi.... aneb kolikrat za den se hlasite k portalu obcana, hmm? :-)

Delate z toho akorat peknou bramboracku.
Já ne. To vy jste přišel s tím, že všichni požadují po Facebooku a Googlu, aby měly propojená data.

Na jedne strane tu tvrditel, jak je par sekund na zpracovani transakce neprekousnutelny problem
Netvrdím.

Ano, pokud resim spolehlivost, tak se nebudu rozcilovat nad tim, ze do 50ms nemam odpoved dle vasi argumentace vyse. Vemte si stopky a zmerte si, jak dlouho trva platba kartou s overenim dle soucasne verze PSD2.
No a může si státní správa dovolit být nespolehlivá? Že by vám tu a tam připsala body na řidičské konto za někoho jiného, občas byste musel FÚ zaplatit pokutu za někoho jiného, možná byste omylem vstoupil do manželství…

Zatimco vy tu fnukate u usmudlanych deseti milionu
Já? Já jsem tu někde psal o objemu dat? O objemu dat jste tu začal psát vy – protože evidentně netušíte, o čem je řeč, tak jste zkusil vyrukovat s objemem dat.

Jo, a kdepak teda pisu, ze vsichni pozaduji propojeni databaze Googlu a Facebooku. Vymyslite si. Nebo neumite cist ci chapat vyznam cesky psanych vet.

Statni sprava musi byt spolehliva a proto neni zadny problem, kdyz transakce par sekund trva. Ale soucasne nejde rezignovat na ochranu soukromi, tedy je zadouci implementovat mechanismy znesnadnujici prime a nekontrolovatelne propojovani databazi jednotlivych statem vedenych agend.

Jo, a kdepak teda pisu, ze vsichni pozaduji propojeni databaze Googlu a Facebooku.
Uváděl jste Facebook a Google jako jako protipříklad proti tvrzení, že spojení dat ze dvou IS je komplikovanější, když nemají společný identifikátor-

Statni sprava musi byt spolehliva a proto neni zadny problem, kdyz transakce par sekund trva.
Pro uživatele to problém je. Uživatelé očekávají, že bude aplikace státní správy fungovat minimálně stejně rychle, jako jiné aplikace (třeba e-shop nebo bankovnictví). Ne že se budou několik sekund načítat údaje, které za několik sekund sami napíšou.

, tedy je zadouci implementovat mechanismy znesnadnujici prime a nekontrolovatelne propojovani databazi jednotlivych statem vedenych agend.
Škoda, že to absence globálního jednoznačného identifikátoru osob nijak neřeší. Navíc jak jsem psal, stát to nějak vyřešené má přes překlad AIFO, daleko větší problém je to pro soukromý sektor.

Jinak to „nekontrolovatelné“ propojování jednotlivých agend je zabezpečené tak, že přístup k údajům musí být vždy uvedený v zákoně, musí se na tom obě instituce domluvit, musí se to na obou stranách implementovat – a pak to kontroluje ÚOOÚ. Představa, že se databáze dvou různých ministerstev propojí tak, že se domluví Franta s Pepou a začnou tahat nějaká data, je úplně mimo. Navíc – opakuji ještě jednou – by jim v tom žádná absence globálního jednoznačného identifikátoru osob nezabránila. Stejně veškerá taková komunikace počítá i s přenosem osob bez AIFO (resp. většinou se to dělá opačně, počítá se s přenosem bez AIFO, a jako bonus, když se zadaří, budete mít i vstup pro získání AIFO) – akorát je to komplikovanější a chybovější, protože když nevyhledáváte osobu podle jednoznačného identifikátoru ale podle jednotlivých údajů, hrozí větší riziko, že osobu nenajdete, nebo hůř že najdete někoho jiného.

Promiňte, ale státní správa je nespolehlivá, až běda. Vámi popsané situace jsem sice nezažil, ale případy, kdy úředník udělá drobnou chybu a občan s tím má trable, ty se mi nevyhýbají.

R. R. Šimek: Je rozdíl v tom, zda udělá drobnou chybu jeden úředník, nebo jestli bude systematicky chybovat systém, protože se třeba pro uložení dat použije databáze, která preferuje propustnost před trvanlivostí a občas nějaký záznam neuloží.

Vlastně mne, jako potrefeného občana nemusí zajímat, jestli chybu udělal úředník, nebo technika.
Každopádně: já preferuji, aby databáze (z pohledu technického) byly robustní a vnitřně jednoduché. Ta propustnost není - do jisté míry - tak kritická, jako spolehlivost. Leč obávám se, že záměrné rozhazování do různých "agend" a spojování přes důmyslně generované téměř-jednoúčelové bezvýznamové identifikátory se může stát nevysychajícím zdrojem chyb.

Netvrdím, že duplicity nastat nemohou (chybělo málo a byl bych jednou z nich, naštěstí druhá maminka měla Romana - bydleli i ve stejné ulici). Změna jména je méně častá a do matriky je zpětně zanesena (to vím určitě, tady jsem ten případ). Aby tam ta jednoznačnost skutečně byla, je na rodném listě - rodné číslo. (I to se může v čase změnit...)
Jenže ta identifikace je dostatečně dobrá a v zásadě všem vyhovuje.
On není běžně potřeba zcela dokonalý a neprůstřelný systém, když máte ošetřené výjimky jste schopen to řešit (a není jich moc).

Jen ještě doplním: na rodném listě jsou ještě napsaní rodiče, takže ta jednoznačnost je poměrně spolehlivá i bez rodného čísla.