neděle 11. října 2015

Můj první Spartan Race – Kouty Super 2015

Rád běhám. Mám za sebou už pár půlmaratonů (pod 1:45) a překážky taky znějí zajímavě. Přihlásil jsem se tedy na Spartan Race v Koutech nad Desnou, konkrétně na variantu Super (tj. min. 13 km a min. 20 překážek). A opravdu – Spartan Race bylo něco, co jsem do té doby nezažil. Byl to snad první závod, kde jsem předem neměl moc tušení, jestli ho úspěšně dokončím.

Před závodem jsme si zvědavě prohlíželi předpověď počasí. Ano, když jsem se hlásil, tak jsem byl určitě rád, že v říjnu asi nebude horko. Předpověď ukazovala cca 3°C – 5°C. No, horko to není. Zimy bych se nebál, kdyby nebylo zvykem mít na trase nějakou vodu – cestu potokem, podplavání překážky apod. Ale na druhou stranu, o den později, kdy na stejném místě měl být další závod (tzv. Beast, tedy delší varianta závodu), mělo být podle předpovědi dokonce pod nulou. To jsem musel okomentovat: A po nás námraza!

Nikoho z nás ale počasí naštěstí neodradilo a v sobotu jsme dopoledne šli závodit. Před závodem jsem do sebe dostal ještě nějaký teplý čaj (měl jsem trochu rýmu), což byla ten den hned první chyba – nevlezlo se do mě tolik jídla, kolik bych si představoval. Ale co se dá dělat. Před startem se nás z pódia snažili rozproudit a navodit tu správnou atmosféru. Řekl bych, že se to celkem povedlo. Před startem jsme si tam trošku zaskákali. A pak – startujeme! Vybíháme…

Prvních pár překážek bylo tak na rozehřátí. Nic těžkého, musel to dát snad každý. Hned za začátku nás poslali do sjezdovky nahoru. To byl celkem typický terén na celém tomto závodě, ale občas to samozřejmě šlo i dolů. Snažil jsem se mít tempo tak akorát a nepřepálit to, což asi byla druhá chyba, ale k tomu se ještě dostanu. Sepíšu tu pár vzpomínek z překážek. Pokusím se to psát zhruba podle pořadí.

První trošku vážná překážka byla přeručkování jakýchsi tyček. Moje ruce snesou o poznání méně než nohy, ale překážku jsem zvládl celkem bez problémů. Jen jsem se mírně zadýchal, a když mi dohlížející slečna řekla nějaké povzbudivé slovo ihned po dokončení překážky, musel jsem asi vypadat jako profesionální hráč pokeru.

Hod oštěpem. Nic zvláštního, jen mých prvních třicet angličáků. To bývá za nezdařenou disciplínu, v tomto případě jsem se oštěpem netrefil na první (jediný) pokus. Ale žádný problém, jsem svěží a běžím dál.

Pytel s pískem. Každý jsme vyfasovali velký pytel s mokrým pískem a šli s ním po sjezdovce – nejdřív nahoru a pak zpátky dolů. Na začátku jsem řekl, že nechci slyšet, kolik ten pytel váží (sám jsem hádal aspoň 10kg), vzal ho na záda a šel. Nevím, jak to bylo vysoko, řekl bych, že nekonečně. Několikrát jsem do kopce zastavoval a odpočíval. Zastavil jsem i asi tři metry před vrchem. Sice to byly jenom tři metry, ale zároveň to byly ještě tři metry. Pak následovala malá rovinka – nejjednodušší část. Člověk by řekl, že dolů to půjde snadno, ale ne tak docela. Nahoru a po rovince jsem se aspoň s pytlem mohl předklonit a být tak nějak stabilní. Dolů mi ten pytel dost bral stabilitu. Vidím to jako asi pro mě nejtěžší překážku, co tam byla. Na konci překážky jsem se zeptal, kolik ty pytle váží. Pro muže prý 20kg-25kg. Takže s pytlem jsem byl tak o třetinu těžší, možná i o víc.

