9. října 2008

Vaše data? Místy oblačno.

Máme s kamarádem Jirkou takovou hru, jmenuje se tříbení názorů. Aniž bychom mohli (nebo snad chtěli) jeden druhého přesvědčovat o své pravdě, pouštíme se opakovaně do diskuse na určitá známá témata. Odměnou za zdánlvě promrhaný čas je nám většinou nějaký nový nápad, jenž společně vykřešeme.

Jedním takovým evergreenem našich debat jsou webové aplikace. Když jsem dopsal odpověď na Jirkův blogpost, napadlo mě, že jsem narazil na zajímavé vedlejší téma, takový malý nugetek, který volá po podrobném rozpracování, totiž: Jsem přesvědčen o tom, že nastupuje věk webových aplikací, jistě. Co ovšem při bližším zkoumání vypadá jako hlavní brzda rozvoje SaaS, clouds, atd. (říkejte si tomu, jak chcete), jsou uživatelova data uložená na serveru provozovatele aplikace. Zkrátka prima materiál pro pozdější zpracování.
I přikryl jsem nugetek opět hlušinou a věnoval se jiným věcem.

A jako už mnohokrát předtím, byl jsem okraden. Po mém nápadu sáhl Stallman, svatý muž z pravoslavné odnože církve Opravdu Svobodného Software. Jakousi podivnou synchronicitou se stalo, že zveřejnil úvahy, které zaměstnávaly mé podvědomí -- naplno se do toho obul a uživatele označil za tmel v rukou autorů webových aplikací.
Užuž jsem se chtěl tématu vzdát -- co vzmůžu proti Stallmanovu pěstěnému charismatu? Ale pak mi to došlo: ono to totiž není vůbec jednoduché.

Předně: Výtky kritiků oblačného počítání s uživatelskými daty se dají rozdělit do dvou velkých skupin. První z nich je:

Ztráta a nedostupnost dat

Zde jde o to, že se ke svým datům občas nedostanete, když je potřebujete. Příčiny mohou být různé, nejčastěji jde o selhání webové aplikace nebo technický problém toho, kdo aplikaci hostuje. Obecně je možno říci, že čím větší korporace, tím větší pozor si na výpadky dává -- i když výhrady jsou na místě. Úplná ztráta dat je spíše výjimečná a většinou souvisí i s úplným odchodem autora aplikace ze scény.
Pokud existuje k webové aplikaci slušně napsané API, má (pokročilý) uživatel k dispozici více či méně komfortní možnost svá data pravidelně lokálně zálohovat. Je pochopitelně rozdíl mezi pasivní datovou zálohou a fungující aplikací, nicméně je dobré vědět, že máme, po určitém úsilí, vždy nějakou nenulovou šanci svá data oživit jinde.

Pro webové aplikace mluví skutečnost, že z pohledu fyzického uložení dat není příliš rozdíl mezi plotnou disku na pracovní stanici a plotnou v diskovém poli poskytovatele aplikace. Naopak, ať už jde o pouhý RAID nebo o jiné technologie datového úložiště (např. GFS), je váš bajt lépe a s vyšší redundancí zapsán spíše na cizím disku než na vašem vlastním -- pokud si to nemyslíte, měli byste se sami sebe zeptat, jak často a na jak spolehlivá média zálohujete důležitá data ze svého počítače nebo mobilu.

Doposud jsem se zabýval jen tou méně zajímavou polovinou celého problému. Tou podstatnou je samozřejmě:

Datové soukromí a autorita

Důležitější, než důvěra v to, že data přečteme my, kdykoliv se o to pokusíme, je jen víra v to, že je nepřečte někdo jiný, ať už se o to bude snažit sebevíc.

Soukromí našich dat v rukou provozovatelů webové služby je většinou zaručeno slovně, přesněji řečeno v jazyce zvaném právničtina. V textech, s nimiž vždy souhlasíme, aniž bychom se namáhali je číst, stojí psáno, že poskytovatel vynaloží nemalé úsilí, aby naše data nikomu neukázal -- tedy, pokud k tomu nebude donucen, třeba soudem. Ovšem v případě, že se veškerá snaha držet jazyk za zuby mine účinkem, nebudeme ho za to, chudáka, nijak popotahovat, třebas před soudem.
Stručně: texty tohoto typu jsou bezcenné, protože nám nepomohou v situacích, kdy už si je opravdu musíme přečíst. Jakou mám záruku, že se má citlivá data nedostanou do nepovolaných rukou -- třeba jen vinou hloupé chyby v klauzuli databázového dotazu? Klidu mi nepřidá, když tuším, že leží v té samé tabulce jako záznamy mého konkurenta, jen jde o jiný řádek.

Nabízejí se analogie s bankou: máte raději své peníze pod matrací nebo v rukou spolehlivých finančních institucí? Důvěra v banky nebyla vždy tak samozřejmá jako dnes (já vím, teď se nabízí příležitost k aktuálním vtipům na účet bankovního sektoru, kterou nevyužiji). Pro účely přirovnání je dobré si uvědomit, že důvěra v banku, jakož i důvěra v poskytovatele webové aplikace, se opírá o autoritu instituce.

