V Google Play lze obejít ochranu nákupů heslem. Jak se bránit?

Google Play umožňuje nakupovat aplikace, knihy a hudbu. Jakmile jednou vyplníte způsob platby (např. platební karta nebo vyúčtování operátora), uloží se a můžete toho využít při přístím nákupu. Od určité doby se Google rozhodl ochránit tyto nákupy heslem. Tato snaha je určitě chvályhodná, pokud by to ale nešlo obejít. Takto máme místo zabezpečení spíše nesplněný slib, který může mít spíše opačné účinky – uživatel se může na zabezpečení spoléhat, to ale nebude fungovat.

Další problém nastává, pokud máte více zařízení s Androidem. Případný zloděj jednoho z těchto zařízení Vám může instalovat aplikace na jiné zařízení bez Vašeho vědomí.

Článek slouží pouze jako varování před bezpečnostními problémy, ne jako návod na zneužití chyby.

Google chybu opravovat nechce.

Přesněji řečeno, nechce opravovat tu část v Google Play. Problém postihoval i například dvoufaktorovou autentizaci, ale tam to již Google opravil velmi brzy po nahlášení. O dalších dopadech ale později.

Zajímavé je, že mi Google vyplatil odměnu za nalezení bezpečnostního problému a zařadil mě do síně slávy, ale přesto to opravovat nechtějí.

Kde je problém?

Na Google Play můžeme nakupovat přes aplikaci pro Android. Ta chce heslo. Způsob, jak jej ověřuje jsem nezkoumal, předpokládám ale, že jej pošle serveru a že (snad) server tudy nedovolí nákup bez potřebného ověření. To ale není jediný způsob, jak mohu nakoupit v Google Play. Druhá možnost je navštívit https://play.google.com/ a nakoupit přes webové rozhraní. Webové rozhraní nepožaduje nákup znovu potvrdit heslem.

Možná se zdá, že útočník potřebuje uživatele, který zůstal v prohlížeči přihlášený ke svému účtu u Google. Není tomu tak. Jakmile v telefonu je účet Google (což obvykle je, pokud chce uživatel používat Google Play apod.), můžeme se s ním totiž přihlásit i ve webovém prohlížeči. Stačí nám na to jednoduchý nástroj, který je navíc v mnohých telefonech a tabletech již předinstalovaný. Jedná se o Google Chrome pro Android. Je to velmi jednoduché, stačí navštívit stránku s přihlášením a Chrome Vám řekne, co máte udělat:

Teoreticky v této chvíli útočník ještě nemá nutně vyhráno. Google by mohl brát přihlášení touto cestou jako „méněcenné“ a pro nákup přesto chtít heslo. Na svém vlastním účtu jsem si ale vyzkoušel, že zde Google heslo nevyžaduje.

Další problém je, že tudy lze instalovat aplikace (jak placené, tak ty zdarma) na libovolné zařízení spojené s tímto účtem Google. Pokud například ztratíte telefon, zloděj by mohl této vlastnosti zneužít ke špehování Vašeho telefonu.

Jak by to mohl Google opravit?

Googlu jsem navrhoval několik variant:

• Odstranit automatické přihlašování. Účinné řešení, ale zbytečně radikální.
• Pokud se uživatel přihlásil přes automatické přihlášení, chtělo by se po něm při instalaci aplikace přes webový Google Play heslo. Pokud se uživatel přihlásil zadáním přihlašovacích údajů, heslo by se po něm nechtělo.
• Heslo by bylo vyžadováno na každý nákup, ale ne pro aplikace zdarma.
• Nějaká kombinace výše uvedených pravidel. Preferoval bych, kdyby se Google ptal na heslo jak při nákupu jakékoli aplikace i přes webové rozhraní (i kdyby byl uživatel přihlášen na počítači přes jméno a heslo), tak v případě automatického přihlášení při instalaci jakékoli aplikace (třeba i aplikace zdarma) na vzdálené zařízení. Nicméně, pokud se uživatel z nějakého důvodu přihlásí ke svému účtu na mobilu v jiném prohlížeči (a tedy nutně použije heslo), třeba jen kvůli vyhledávání, umožní to útočníkovi instalovat neplacené aplikace na jiná zařízení uživatele.

Jak se bránit?

Zaprvé, při ztrátě telefonu nebo tabletu s Androidem co nejdříve změnit heslo k účtu Google. (Je samozřejmě vhodné změnit i hesla k ostatním účtům.) Tím ztracený telefon nebo tablet vzdáleně odhlásíte.

Samozřejmě může pomoci nějaký i zámek obrazovky, ten ale v principu lze obejít. Někdy to lze snadno (extrém je rootnutý telefon se zapnutým USB laděním, ale to už dnes není tak jednoduché zneužít – novější Android požaduje povolit klíč počítače), jindy obtížněji (teoreticky vždy můžeme telefon rozebrat a dostat z něj třeba flash paměť, otázka je, jestli to stojí za to). Každopádně zámek obrazovky telefonu může někoho odradit.

A samozřejmě ze všeho nejlepší je telefon ani tablet neztratit :)

Týká se to pouze Google Play?

Jak je možná zřejmé, tento problém se netýká výhradně Google Play, ale měl trošku více dopadů. Dříve jsem o dalších dopadech mlčel, protože by mohly naznačit podstatu chyby.

Dvoufaktorová autentizace

Ne všechny aplikace podporují dvoufaktorovou autentizaci, takže Google umožňuje si nechat vygenerovat speciální heslo, které budete používat v jedné konkrétní aplikaci. Google to zcela správně ochránil heslem. Jenže, jak možná tušíte, nebylo potřeba znát heslo. Stačilo mít účet Google v Androidu a bylo možné podobnou cestou generovat nová speciální hesla. Google sice uživateli poslal e-mail, že vygeneroval nové application-specific password, ale to nemuselo být moc platné, když útočník měl typicky i přístup k jeho e-mailu a mohl jej smazat…