Zajímavý byl memory test. Člověk si podle svého startovního čísla našel v tabulce kód a musel si ho zapamatovat. O hodně později si na to musel vzpomenout – jinak ho to stálo třicet angličáků. Já jsem s tím neměl problém. Jméno Belinda jsem si zapamatoval. V číslicích jsem našel nějaké údaje jako třeba můj ročník narození (tj. „91“). Ještě teď si vybavím „64Belinda9117“.

Brzy přišel šplh po laně. Nic až tak zvláštního, jen druhých třicet angličáků pro mě, ale stále celkem pohoda. Moment, vlastně něco ano: Na lano se začíná lézt z vody. Když pak člověk dělá angličáky, pěkně se na něj nalepí všechno to bláto. Zhruba od tohoto místa jsem taky měl občas nějaké křeče v nohách, možná kvůli té studené vodě. Zima ale nebyla, na Spartanu se člověk zahřeje.

Asi dvakrát nebo třikrát jsme měli cestu (plazení nebo válení sudů) pod ostnatým drátem. Jednou jsem dokonce pod ostnatým drátem vleže někoho „předbíhal“ (jestli se tomu tak dá říct).

Pár překážek bylo na rovnováhu. Měli jsme přechod po lávce a přechod po kůlech. S ani jedním nebyl problém. Akorát tu lávku někdo přeběhl rychle a rozechvěl celou konstrukci, tak jsem uprostřed lávky chvilku stál a čekal, než se to uklidní.

Horostěna – moje třetí sada angličáků. Trošku zbytečně, ale stále jsem měl sílu a nebyl to problém. A jen tak mimochodem, přišel jsem tady na to, že mokrý papírový kapesník si moc snadno nerozložím.

Na desátém kilometru to přišlo. Překážka nebyla nic extra náročného, měli jsme přeručkovat po madlech. Něco podobného jsem už zvládl dříve, jen tam byly železné tyče, které byly příjemnější. Ale hlavně to tehdy bylo v místě, kde jsem měl dost síly. Tady jsem to zkusil, ale cítil jsem, že mě to dost výrazně vysiluje. Angličáky se začaly zdát jako přívětivá alternativa. Kdybych se hodně snažil, možná bych tu překážku dal až do půlky, ale angličákům bych se stejně nevyhnul.

Tak začala moje čtvrtá sada angličáků. Udělal jsem jeden angličák a zjistil jsem, že té síly už moc není ani na ty angličáky. Nohy mě asi nebolely, ani nic dalšího, jen jsem prostě měl dost hlad a neměl jsem energii. Asi po dalších šesti angličácích vážně zvažuju, jestli pokračovat. Hlad byl výrazný a bylo naprosto jasné, že do cíle to lepší nebude. S sebou jsem si žádné jídlo nebral. (Hmm, příště…) Přede mnou kromě angličáků a překážek bylo ještě asi sedm kilometrů nejistým terénem. Celkem otevřeně se tu ptám: Kdybych teď skončil, za jak dlouho se dostanu k jídlu? Místo odpovědi na svůj dotaz jsem byl ale ujištěn, že už to půjde jen z kopce a překážky už „budou neangličákové“. (Přeloženo do češtiny, překážky nebudou tak náročné, aby se na nich ve velkém dělaly angličáky.) Váhám, ale nakonec se nechávám přesvědčit. Dodělám angličáky a pokračuju dál. Kamarádovi, se kterým jsem do té doby zhruba držel tempo, jsem řekl, že nemá smysl, aby na mě čekal. Bylo mi jasné, že dřív než v cíli se asi nepotkáme, a nechtěl jsem ho brzdit.