Důvěra v takovou autoritu je značně asymetrický vztah: Na jedné straně spotřebitel / zákazník / klient / uživatel -- prostě človíček s omezenými možnostmi obrany, na straně druhé silně se tvářící instuituce, která chce, aby jí bylo věřeno (přestože všichni víme, že každá instituce je utvořena z normálních, tj. náladových, chybujících, případně i zkorumpovatelných človíčků).
Zde se Stallmanem souhlasit mohu. Spolehneme-li se na slovní záruky autorit, budeme vždy jen tvárnou konzumní hmotou v rukou institucí -- bank nebo IT korporací.

Datové soukromí a technologie

Nexistují jiné záruky? Zdá se, že zatím příliš ne. Problém uživatelských dat si lidé uvědomují, o tom žádná. Pokud považujeme zajištění dat založené na důvěře v instituce za nedostatečné, není možné řešení založit na důvěře v technické prostředky?

Příklady by tu byly: Jediný bezpečný způsob, jak uložit autorizační heslo na serveru, je -- neukládat ho vůbec. Zadá-li uživatel při prvním přihlášení heslo, je toto nejprve převedeno z otevřeného tvaru do zašifrované podoby (hashed) a teprve v tomto tvaru je uloženo. Způsob převodu by měl zajistit, že získat otevřený tvar hesla z jeho zašifrované podoby je prakticky neproveditelné a že opakovaným šifrováním stejného hesla získáme vždy stejnou šifrovanou podobu. Pokud později potřebujeme uživatele autorizovat, postačí porovnávat šifrovanou podobu nově zadaného hesla s jeho dříve uloženou verzí. I když se pak někdo zmocní šifrovaných hesel na serveru, moc mu nepomůže ani to, že má k dispozici šifrovací algoritmus.

Je jasné, kam směřuji: Šifrování je celé založeno na obecně přijatelném předpokladu, že dobrý šifrovací algoritmus je veřejně přístupný a jediné, co je třeba udržet v tajnosti, je heslo, jímž jsou data šifrována. Čím více očí kryptologů vidí do toho, jak šifrovací systém funguje, tím je daný systém bezpečnější, protože jeho potenciální slabiny jsou pod veřejnou kontrolou.
Je tedy možné, aby datové soukromí webových aplikací bylo založeno na podobné technologické transparenci?

Představme si takovou podporu aplikace v prohlížeči, jež zajišťuje, že citlivá data vůbec neopustí uživatelův počítač. Server webové aplikace pak může pracovat pouze s daty, jejichž zneužití útočníkovi nepřináší velkou výhodu.
Samozřejmě, že taková architektura je o poznání složitější než to, co známe v oblasti webových aplikací dnes a vyžaduje obecně rozšířený prohlížeč s dobře propracovanou podporou uložení dat. Také je nutné, aby vzniklo více různých implementací této datové podpory, navíc se standardizovaným aplikačním rozhraním (JavaScript API), jinak hrozí klasický vendor lock-in (neboli: ''Jo tak vy nemáte nainstalovaný tohlencto naše rozšíření? Jak si to pak představujete, že vám naše aplikace poběží?").

(Vsuvka pro C++ programátory: Vedle šifrování se k lokálnímu úložišti nabízí se ještě jedna analogie, sice ve smyslu funkcionálního programování. Ten, kdo zkusil použít šablonovou knihovnu STL, pravděpodobně narazil na koncept tzv. iterátoru, oddělujícího datový kontejner od algoritmu. Osobně považuji tento koncept za jednu z největších výhod STL. Omlouvám se neprogramátorům za ztíženou čitelnost článku na tomto místě.)

Smrt "nativních" aplikací?

Ano, můžeme namítnout, že navrhované rozšíření o lokální úložiště dat prohlížeč více přibližuje nativním aplikacím, tak, jak je známe. Proč tedy nepsat rovnou nativní aplikace? Nebo -- proč nedat zákazníkovi rovnou do rukou kromě klienta i server aplikace?
Ještě jednou tedy a stručně -- proto, že webové aplikace na serveru poskytovatele jsou pružnější, praktičtější a zkrátka životaschopnější než všechny ostatní varianty. Jistě, že budou existovat odůvodněné vyjímky a stále bude vznikat určité nezanedbatelné procento nativních aplikací. Probírat všechny aspekty nehodlám, kdo dnes zpochybňuje jeden z nejviditelnějších trendů současného vývoje IT, asi by mé argumenty stejně nepřijal.
Soukromí uživatelových dat zkrátka vnímám jako nejvíce oprávněnou výhradu proti používání webových aplikací. Důsledné oddělení uživatelových dat od kódu aplikace na serveru -- i když jeho provedení může být složité -- tuto výhradu odstraňuje.

V rukou programátora zcela budiž algoritmus, protože jen programátor dovede zařídit, aby byl algoritmus k užitku. V rukou uživatele budiž data, protože jen uživatel ví, jak cenná data jsou.

8 komentářů:

jj řekl(a)...

Zdravím,
pěkná úvaha, i když se závěry se nedkokážu ztotožnit.

BTW: Co mě trochu zarazilo.

Citace "Důvěra v takovou autoritu je značně asynchronní vztah". Mně by se tam poté dle významového kontextu místo slova asynchronní hodilo slovo asymetrický. :)