Stojí za zmínku, že bylo možné takto „rozmnožit“ tato speciální hesla. Pomocí speciálního hesla je možné se přihlásit do Androidu. S přihlášením do Androidu potom bylo možné výše uvedeným způsobem získat nové speciální heslo.

Celý tento problém s dvoufaktorovou autentizací ale Google opravil brzy po nahlášení.

Přístup k historii a dalším datům s vyšší ochranou

Když jdu například na https://history.google.com/, Google po mě chce zopakovat heslo. Chápu to tak, že historie vyhledávání patří mezi data, která si podle Google zasluhují vyšší ochranu, a proto vyžaduje zadat heslo znovu. Automatické přihlášení v Google Chrome pro Android ale tuto zvýšenou ochranu narušuje. Jenže to není bráno za slabinu, protože v Androidu lze tuto historii prohlížet i jinudy. Rozumím, že bezpečnostní zásady na desktopu se mohou lišit od těch na mobilu. Je to sice trošku matoucí, ale chápu to.

Co má Dvorakova klávesnice společného s morseovkou?

Zamysleli jste se někdy nad vztahem mezi Drovakovou klávesnicí a Morseovou abecedou? Naučit se Dvorakovu klávesnici by mohlo být o trošku jednodušší se znalostí morseovky. Obojí vychází z frekvence písmen v angličtině. V morseovce se častá písmena zapisují kratší posloupností signálů, u Dvoraka byla nejčastější písmena umístěna na prostřední řádek. (Dvorak nicméně sledoval i jiné vlastnosti, jako posloupnosti znaků nebo střídání levé a pravé ruky. V tomto článku to neřeším.)

Všechna písmena v prostředním řádku Dvorakovy klávesnice kromě „H“ se v morseovce zapisují nejvýše třemi signály. Písmeno „H“ ale není až tak zásadní výjimka, to se zapisuje čtyřmi krátkými signály (....).

Takovéto pravidlo je trošku hrubé, protože nerozlišuje mezi délkou krátkých a dlouhých signálů. Například M (––) trvá dva signály, zatímco H (....) trvá čtyři signály. Pokud bychom ale uvážili délku signálů, zjistíme, že trvají stejně: Podle aktuálního doporučení trvá krátký signál jednu jednotku času, dlouhý signál trvá tři jednotky času a pauza mezi signály v rámci písmena trvá jednu jednotku času. Odvysílání „dlouhého“ písmena H (....) tak trvá 7 jednotek času (4 krátké signály a 3 pauzy mezi nimi), zatímco odvysílání „krátkého“ písmena M (––) trvá také 7 jednotek času (2 dlouhé signály po třech jednotkách času a jedna pauza mezi nimi).

Pokud bychom chtěli vytvořit opačné pravidlo, tedy že písmena do tří signálů mají být v prostředním řádku a ostatní písmena mají být v horním nebo dolním řádku, musíme mít bohužel více výjimek. Morseovka má celkem 14 písmen, která se zapisují nejvýše třemi signály. Dvorakova klávesnice má ale pouze 10 znaků v prostředním řádku. Nutně tak získáme aspoň 4 výjimky. Kvůli písmenu „H“ ale máme celkem 6 výjimek: v horním řádku G (––.) a R (.–.), v prostředním řádku H (....) a ve spodním řádku K (–.–), M (––) a W (.––).

Zajímavé ale je podívat se na znaky, které „měly“ být v prostředním řádku (protože jejich zápis v morseovce je dostatečně krátký), ale nedostaly se tam. Jde o písmena G (––.), R (.–.), K (–.–), M (––) a W (.––). Čtyři z těchto pěti písmen se jsou složeny ze tří signálů, u tří z nich navíc převažují dlouhé signály. Z méně než tří signálů se zde skládá pouze písmeno M (––), ale to se skládá ze dvou dlouhých signálů. Trošku se divím, že na seznamu výjimek není písmeno O (–––), které se skládá se tří dlouhých signálů a je tedy nejdelší.

Jak je na tom QWERTY/QWERTZ?

Rozložení QWERTY bylo vyvinuto tak, aby bylo psaní na něm co nejpomalejší, protože psací stroje tehdy nezvládaly rychlé písaře. Pokud bychom se pokusili aplikovat pravidlo o morseovce na QWERTY (příp. QWERTZ, ale tam to vychází prakticky stejně), dostali bychom mnohem více výjimek:

V prostředním řádku se nachází písmena F (..–.), H (....), J (.–––) a L (.–..), která se skládají z více než tří signálů. Prostřední řádek QWERTY má pouze 9 písmen, z toho skoro polovina (4) porušuje naše pravidlo.

Pokud chceme 14 písmen do tří signálů v morseovce umístit do řádku s devíti klávesami, minimálně pět písmen se nám tam nevleze. Další výjimky nám udělají zmíněná písmena F (..–.), H (....), J (.–––) a L (.–..), která vytlačí čtyři jiná písmena. Dohromady by mělo být 5+4+4 = 13 výjimek.

A skutečně. Horní řádek má písmena W (.––), E (.), R (.–.), T (–), U (..–), I (..) a O (–––), tedy celkem sedm 7 na 10 písmen. Prostřední řádek jsme si ukázali, ten má 4 výjimky na 9 písmen. Ve spodním řádku potom nesedí N (–.) a M (––), tedy nesedí dvě ze sedmi písmen. Máme tedy celkem 7+4+2 = 13 výjimek.

To je určitě mnohem víc, než kolik má Dvorak. Je to více než dvojnásobek. Na QWERTY tvoří výjimku přesně polovina písmen, což zhruba odpovídá náhodě. Pokud byla ale QWERTY navržena tak, aby se na ní psalo maximálně neefektivně, není to málo? Zřejmě neefektivita QWERTY měla spočívat v něčem jiném než v rozmístění kláves do řádků. Na QWERTY například převládá psaní levou rukou. Dost možná bychom ale našli i nějaký méně efektivní layout než QWERTY.

Který layout používám?