Skutečně to už jde jen z kopce. (Všímáte si té ironické dvojznačnosti?) No dobře, zas tak zlé to nebylo, z kopce se dalo i celkem ještě běžet. K čemuž při vidině jídla byla i celkem motivace. Skoro každá překážka tu byla těžká. Ani přelezení dřevěné stěny (cca něco přes 2 metry) už nebylo zdaleka tak samozřejmé jako na začátku závodu, i když to bylo pořád z těch lehčích překážek.

Jedna z posledních překážek bylo podplavání desky. Žádný hluboký ponor, ale člověk se musel celý ponořit do vody. Po vynoření jsem ze sebe okamžitě sundal funkční mikinu, která poněkud nasákla vodou a pekelně studila. Ale pak dobrý, pohybem jsem se zahřál.

Prakticky poslední překážka byla pavučina z lan, kterou měl člověk přelézt. Nahoru to šlo snadno a dolů… Dolů by to mohlo jít ještě mnohem rychleji. Na pavučině bylo mnoho lidí současně, dost se to hýbalo. Sil moc nezbývalo a riskovat, že to dolů půjde ještě mnohem rychleji se mi opravdu nechtělo, i kdybych náhodou spadl na tu správnou stranu. Asi sto metrů před cílem tedy dělám pátou sadu angličáků. Sice jsem v tom nebyl úplně sám, ale šlo o jedinou vyloženě neangličákovou disciplínu, kde jsem dělal angličáky. Šlo to pomalu, ale nějak to šlo. Uff, a hurá do cíle! Už jen kousek potokem, přeskočit malý oheň a jsem v cíli. Čas nic moc, ale cokoli lepšího než DNF beru.

V cíli teprve začala zima. A tedy taky menší dilema – mám se prvně převléct, nebo najíst?

Můj první Spartan Race byla určitě zajímavá zkušenost a i nejedno ponaučení. Dost jsem podcenil dobu trvání, takže jsem neřešil jídlo na cestě. Taky kdybych to na začátku trošku víc „osolil“ (nohy by to patrně zvládly), mohl mě hlad dostihnout až o něco později. Což by se mi vyplatilo hned dvojnásobně – hlad zde vytváří jakousi pozitivní zpětnou vazbu: hladovému všechno trvá déle, ale o to je pak člověk hladovější. Určitě by pomohlo taky pití (hádám, že by to stálo za tu trochu zátěže), ale nepřišlo mi to jako až tak krizové. Na Super jsem byl vlastně vybaven spíš jako na Sprint (kratší varianta závodu). Hodilo by se taky posílit ruce, ale to vím už delší dobu. Příště můžu dopadnout lépe. Určitě toto nebyl můj poslední Spartan Race. Chtěl bych jít na Super nebo Sprint. Varianta Beast má zatím ještě čas.

Za dva týdny jdu na něco vyloženě odpočinkového – na půlmaraton.

úterý 2. června 2015

Review of Crypto library in Play! framework

I'd like to discuss the crypto library security and purposes, namely encryptAES and decryptAES methods. I find it easy to misuse the library. Moreover, recent 2.4 update changed some security properties. That is, some previously insecure usages are secure now, but also some previously secure usages are insecure since 2.4. This means users of Crypto library should consider the security impact before migrating to 2.4.

What has been changed?

The ECB mode has been replaced by CTR mode. I'll quote a misleading claim from the official documentation: The CTR mode is much more secure than the ECB mode.

The ECB mode is non-recommended in general, so this might look like a good decision at first sight. While the CTR mode can be more secure if properly used, it has some different pitfalls. Because some of these CTR mode pitfalls are not present in ECB, some previously secure code might become insecure.

There are some more changes, e.g. better entropy of key (higher effective key size). The old Crypto library uses first 16 characters of a string key (i.e. application.secret by default) as a key, which is wrong, especially when the string (application.secret) is hexadecimal (⟹ 64b effective key size) or so.

The new Crypto uses a hash function for deriving the key, which is much better. A PKDF would be even better for some purposes, but even now I don't see any significant issue with the new key derivation approach. (But it depends on usage! I'll discuss it later.)