bver řekl(a)...

@jj samozřejmě tam má být "asymetrický vztah", děkuji za upozornění.

Anonymní řekl(a)...

To, co popisujes je cesta, kterou se dat, ale pomuze to jen u aplikaci, ktera mracna pouzivaji ke skladovani vody. Pokud je potreba mit v oblacich i logiku, tak to narazi na skutecnost, ze ta logika potrebuje data nesifrovana.

bver řekl(a)...

@satai ano.

tam, kde neni problem, aby prohlizec odkroutil veskerou drinu na datech, je mozne, aby oblaka drzela jen sifrovanou podobu citlivych dat (mame-li vice prohlizecu, hodi se to kvuli synchronizaci).

pokud vychazime z toho, ze opravdu citlivych dat je jen male mnozstvi, muze byt hlavni objem dat ulozen v otevrenem tvaru u provozovatele a aplikacni logika mraku se nazere.

zalezi samozrejme na konkretni aplikaci a na definici toho, co jsou to "opravdu duverna" data.

jIRI řekl(a)...

Ach :-).

Nejprve bych chtěl poznamenat, že tuhletu úvahu o bezpečnosti jsem do svého opileckého žblebtu zapomněl dodat, protože jsem si, jako obvykle, neudělal poznámky :-).

Teď k tématu: Takže ty chceš síťové úložiště dat, ke kterému budou přistupovat aplikace které poběží lokálně, protože tak je to bezpečné. A jak sám poznamenáváš, jsou to v podstatě "nativní" aplikace (ve smyslu nativity jak ho chápeme dnes -- tedy že i Java a .NET jsou de facto nativní), ale zdráháš se je tak označit, protože od nativních aplikací se liší... Ehm... Čím vlastně?

Deploy modelem? Tedy tím, že nic neinstaluješ, pokud je dostupný update, tak se ti tak nějak sám podstrčí? Ale tohle jsou věci, které fungují i pro nativní aplikace (třeba ClickOnce od MSFT, který to samozřejmě tak trochu pohnojil, takže to nikdo nepoužívá, ale stejně... :-)). Na to se nemusím mučit s JavaScriptem :-).

A komu to přijde neohrabané (myslím velký framework jako je Java nebo .NET), ten sáhne pro Flash nebo Silverlight, které se nainstalují asi tak za 3 sekundy a poskytují mnohonásobně vyšší komfort než programovat aplikaci pro sedm různých verzí browserů v JavaScriptu.

IMO se lišíme tím co ještě považujeme za "nativní" a co už za "cloud" aplikaci. Pro mě situace, kdy jediné co je uložené na serveru jsou zašifrovaná data a instalační balíček (pseudo)nativní aplikace, není dost "cloud". Cloud je když data uploudneš kdoví kam a pak se modlíš, že, než ti dají výsledek, s nimi nedělají nic o čem ti neřekli.

bver řekl(a)...

@jiri ach jo.

ujasneme si pojmy: nativni aplikace je programovana pro dany OS, zpusob tohoto programovani je podruzny. neboli: pokud chces, aby tva nativni aplikace bezela jinde nez pod windows, musis ji portovat, coz je vetsinou pomerne bolestivy proces (ono to skoro funguje, diky skvelemu XYZ jazyku/knihovne/frameworku, az na to, ze... atd.).

to, co popisuju v postu, neni nejaka snaha priblizit se nativnim aplikacim (proc taky, kdyz to neprinasi vyhody). v textu naznacuji cestu pro webove aplikace na cloudech, jimz se dnes vytykaji ruzne veci, z nichz za nezasadnejsi povazuji prave nedostatek soukromi.

opakuji: vsude tam, kde to ma smysl, necht jsou data v otevrenem tvaru na serveru, vsude tam, kde to ma smysl, pouzijme vhodne navrzene REST+ajax kombinace.

takze pozor, zde nejde o nejaky "deployment model", server neni a nema byt pouhe uloziste pro aplikacni kod bezici na prohlizeci. webovou aplikaci tvori spolecne http server a javascript pro browser.

to, ze by nektere korporace strasne rady videly server jen jako staticke uloziste "nativniho" kodu a premysleji, jak co nejvic prosadit svuj browser plugin interpretujici jejich "nativni" (cti: uzavreny, proprietarni) framework, je namet pro uplne jiny post.

bver řekl(a)...

jeste relevantni odkaz, jenz jsem ztratil a opet nalezl:
http://blog.jamesurquhart.com/2008/08/cloud-computing-bill-of-rights.html

bver řekl(a)...

Nove se k tematu vyjadril i O'Reilly.