Na závěr dodám, že se nechystám přecházet na Dvorakovu zjednodušenou klávesnici. Rád jsem nahlédl do jejího návrhu, určitě má svoje výhody, ale byla by to velmi náročná změna – musel bych změnit layout na tabletu, mobilu a notebooku zároveň. Navíc na notebook by se pro začátek hodily přelepky na klávesnici a na mobilu by to bylo ještě horší – mám výsuvnou klávesnici a přelepky bych nejspíš sloupnul při otevírání a zavírání mobilu.

Používat Dvorakovu klávesnici na jednom zařízení a QWERTY na druhém by bylo obtížné. Pamatuju si, jak těžké bylo používat současně QWERTY (na mobilu) a QWERTZ (na notebooku). Časem jsem došel k tomu, že jsem to musel sjednotit a na notebooku jsem přešel na českou QWERTY. Ta byla celkem fajn, dokud jsem nepotřeboval psát na školním počítači s Windows, kde se česká QWERTY od české QWERTZ liší mnohem více než pouze pozicí Y a Z. Nedávno jsem zkusil česko-americkou klávesnici CShack, opravil pár chyb a mírně si ji upravil.

Jak zpracovávat chyby?

V programu může běžně nastat nějaká chyba, kterou bychom měli zpracovat. Výjimky nejsou jediná možnost, jak to řešit. Co víc, výjimky nemusejí být vždy tou nejlepší možností.

Dost totiž záleží na stylu programování. Nicméně dnes se styly programování často mísí, takže to není tak jednoznačné. Většinou dnes uplatníme od každého přístupu něco.

Imperativní přístup

V imperativním kódu budou výjimky nejspíše správná cesta. Pokud volám funkci (proceduru), která má něco provést, ale nevrací žádný výsledek nebo mě její výsledek nemusí zajímat, je dost velké riziko, že zapomenu zkontrolovat výsledek. Dopady mohou být někdy fatální. Pokud se nepodaří změnit adresář, mohu vymazat třeba úplně jiná data. Pokud se nepodaří zkopírovat data, může dojít k jejich ztrátě. Pokud se nepodaří volání setuid, program může běžet dál s vyšším oprávněním, jako to bylo v případě rageagainstthecage. V takovýchto případech je lepší program nechat spadnout než dělat, že se nic špatného nestalo.

Bylo by fajn, kdyby se programátor již při kompilaci dozvěděl, že něco zapomněl ošetřit. V Javě jsou k tomuto účelu checked exceptions. Používají se v situacích, kdy si programátor nemůže být jist, že operace proběhne bez chyby. Typicky jde o I/O. Naopak třeba u dělení by bylo otravné pokaždé muset kontrolovat, jestli nedošlo k ArithmeticException, ale zase programátor má šanci různými způsoby zajistit, aby nedělil nulou. Uznávám, že okolo checked exceptions je jistá kontroverze, a že nejspíš kvůli tomu je nemá moc jazyků. Nalezení hranice mezi checked a unchecked mi kupodivu v praxi většinou (ne vždy) nepřišlo jako až takový problém, ale třeba podpora v lambda funkcích je docela peklo. Dobře se to projevuje v Javě 8. Zkuste schválně upravit kód urlStringList.map((url) -> new java.net.URL(url)) do funkční podoby.

Funkcionální přístup

Mám dvě zprávy, jednu špatnou a druhou dobrou.

Špatná zpráva je, že v čistě funkcionálních jazycích není chytání výjimek zrovna běžná záležitost. Například v Haskellu se snad nedají výjimky chytat mimo I/O monády. Důvodů pro to může být více, třeba určité narušení čistoty vzhledem k línému vyhodnocování. Je tedy celkem OK vyhodit výjimku třeba u dělení nulou, což mohl programátor snadno ošetřit různými způsoby. Na druhou stranu je méně vhodné házet výjimku třeba u neexistujícího klíče mapy.

Dobrá zpráva je, že funkcionální jazyky přicházejí s něčím v jistých ohledech lepším, co by mohlo nahradit checked exceptions. Pokud výraz nemění stav, určitě nás bude zajímat jeho návratová hodnota. Jinak je zbytečný. (Výjimkou může být snad jen sleep.) V návratové hodnotě bude tedy buď výsledek, nebo chyba. Když chce programátor číst hodnotu, musí zároveň ošetřit i chybu. Podstatné je, že by nemělo jít o uspořádanou dvojici (errorCode, value), protože tady je velmi snadné přečíst pouze value, i pokud došlo k chybě. Spíše by mělo jít o typ Either[ErrorType, ReturnValueType]. V případě úspěchu se vrátí Right(value), v případě chyby se vrátí Left(errorDescription).

Možná to vypadá strašně komplikovaně, ale není. Funkcionální jazyky mívají pattern matching, který to usnadní. Ukážu příklad. Dejme tomu, že budeme mít celočíselné dělení safeDivision, které skončí chybou nejen v případě dělení nulou, ale i v případě nepřesného výsledku. Tedy safeDivision(9, 3) vrátí Right(3), ale safeDivision(9, 2) vrátí Left(InaccurateResult) a safeDivision(9, 0) vrátí Left(DivisionByZero). Budeme psát funkci, která má prezentovat výsledek uživateli. Její tělo může vypadat třeba takto:

safeDivision(numerator, denominator) match {
 case Right(result) => s"$numerator/$denominator = $result"
 case Left(error) => "Can't divide"
}

Nebo můžeme vypsat i konkrétní chybu:

safeDivision(numerator, denominator) match {
 case Right(result) => s"$numerator/$denominator = $result"
 case Left(InaccurateResult) => "Can't divide accurately"
 case Left(DivisionByZero) => "Can't divide by zero"
}

Daly by se vymýšlet i složitější příklady, kdy bychom napsali nějaký výraz pro prvek JSONu (například json.a.b.c.d.as[String]) a na konci bychom zjistili buď hodnotu, nebo srozumitelnou chybovou hlášku (např. "a.b.c je null"). Toto by se přes výjimky dělalo obtížně.