What might be wrong for some usages?

Unlike ECB, the CTR mode is a stream cipher mode. Stream ciphers have usually two issues that are not present in ECB mode:

  1. Malleability. This one is not specific for stream ciphers, but stream ciphers are ultimately malleable. An adversary without the secret key can modify the cryptotext to mean something different. For more details on malleability, see the related Wikipedia article.
  2. Insecure when a key+IV is reused. If you, use one key with the same IV twice, some details about both plaintexts are leaked, potentially revealing both of them. See Reused key attack for more details.

The malleability can be mitigated by authenticated encryption, but Play! does not it implicitly. This would be correct for a completely new API if this was mentioned in the documentation. In Play!, the Crypto API is not completely new (so one might consider it as a BC break with some bad security implications) and the documentation even don't mention it.

The key+IV resuse attack (“keystream reuse attack”) can be mitigated by using random unpredictable IVs. The documentation is unclear about usage of IVs. It just states that both using an IV and not using an IV is supported, but it is not clear what is the default.

What else is wrong with the documentation?

I've found also some relict in documentation, ECB doc relicts. It is a minor issue: The documentation just states that some usage is insecure, although the issue is not true for CTR mode. See my comment on the related GitHub issue

What/who is the Play! Crypto library intended for?

A proper mode of operation must be selected for ensuring desired level of security for desired type of usage. There are various properties that can be considered neither good nor bad without defining the correct usage. I am also not sure if the library is intended for crypto-newbies (it is easy to use it wrong for them) or crypto-experts (they would want to choose the mode of operation themselves).

In addition to two CTR-related issues mentioned above, it is questionable if PKDF should be used. It is unneeded in some cases (e.g. if the key is application.secret), but it is welcome if you are using a potentially weak password (e.g. user password), because they slow bruteforce attacks down by some factor.

Well, I admit one can configure the mode. But I don't think that global config (i.e. play.crypto.aes.transformation config option) is a good idea. It is generally unclear what code is affected by changing this property. Is some library code affected? I don't know until I analyze all the libraries I use.

I'd like to hear answer to the question from the developers. It should be also noted in the documentation. Without it, one might assume that almost any behavior is OK.

Why do I disclose it publicly?

I respect responsible disclosure objective, but I don't think that keeping this issue private makes any sense now, especially when 2.4 is fresh. I feel it is better to warn programmers that they should think twice between 2.3 ⟶ 2.4 migration if they are suing Play! Crypto library.

Discussion

If you wish to discuss it, you should do so in the discussion thread on play-framework user group. Comments under this article are closed in order to prevent two separate discussions.

pondělí 23. února 2015

Password protection for purchases in Google Play can be bypassed. (And some other issues.) How to defend yourself?

Google Play allows you to buy apps, books and music. Once you enter a payment method, (e.g. payment card or carrier invoice), it is saved, so you can use the same payment method in the next purchase. Google offers password protection for that. It sounds great, but it can be bypassed. We actually don't have an additional security, but an unkept promise, which may have the opposite effect – the user might rely on the security enhancement, which does not work correctly.

There is an extra issue for users with multiple Android devices. The thief of one device can install apps on the other devices of that user. I'll also mention another related issue, but the last one is fixed.

This is just a warning about security issues, not a manual for the abuse.

This article is a translation (with minor modifications) of my recent article. I am sorry for the delay, I hoped to release this article sooner.

Google will not fix it.

Well, there were also some related issues in two-factor authentication, but Google fixed them quickly after they were reported. Google however refused to fix two Google Play related issues I will talk about.

By the way, Google has paid a bug bounty and listed me in the Hall of Fame, but they said they were happy with the current situation.

Where is the merit of the issue?

Google Play allow us to purchase some content using the Google Play application for Android, which is usually password protected. I haven't looked in the details of password verification, but I hope this is designed correctly. However, this is not the only way I can buy an item in Google Play. I can also use the web interface on https://play.google.com/. The web interface does not require the password for buying an item.