Nabízí se otázka, kdy ve funkcionálním programování použít výjimky a kdy návratové hodnoty. Výhoda výjimek je, že nezaplevelují kód, pokud ta chyba nemůže nastat, například u foo/(1+x*x) nenastane dělení nulou (pokud je vyřešeno číselné přetečení). Jejich nevýhoda je, že se na jejich zpracování snadno zapomene a že se hůře zpracovávají. Někdy se osvědčilo nabídnout dvě funkce, kdy jedna je optimistická (předpokládá bezchybný průběh, jinak hodí výjimku) a druhá pesimistická (předpokládá, že může nastat chyba, a vrátí Either nebo něco podobného). To může být užitečné třeba u mapy (slovníku), kdy záleží na použití, co se více hodí.

Který použít?

Rozmýšlíte se, jestli použít funkcionální přístup, nebo imperativní? Nenechte se zmást jazykem. Máme imperativní jazyky s funkcionálními prvky (Ruby, Java, PHP), máme čistě funkcionální jazyky s I/O monádami (Haskell) a máme nečisté funkcionální jazyky (Scala, LISP). Hranice jsou někdy diskutabilní, záleží dost na kultuře. Co tedy s tím?

Pokud by chyba v dobře napsaném programu neměla nastat, pak budou nejspíš nejlepší výjimky. Nutit programátora ošetřovat chybu, která nemůže nastat, těžko povede k něčemu dobrému. V lepším případě ji sám konvertuje na výjimku, v horším případě ji nějak bude ignorovat.

Funkcionální přístup se dobře hodí u výrazů, které nemají žádný side effect. Tam těžko zapomenu na kontrolu návratové hodnoty. Zbývá pouze otázka, zda zvolený jazyk nabízí vhodné prostředky pro tento přístup.

Diskutabilní bude použít funkcionální přístup, pokud sice mám side effect, ale vracím nějakou zajímavou návratovou hodnotu.

Pokud je ale volání čistě o tom, abych udělal nějaký side effect (změna adresáře, setuid, ...), potom je dost riskantní se spoléhat na ověření návratové hodnoty. Jsme čistě imperativní, výjimka je tedy skoro jasná volba, pokud to jazyk umožňuje. Diskutovat lze možná o tom, jestli má jít o checked exception, nebo unchecked exception.

Nokia s Androidem pod Microsoftem? Ono to začíná dávat smysl.

Nejdřív Microsoft, nepřesně řečeno, „koupil Nokii“. Potom se objevily spekulace o Nokii s Androidem, které byly v Barceloně potvrzeny. A do toho se objevuje spekulace, že by měl Microsoft umožnit běh aplikací pro Android na Windows. Dává vám to smysl? Začínám tušit, co se chystá.

Tento článek je spekulace. Snažil jsem se ale fakta odlišit od domněnek.

Telefony s Androidem byly skutečně představeny

Jasný fakt je, že Nokia smartphony s Androidem skutečně představila. Jde o levnější smartphony, mají systém upravený do vzhledu Windows Phone a nemají Google Play. Uživatel s telefonem dostane prostor v úložišti OneDrive od Microsoftu. Dokonce v systému lze najít označení „Nokia X software platform 1.0.1“, jako by to ani nebyl Android. Samo o sobě některé věci, zejména absence Google Play, znějí jako šílenost, ale s ostatními událostmi to dohromady začne dávat smysl.

Tyto telefony nejspíš bude vyrábět Microsoft

Ještě šíleněji může na první pohled znít, že tyto telefony bude nejspíš vyrábět Microsoft. Microsoft totiž koupil mobilní divizi Nokie. (Nekoupil celou firmu Nokia – ta bude stále existovat a bude dělat mapy Here, bude mít Nokia Solutions and Networks a další.) Zdroj už přesně nevím, ale od převzetí mobilní divize (očekává se první čtvrtletí 2014) do zhruba konce roku 2015 nebude, tuším, Nokia podle dohody smět vyrábět vlastní telefony. Těžko tedy můžeme předpokládat, že tyto telefony bude dělat Nokia. Spíš to převezme Microsoft s celou divizí Devices & Services.

Teoreticky by Microsoftu snad nemělo nic bránit v zahození těchto telefonů. Hádám ale, že se tak nestane. Spíše to vypadá, jako by vývoj těchto telefonů začal na pokyn Microsoftu.

I když je bude vyrábět Microsoft, mohou ještě mít značku Nokia

Nenechte se zmást, i když Nokia jako taková nebude patřit Microsoftu a bude stále mít svoji původní značku, dohodla se s Microsoftem na tom, že v některých případech může použít její značku. Můžeme se hádat, jestli „current Nokia mobile phone products“ napsané 3. 9. 2013 zahrnuje i telefony představené v roce 2014. Tisková zpráva nicméně není smlouva a právníci nejspíš pro skutečnou dohodu udělali přesnější formulaci. Dávalo by smysl, kdyby Microsoft nemusel rebrandovat všechny předchozí telefony a značku Nokia vypustil až u těch nových.

Microsoft prý snad umožní běh aplikací pro Android na Windows

Objevují se spekulace, že Microsoft umožní na Windows spustit aplikace pro Android. Nejspíš ale pouze ty, které sám schválí ve Windows Store. Instalace APK ze souboru tak asi možná nebude, Google Play nečekejte vůbec. Myslím, že podpora aplikací pro Android na Windows sice bude, ale bude to s ní trošku vlažnější, než to na první pohled může vypadat.

Zaprvé, těžko tu bude 100% kompatibilita. Některé aplikace pro Android mohou být vázány nějakým způsobem na Linux a to se Microsoftu asi nebude chtít řešit. (To se mimochodem nechtělo řešit ani BlackBerry, které to s aplikacemi pro Android myslí asi o něco vážněji.) Jiné aplikace zase používají Google Play Services, které tu bez dohody s Googlem nebude. (A pokud chce Microsoft schvalovat aplikace a mít provize z prodeje, dohoda tu asi nevznikne.) Microsoft může místo Google Play Services nabídnout alternativu s podobným či stejným API, ale třeba podporu push notifikací bude muset vyřešit vývojář i na serveru. Opět tu můžeme vidět do jisté míry paralelu s BlackBerry OS 10, kde též řešili podporu aplikací pro Android.

Zadruhé, možná ani po „jailbreaku“ nepůjde instalovat vlastní APK. Microsoft totiž nemusí dát do Windows obecný runtime pro aplikace pro Android. Možná bude mít pouze nějakou on-line službu, která aplikace pro Android (s nějakými omezeními) konvertuje pro Windows Phone. K této službě se mohou vázat různá omezení, která i v případě odemčeného telefonu zabrání nebo aspoň významně ztíží instalaci cizí aplikace jako APK.

Na druhou stranu, možná bychom nemuseli čekat na Windows 9, jak některé zdroje tvrdí. Touto cestou může Microsoft nabídnout tyto aplikace i pro starší Windows. V extrémním případě by věškeré potřebné součásti byly přímo v té konvertované aplikaci.

Microsoft to nejspíš dělá zejména kvůli Windows Phone. Smysl to ale může mít i kvůli desktopovým Windows – pro ty je sice aplikací dost, ale asi málo z nich je přizpůsobených pro dotykové ovládání. Pokud budou mít vývojáři možnost se věnovat hlavní platformě (Android) a s minimem práce ty aplikace dát i na Windows Store, budou tak nejspíš činit mnohem ochotněji a Microsoft by mohl tak rychleji zaplnit nedostatek aplikací.

Z Nokia X software platform může být „Windows Phone Lite“

Pokud ale bude podpora aplikací pro Android na Windows Phone, začínají dávat smysl telefony s Androidem. Zvláště když jsou upraveny tak, aby to Android moc nepřipomínalo a bude mít jiný obchod s aplikacemi. Navíc s nimi dostane člověk 10GB v OneDrive od Microsoftu. Jde o lowendy, které nebudou příliš konkurovat Windows Phone. Zatím snad vše nasvědčuje tomu, že Windows Phone budou pro Microsoft hlavním operačním systémem a upravený Android bude pro lowendy. Očekávám, že nastane zhruba toto:

• Pokud budu chtít aplikaci pro Android vystavit na obchodu Nokie (nebo Microsoftu?), bude muset splňovat stejná omezení jako pro Windows Marketplace. (Možná se najdou výjimky – například aplikace, které mají speciální verzi pro Windows Phone.)
• Na Nokiích s Androidem nepůjde instalovat aplikace z neznámých zdrojů, ale pouze schválené aplikace z obchodu. Naproti tomu na běžných Androidech je instalace z neznámých zdrojů otázka jednoho zatržítka v nastavení.
• Obchod Nokie časem splyne s Windows Marketplace.
• Všechen software pro Nokia X software platform půjde spustit i na Windows Phone. Naopak to ale platit nemusí.

Teď by to všechno mohlo dávat smysl. Microsoft by skutečně dělal telefony s Androidem, ale měl by tam Windows Marketplace a vlastně by ty telefony až tak nekonkurovaly těm s Windows Phone. Android v podání Microsoftu by byl spíše Windows Phone Lite.

Nové smartphony s Windows Phone by mohly používat značku Lumia, kterou Microsoft dostane od Nokie. Nové smartphony s Androidem by spíše použivaly jinou značku. Možná Asha, možná ještě jinou.

Možná se dočkáme navigace Here pro Android

Navigaci Here bude mít Microsoft licencovanou, ale patřit bude stále Nokii. Pokud tyto nově představené telefony mají mít Nokia Here, znamená to jediné – Nokia tuto navigaci připravila i pro Android. Samozřejmě nevím, jestli půjde nainstalovat do běžných telefonů s Androidem ani jestli tak půjde učinit oficiálně. Možná se ale objeví i přímo v Google Play. když Nokia nepatří Microsoftu, zveřejnění navigace Here v Google Play by dávalo smysl.

Budou aplikace pro Android univerzální?

Aplikace pro Android již dnes umí spustit Jolla (podrobnosti neznám) a BlackBerry OS 10 (s jistými omezeními). Nejspíš to bude do jisté míry umět i Windows. Stane se to trendem?

Hádám, že u iOS se podpory aplikací pro Android jen tak nedočkáme, aspoň zatím. Na to jsou příliš mainstreamové. Možná bude ale situace jiná třeba u Ubuntu. Technicky to může být i jednodušší než u Windows.

Na druhou stranu se jednotlivé operační systémy od sebe více nebo méně liší i logikou ovládání. Pokud bude snaha dostat k sobě aplikace pro cizí systém, mohou si s sebou vzít i logiku ovládání. V jednodušších případech to mohou vyřešit upravené knihovny, jindy ale bude potřeba ruční práce programátora a případně i návrháře UI. Jenže se může také stát, že aplikace pro ten OS nebudou mít uživatelské rozhraní dostatečně přizpůsobené a ovládání „infikují“ zvyky z Androidu.

Jak je to s volbou menšího zla? Proč se nebát volit malou stranu?

Blíží se další volby a k volbám obvykle patří debata o menším zlu. Myslím si ale, že zde dochází k určitým zjednodušením, která někdy dokáží – byť neúmyslně – přinést zmatek. Musíme totiž rozlišit, jaké jsou možnosti, a jaký je volební systém.

Poměrný systém

Pokud bychom měli dokonalý poměrný systém, pak by volba menšího zla evidentně neměla smysl. Mohu volit, koho/co chci, a v každém případě mám šanci na ovlivnění výsledku stejnou.

V praxi ovšem dokonale poměrný systém asi nenajdeme. Tím, že je počet volených zástupců mnohem menší než počet voličů, a tím, že každý zástupce má stejně silný hlas (není ovlivněn např. počtem voličů), bude vždy docházet k menším či větším zaokrouhlováním. To ale většinou není velký problém.