Moreover, the attacker does not need the victim to be logged in a Google account in a browser on the stolen device. Once the Google account is present in the device (which very likely due to the connections to the Android ecosystem), we can use the account also in a web browser. We just need a tool, which is often pre-installed in Android devices. I am talking about Google Chrome for Android, which suggest the attack when you are on the Google login page:

Well, it is unclear from the screenshot if there is a real attack possible. For example, Google might consider this login method to be something inferior, so Google would ask for password when buying an application. This is, however, not the case. Google allows you to use this passwordless login for buying apps without knowing the password.

There is one more issue. The attacker can install any application (paid or free) on other devices of the victim. For example, If you have your tablet stolen, the thief might abuse this feature for spying your phone.

How could Google fix it?

I've suggested some countermeasures:

  • Remove the passwordless login feature. This would surely mitigate these attacks, but it costs too much of user convenience and there are some more convenient ways.
  • If user uses the passwordless login, the Google Play webapp would require the user's password for any application installation request. If user logs in with the password, Google would allow installing apps without entering the password again.
  • The password would be required always when the user purchases some item in Google Play.
  • Some combination of the above. My preferred approach is asking for password when user buys an item (regardless the authentication method) and asking for password when installing any application (either paid or free) on a remote device using the passwordless login feature. However, when user uses, say, Firefox for Android, so he can log in only with the password-based authentication, he would allow the attacker to install any free application on other devices of the victim.

How can I defend myself?

First, when you lose an Android device, you should change your Google account password as soon as possible. (I also recommend changing all the passwords of other affected accounts, not just the Google account.) This performs a remote logout on the Android devices.

Screen lock might help, but it can be bypassed in general. In some cases, it might be very easy, e.g. on phone with enough access to recovery. In some cases, it might be hard, but one can disassemble the phone and directly access the flash memory. (Well, this extreme case is hard and might not be worth the cost.) Nevertheless, screen lock is likely to discourage some people.

Remote wipe tools can also help, but they should not be a primary countermeasure for this issue. First, I advise you to change the password regardless of remote wipe tools, because you can never be sure if you have it done in time. Moreover, I am not aware of any secure delete functionality in Android remote wipe tools. Of course, when you change the password, there might be still some other reasons for doing a remote wipe, so I don't suggest remote wipe tools to be useless. They are useful, but you should not rely on them too much…

And of course, the best countermeasure is not having your device lost :)

Issues outside the Google Play

Of course, there are some other parts Google ecosystem affected by passwordless login.

Two-factor authentication

There are some apps (e.g. Android) not supporting the two-factor authentication, so Google allows you to generate an application-specific password for these purposes. In order to generate an application-specific password, you have to re-enter your password, which is good. However, it used to be enough to use the password-less authentication in Android for generating new application-specific password. This could be abused by a thief of an Android device for having an access to the account even after the user changes the password.

Well, Google sends an e-mail when user generates a new application-specific password, but the attacker is very likely to have access to his GMail account, so he can easily delete it.

It is worth noting that this used to be also an issue for Android non-users. An adversary was able to abuse this feature for cloning an application-specific password and use the cloned one even after the old one is revoked. Some social engineering (like choosing a good name for it) might be needed for successful attack.

Fortunately, this issue was fixed quickly after I reported it.

Access to history and some other more protected data

Google tries to protect some data more than others. For example, when you go to https://history.google.com/, Google is likely to require your password even if you are logged in. The passwordless login seems to weaken this extra protection. Google sees this to be just a feature, not a bug. You can see the history data by using Google Search app. So, mobile devices (including tablets) seem to have a different security policy from desktops. It might be confusing, but we should be aware of it.

úterý 20. ledna 2015

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.

neděle 18. ledna 2015

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.

sobota 4. října 2014

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.

pondělí 24. února 2014

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.