Jenže ani takto jednoduché to obvykle není. To by pro získání mandátu v Poslanecké sněmovně muselo stačit získat 0,5 % hlasů. To nestačí, protože tu jsou další deformace, jako třeba známý 5% práh. A tady začínají obvykle vznikat úvahy o volbě menšího zla. „Podpořil bych radši tuto malou stranu, ale ta se zcela určitě nedostane přes potřebných 5 %.“ To je do jisté míry sebenaplňující předpověď, která může dlouhodobě ovlivnit výsledek voleb dost výrazně. Je tu ale několik možných důvodů, proč i přesto může stát volba malé strany za to:

1. I pokud strana nezíská 5 % v těchto volbách, má její výsledek vliv na příští volby. Pokud strana získá např. jen 3 %, bude u příštích voleb brána nerozhodnutými voliči asi vážněji, než kdyby získala pouze 0,5 %.
2. Spekulace na těsné překročení 5% hranice. Případná ztráta nízká, případný výnos vysoký.
   Pokud strana získá pravděpodobně kolem 5 % hlasů, pak jeden hlas má mnohem větší šanci udělat významnější posun v celkovém výsledku voleb. Zvlášť pokud by mohla být potřebná pro vznik koalice.
   Toto jsem mimochodem reálně zvažoval u voleb v roce 2010.
3. Nechcete se nechat dovést k sebenaplňující předpovědi. Když přesvědčíte více lidí, aby se nenechali ovlivnit průzkumy, možná se budeme výsledkům voleb divit.

K čemu vede myšlenka „ztraceného hlasu“?

Upřímně by mě celkem zajímalo, co by se stalo, kdyby byla 5% hranice zrušena. Přirozená hranice u voleb do Poslanecké sněmovny by tak byla zhruba 0,5 %. Bez výrazné kampaně tuto hranici byli ve stávajícím systému například Svobodní v roce 2010 přesáhnout. Tehdy to byla nová strana, vznikli v roce 2009. Zajímalo by mě, kolik by taková strana mohla tehdy dostat, kdyby nebylo 5% hranice nebo kdyby ji voliči ignorovali. Možná i přes 5 %.

Dlouhodobě navíc může tento přístup vést k tomu, že bude mít hlavní slovo několik stran, které málokdo chce. Protože se skoro všichni budou bát volit nové strany. Staré strany pak budou mít možnost dělat si celkem co chtějí. Třeba slíbit, že daně zvyšovat nebudou, a po volbách je zvýšit.

Většinový dvoukolový systém

První kolo

První kolo je celkem nezajímavé. I když zde může být k volbě „menšího zla“ větší motivace, argumenty a protiargumenty jsou v zásadě velmi podobné.

Vlastně nějaká výjimka by se našla. V prvním kole je úplně jedno, kdo je první, a kdo druhý. Ti dva se utkají až ve druhém kole. Aspoň pokud ten první nezíská v prvním kole přes 50 %, což obvykle nezíská.

Druhé kolo

Ve druhém kole je to ale jiné. Pokud jeden z kandidátů je přijatelný a druhý ne, je volba jasná. Pokud je ale jeden špatný a druhý ještě horší, máme se také vyhnout volbě menšího zla, když je ta volba menšího zla tak špatná?

Ptám se, co tím člověk získá. Jediná možnost, jak se vyhnout volbě menšího zla, je nevolit. To v dnešních systémech neznamená, že chcete, aby místo zůstalo neobsazeno, tím pouze necháte volbu na ostatních. Kteří možná vyberou menší zlo a možná vyberou větší zlo. V čem si zde člověk pomůže oproti volbě menšího zla? V tomto případě v ničem. Nevolit tak má význam jen ve speciálních případech, například když z těch dvou variant neumíte vybrat menší zlo.

Proto si taky myslím, že je konzistentní na jedné straně kritizovat volbu menšího zla ve volbách do Poslanecké sněmovny, ale na druhé straně volit menší zlo ve druhém kole voleb do Senátu nebo ve druhém kole voleb prezidenta.

[AKTUALIZOVÁNO] Co bude znamenat přechod Opery na WebKit pro Operu Mini?

Asi jste zaznamenali, že Opera opouští vlastní vykreslovací jádro Presto a přechází na WebKit. Nevím, co bude s funkcí Opera Turbo, ale nejspíš by mohla v nějaké (byť technicky možná odlišné) podobě přežít. Co ale Opera Mini? Opera Software slíbila, že ji zachová. Což možná nebude tak jednoduché...

Jak funguje Opera Mini?

To, co si člověk stáhne do mobilu (klientská část Opery Mini), neumí ani HTML a CSS. To umí formát OBMP, který dostane ze serverů Opery. Nejde jen o nějakou obyčejnou kompresi typu GZIP. Server Opery patrně téměř kompletně vykreslí stránku a pošle ji v úsporném formátu klientovi. Ukázat si to můžeme malými experimenty:

• Zkuste otočit displej. Text se nijak nepřeskládá, vše zůstane tak, jak je. Text se přeskládá jen po reloadu stránky. Starší verze Opery Mini (zřejmě 4.*) se v tomto případě dokonce ptala, jestli uživatel chce stránku znovu načíst.
• Zkuste zkopírovat nějaký text na stránce. Zkopíruje se i s novými řádky a případnými přidanými mezerami. To jen podporuje variantu, kdy i lámání textu probíhá na serveru.
• Zkuste na nějaké stránce kliknout nějaké tlačítko, které provede nějakou akci offline. Například může jít o rozbalení/sbalení textu. (Dřív to šlo vidět dobře například na mobilní Wikipedii, dnes už ne.) Opera Mini to neprovede offline. Musí se zeptat serveru, co s tím. Javascriptová validace formulářů tak může docela obtěžovat.

Jistě by se našlo mnoho dalších příkladů. Formát OBML se nejspíš v jistém smysllu podobá PDF. Je to připraveno pro přesně dané rozměry stránky a nejde nějak snadno provést například text reflow. (Ano, u PDF to jde, ale je to spíš hack a jsou s tím spojeny jisté problémy, pokud se například používá dělení slov.)

A kde je problém?

Zkusme navrhnout, jak to implementovat. Mějme nějaké obecné jádro prohlížeče a implementujme nad ním prohlížeč podobný Opeře Mini. Co budeme potřebovat? Základ je jasný, klient pošle, řekněme, URL, rozlišení obrazovky a DPI, server to vykreslí a pošle zpět. Pro začátek třeba použijeme PNG, nebudeme řešit výběr textu, hledání, zoom ani datovou náročnost. Budeme asi muset sázet text do sloupců širokých nejvýše stejně jako obrazovka. To v případě WebKitu, který se používá v mnohých jiných mobilních prohlížečích, problém nebude. Budeme muset nějak udělat funkční formuláře, což vyřešíme posíláním pozic a identifikátorů jednotlivých elementů formuláře. Nejzajímavější ale může být implementace Javascriptu. Budeme muset vyřešit, která část stránky reaguje na kliknutí, udělat z ní odkaz, který se nějak speciálně zpracuje na serveru. Zároveň ale budeme chtít, aby se při kliknutí mimo klikatelné oblasti nemuselo nic vyměňovat se serverem. Toto už bude chtít celkem těsnou spolupráci s enginem.

Pokud se do toho Opera pustí touto cestou, nabízejí se navíc některé otázky. Udělá nějaký patch pro jednodušší integraci, který pošle vývojářům WebKitu? Kdo se o tyto patche bude starat? Bude se chtít vývojářům WebKitu?

Co s tím Opera udělá?

Je tu několik možností, jak se s tím Opera může vyrovnat.

Použít Presto pro Operu Mini?

Problém je v tom, že by museli Presto vyvíjet a záplatovat. Je otázka, jestli se to vyplatí. Nejspíš by to znamenalo jen vývoj v rozsahu oprav. Prvně jsem byl skeptický, ale postupně si kladu otázku, jestli by to nebylo u tohoto prohlížeče good enough.

Opustit stávající model renderování na serveru?

Pak by ale nejspíš nebyl rozdíl mezi Operou Mini a Operou Mobile (popř. Operou Ice). Pokud slibovali Operu Mini zachovat, pak asi nepůjdou touto cestou. To je dobrá zpráva pro uživatele J2ME verze, protože portovat WebKit pro J2ME by asi nikdo nechtěl. Když ne z jiných důvodů, tak kvůli nemožnosti spouštět přímo nativní kód. Kód v C++ by se špatně portoval.

Rozdělit WebKit na server a klienta?

Jak jsem psal, je to sice jedna z možností, ale jsou s tím spojeny různé výše uvedené komplikace. Možná by se změnil (zvětšil?) objem přenesených dat. Od verze 5 zřejmě v Opeře Mini funguje u interaktivních stránek někdy rozdílový update. (To je můj odhad podle měření objemu přenesených dat.) To by se mohlo změnit a třeba v první verzi by to nemuselo tak fungovat.

Co rozhodne

Vidím tu dvě reálné možnosti – adaptace WebKitu a udržování jádra Presto. Záleží na tom, jestli má jít o urdžení prohlížeče zhruba ve stávajícím stavu, nebo jestli Opera předpokládá další vývoj. Pokud předpokládá další vývoj, WebKit je asi jasná volba. Pokud ne, udržování jádra Presto (zejména opravy chyb) se může ukázat jako výhodnější varianta.

AKTUALIZOVÁNO: Opera kupuje Skyfire

Přidala se nová zpráva, kterou jsem si bohužel přečetl až po publikaci tohoto blogpostu. Totiž že Opera kupuje Skyfire. Trošku jsem zavzpomínal a pohledal a přinejmenším se dost nabízí, že Skyfire bude dost souviset s budoucí podobou Opery Mini. Dám sem citaci z článku z Wikipedie, které mluví za vše: In Skyfire's first generation (1.x) browser, a web page is fully rendered by a server separate from the mobile device, similar to the operation of a thin client.[3] This approach is also used by Opera Mini. Skyfire's second generation (2.x) browser employs a hybrid approach, using a conventional rendering of Web pages on the handheld device, but streaming video from Skyfire's servers.[4]

Je to otázka. Starší verze byla založena na jádru Gecko (stejně jako Firefox) a šlo o tenkého klienta stejně jako Opera Mini. Dnes staví na WebKitu, ale je mnohem blíže klasickým prohlížečům, protože na svém serveru zpracovává jen videa a podobný obsah. Může jít jen o komponentu do Opery Ice. Nebo se pro Operu Mini použije upravený kód ze Skyfire 1 a pro Operu Ice videa z novějších verzí Skyfire? Nevím, budoucnost je po tomto kroku ještě možná o něco nejasnější.

Zeman vs. Schwarzenberg: žádná sláva

Tak se nám blíží druhé kolo prezidentské volby. Zbyli nám jen dva kandidáti. Navzdory tomu, jak se prezentují, mezi nimi nevidím příliš rozdílů. Ani jednoho na hradě nechci. Ale přece jen vybírám, jeden z nich tam, bohužel, bude.

#Zeman a #Schwarzenberg s námi asi hrají hru "najdi deset rozdílů".

— Vít Šesták (@v6ak) January 16, 2013

Kauzy

Zeman je spojen s mnoha kauzami. O tom se mluví tak, že je zde snad ani nemusím zmiňovat. Mnohem méně se mluví o tom, že čistý není ani Schwarzenberg. Ten například hlasoval pro podporu fotovoltaiky. (Omlouvám se za Google cache, na senat.cz to dnes nefunguje.) Údajně hlasoval pro povinná biopaliva. (Nedaří se mi dohledat.) Doporučil schválit ACTA. A hlasoval pro ESM. Přesto má podle mnohých pověst čestného politika.

Čistě nevypadá ani jeden. I tak se je můžeme pokusit srovnat:

• Ke Schwarzenbergovi najdeme asi méně kauz.
• Není ale až tak důležitý počet, ale závažnost. V souvislosti se Zemanem jsem slyšel především o kauzách, kde se ztratil jednorázově nějaký milión, desítka milionů, možná miliarda. Máte-li jiné informace, uvítám. Zvlášť protože sám nejsem úplně rozhodnut, koho volit.
• Naproti tomu Schwarzenberg hlasoval pro smlouvu ESM a doporučil schválit smlouvu ACTA. Tuším, že tyto smlouvy by mohly (ACTA mohla, ESM může) páchat škodu řadu let po schválení.
• Od Zemana vyčnívá kauza Slonková. Ale nevím, jestli s tím měl Zeman něco přímo společného.

Dohled médií

Jak jsem psal, média jsou zajímavá věc. Zemanovy kauzy (aniž bych chtěl tím zmenšovat jejich význam) jsou propírány, zatímco podle dojmu z médií by Schwarzenberg měl být snad co nejdříve svatořečen. Nevím, čím to je, ale dobrý dojem z toho nemám.

Bankovní rada ČNB

Prezident jmenuje bankovní radu České národní banky. Stávajícím členům funkce mají končit v letech 2014, 2016, 2017 a 2018 (opravil jsem to podle ProInvestory.cz). Tady by se kandidáti lišili:

• Zeman by zvažoval mj. Švejnara.
• U Schwarzenberga jsem nic konkrétnějšího nenašel. V roce 2016 ale bude dost možná TOP09 mimo vládu a Kalousek by mohl mít zájem. Je to ale jen spekulace.

Ani z jednoho nejsem nadšený.

Zdroj: debata na iHned.

Euro

Oba by chtěli euro nejdříve v roce 2017, pokud se nepletu. Ani jeden mě tím nenadchnul, rozdíly zde moc nejsou. Zeman má u mě menší mínus za mlžení okolo Sorose. Ve skutečnosti by podobná situace mohla nastat i mezi dolarem a eurem, nezávisle na „velikosti“ měny.

Levice vs. pravice?

Zeman se otevřeně hlásí k levici, která se nebojí vyšších daní ani regulací. Karel Schwarzenberg se hlásí k pravici. Takže snižuje daně a dereguluje? Hmm, asi ne.

Tady taky není moc rozdílů. Nejde o souboj pravice vs. levice. A i kdyby byl, není to podle mého názoru u prezidenta až tak podstatné.

ESM

Už jsem o tom psal, zmiňuji to znovu, protože to zde má i další význam. Evropský stabilizační mechanismus by pro Českou republiku mohl znamenat povinnost platit dluhy („půjčovat“) za státy, které se příliš zadlužily. Až po vstupu do eurozóny, ke kterému jsme ale zavázáni (nemáme na rozdíl od Velké Británie a Švédska výjimku, takže si o tom nemůžeme rozhodnout sami). Vstup do eurozóny podporují oba kandidáti a u mnohých států (hmm, Řecko) ani nevadilo nesplnění příslušných kritérií. Je to tedy sice závazek do budoucna, ale ČR zřejmě nemá v případě jeho přijetí možnost se mu vyhnout. Šlo by to leda vystoupením z EU, které by mohlo trvat podle Lisabonské smlouvy až dva roky, ale na to bych se nespoléhal.

ESM schválila Poslanecká sněmovna i Senát. Prezident Václav Klaus odmítl tuto smlouvu podepsat. Je tedy otázka, jak se k tomu postaví příští prezident.

Tady se postoje kandidátů liší. Karel Schwarzenberg hlasoval pro ESM. V Prezidentském duelu 2013 na ČT uvedl, že by si smlouvu důkladně přečetl a pak by nejspíš podepsal. Jeden ústavní právník by ho od toho neodradil. Kdyby byli proti všichni ústavní právníci, pak by se podle svých slov ještě jednou zamyslel.

Naproti tomu Zeman jasně uvedl své výhrady proti ESM. Sice neslíbil, že nepodepíše, ale byl zde mnohem přesvědčivější než Schwarzenberg.

Dopady na další volby

Schwarzenberg je předseda strany TOP09. Přestože se mnozí voliči za volbu této strany omlouvali, Schwarzenberg je stále populární. Je otázka, co by se stalo, kdyby se stal prezidentem a nekandidoval ve volbách do Poslanecké sněmovny. Mohl by nastat propad TOP09. Je otázka, k čemu by to vedlo – jestli k větší popularitě ČSSD (vlastně žádná velká změna), nebo k větší popularitě skutečně pravicových stran.

U Zemana nedokážu odhadnout. Pokud by se stal prezidentem, byl by více na očích a více na očích by mohla být jeho strana. Ale na druhou stranu, pokud by do Poslanecké sněmovny nekandidoval Zeman, výrazná ikona této strany, jakou šanci by měla SPOZ.

Slovník prezidenta

Zemanovi je vyčítán jeho slovník. Zajímavé je, že se prakticky vůbec nemluví o tom, že ani Schwarzenberg nemá problém někoho označit např. za magora. Nevím proč.

Těším se na komentáře, jak je přisprostlej strejda Karel lepší než přisprostlej strejda Zeman (který se aspoň nestydí, že je levičák).

— Jan Sychra (@JanSychra) January 12, 2013

Na druhou stranu, je asi podstatné hlavně to, co prezident reálně udělá, než co (a jakými vyjadřovacími prostředky) říká.

Koho tedy volit?

Sám nevím. Zvažuji Zemana, ale ve hře jsou všechny tři možnosti. Snížit zisk TOP09 ve volbách do PS 2014 ale může být též zajímavé. Jisté je jen to, že k volbám půjdu. Není jisté, jestli k nim půjdu střízlivý. (Za střízliva se chci rozhodnout, ale ne vhazovat obálku s jedním z těchto dvou kandidátů.) Možná podpořím někoho třetího (via Dominik Stroukal), nevím.