Může být Česká televize opravdu nezávislá?

Článek vyšel též ve Stokách Svobodného přístavu.

Občas slýchám, že potřebujeme veřejnoprávní Českou televizi jakožto nezávislé médium financované z koncesionářských poplatků. Na první pohled to může dávat smysl – vliv má přece ten, kdo platí. Médium placené z reklam může být pod vlivem inzerentů.

Toto by dávalo smysl pro obhajobu nějakého soukromého placeného (popř. freemium) média. V případě veřejnoprávních médií ale platí někdo jiný, než kdo rozhoduje o platbě. Platí každý majitel a uživatel televizního přijímače, nehledě na to, jestli má o Českou televizi zájem. Co když bude chtít vedení zvýšit poplatky? Nestačí přesvědčit zákazníky, že služby za to stojí. Je potřeba přesvědčit politiky, že mají upravit zákon. Může být Česká televize nezávislá na poslancích?

Drahá úspora na elektronických dálničních známkách

Článek vyšel také na webu Mises.cz.

Občas slýcháme, jak transparentnost pomůže kontrolám veřejných zakázek. Pojďme se podívat na jeden celkem nedávný případ, kde jsme se prý dočkali ušetřené půl miliardy. To na první pohled může vypadat jako velký úspěch. Na druhý pohled to až tak velký úspěch není – i kdybychom předpokládali, že se ušetřené peníze využijí efektivně a na dobré účely.

Kauza elektronických dálničních známek

Možná jste v lednu 2020 zaznamenali státní zakázku na e-shop k elektronickým dálničním známkám za 401 milionů korun. Tato zakázka vzbudila pochyby, co je tak drahé na e-shopu o několika produktech. Chytil se toho Tomáš Vondráček ACTUM Digital, který uspořádal hackathon, jehož cílem mělo být vytvořit tento eshop za víkend a nabídnout ho státu zadarmo. To vyvolalo velký mediální ohlas, ale nakonec z toho stát nic nevyužije.

Oslava ušetřené půlmiliardy

Nedávno Tomáš Vondráček publikoval na LinkedIn oslavný příspěvek – ačkoli se výsledek hackathonu nevyužije, je to prý obrovský přínos, protože i tak se díky tomu povedlo ušetřit spoustu peněz:

Možná to zdaleka není půl miliarda

Objevil se i skeptičtější komentář Pavla Sundy (viditelný jen přihlášeným), že prý úspora není zdaleka tak vysoká:

Můžete prosím zveřejnit zdroj? Dle Registru zakázek je cena nižší o 100m bez DPH, ovšem nejsou v ní zahrnuty vouchery na doplňkové mandaye, čili v reálu je úspora nějakých 60mio. Viz https://www.hlidacstatu.cz/Detail/11860184?qs=CENDIS+

Na odkazu lze rychle ověřit, že se cena zakázky snížila jen o cca 100 milionů. Pro další tvrzení nemám v rychlosti k dispozici zdroje, a pravděpodobně by si to vyžádalo složitější analýzu, která by vydala na samostatný článek. Vyjděme tedy z předpokladu, že úspora se pohybuje v rozsahu cca 60–500 milionů korun. Je to sice poměrně velký rozsah, ale jádro článku nenarušuje.

Nechci úsporu zadarmo

Aby se tato úspora mohla uskutečnit, bylo potřeba vynaložit určité úsilí. To je přirozené, ale i toto úsilí má smysl započítat. Sice to nešlo ze státního rozpočtu a lidé toto úsilí vynaložili dobrovolně, i tak má ale smysl uvažovat o efektivitě tohoto snažení.

Jistě někdo si toho musel všimnout a publikovat. Tomáš Vondráček zorganizoval hackathon, který stál dobrovolníky nějaký čas. To by ale samo o sobě nestačilo, celé by to politici mohli snadno odignorovat, nebýt pozornosti veřejnosti. Lidé si o tom průběžně četli, slyšeli o tom ve zprávách, diskutovali s přáteli a sdíleli na sociálních sítích.

Možná si řeknete, že tyto náklady na veřejnou diskuzi nestojí za řeč – i kdybychom to přepočítali na peníze, bude to v řádu desetikorun na obyvatele ČR. Možná ano, ale potom zkusme stejnou optikou vidět i úsporu. Když úsporu cca 60–500 milionů podělíme cca deseti miliony obyvatel, jsme na 6–50 korun na obyvatele. Možná tak náklady na obyvatele byly větší než přínos. A i pokud ne, režie byla obrovská.

Kolika zakázkám jsme schopni se věnovat?

Pokud vám nesedí přepočítávání lidské pozornsti na peníze, nabídnu ještě jiný pohled: Lidská pozornost je vzácný zdroj. Zvládli jsme se věnovat jedné státní zakázce, probírat to s rodinou, přáteli a kolegy. Dovedete si ale představit, jak by to škálovalo? Že bychom takto probírali třeba jen malý zlomek všech zakázek? Kdybychom takto vyřešili třeba jednu zakázku za týden (což mi přijde dost optimistické), jsme na cca 52 zakázkách za rok, kterým jsme schopni se věnovat. Podle otevřených dat ISVZ jsem se dopočítal 55 673 zadání veřejných zakázek za loňský rok. Jedna zakázka za týden by tak znamenala méně než 1 ‰ všech zakázek. Tedy přes 99,9 % zakázek se nejsme schopni věnovat.

Radši přispět ve sbírce…

Kdybychom místo tohoto sledování státních zakázek ten čas věnovali nějaké práci a výtěžek poslali nějaké dobročinné organizaci vlastní volby, nejspíš by to přineslo větší dopad. (Pokud za dobročinnou organizaci považujete stát a považujete jeho hospodaření za efektivní, můžete klidně poskytnout dar státu. Já to pravděpodobně neudělám…)

Co si z toho vzít?

• Stát neškáluje.
• Současný stát je řádově větší, než co zvládneme uhlídat. (Nejde o počet obyvatel ani rozlohu, ale o to, co všechno se snaží stát poskytovat.)
• V minimálním státě by možná transparentnost pomohla, ale v současném stavu očekávám zanedbatelný přínos. Rozhodně na ni nespoléhejme jako na jediné řešení státní neefektivity.
• Nechtějme po státu další služby. Naopak revidujme, co všechno stát dnes dělá, a všímejme si věcí, které by dělat nemusel. Ostatně zaměstnance stojí stát cca ⅔ příjmu na odvodech, DPH, spotřebních daních apod. Prostoru ke zmenšení je spousta.
• Vážím si práce lidí, kteří poukazují na neefektivity státu, díky nim je problém viditelný i jako praktický problém. Nemusíme se tak opírat jen o teoretické odůvodnění nemožnosti ekonomické kalkulace od Ludwiga von Misese. Jen si nemyslím, že dotlačit politiky ke zlepšení jedné konkrétní zakázky stojí za to úsilí.

Život na vedlejších efektech

Znáte tu situaci, když nějaký produkt používáte způsobem, jak nebyl zamýšlen? Někdy se jeho nedostatky dokonce stanou žádoucí vlastností? Asi jako v komisku XKCD workflow:

Já to tak mám často, uvedu pár příkladů.

Kdysi dávno jsme v počítači měli disk, který nejen vydával hluk, když se točil, ale ještě k tomu vydával specifický výrazný hluk, když disk zrovna něco četl nebo zapisoval. Nový disk pak sice měl větší kapacitu, ale bohužel postrádal tuto užitečnou zvukovou signalizaci, na kterou jsem si zvykl.

Na telefonu Nokia 3120 snad nebylo možné bez odemčení kláves rozsvítit displej. Teda bylo. Stačilo napsat některé z vybraných nouzových čísel, jako například 112 nebo 911. Asi není moudré pro tyto účely používat místní nouzové číslo 112 (kdybych to omylem vytočil), ale naštěstí telefon takto z nějakého důvodu reagoval i na číslo 08. Stiskem další číslice jsem pak zrušil psaní nouzového čísla. Takže jsem používal sekcenci 080, abych zkontroloval stav telefonu. Bylo to praktické, protože 0 a 8 jsou poblíž.

Na touchpadu jsem si kdysi aktivoval emulaci multitouch. Potom systém například plochu palce bral jako dva prsty, což mi přišlo velice praktické. Bohužel jsem byl v tomto vnímání asi osamocen a novým notebookem jsem o tuto praktickou vlastnost přišel.

V autoškole jsem se naučil řídit starou Fabii 1.9 SDI skoro bez dívání na budíky. Rychlost odhadnu podle převodu a otáček. A na otáčky je tu „zvukový otáčkoměr“. Jenže, pokud budu mít relativně moderní auto, bude mít nejspíš příliš tichý motor…

Naštěstí tento problém až tak řešit nemusím. Asi vás nepřekvapí, že cílem autoškoly nebylo stát se řidičem…

A non-technical aspect of security – how could I have prevented the 2014 Jabbim password leak?

The 2014 Jabbim breach has happened almost five years ago, but there is still one interesting information to reveal. It is something I am not much proud of, but we can learn from both my mistake and Jabbim's mistake.

My experience with a past vulnerability report

Some time before the breach (2013-11-21), I had reported some seemingly unrelated vulnerability. Well, it was also an SQL injection, but on a different place. Moreover, just a script crash there had some unexpected consequences:

1. Some part of the DB remained locked.
2. This has caused many script waiting for releasing the lock.
3. As many web scripts were waiting, the server has reached the fork limit. As far as I remember, it was unable to serve even static files.

Maybe you can imagine what happened. Without having an idea that the status icon script is backed by a SQL database and without any bad intentions, just putting an apostrophe in the url accidentally caused an SQL injection and subsequent webserver crash.

I had good intentions, so I promptly reported the issue to admins. The reaction was like “Thank you for crashing our server. I could have been at home right now.”. Well, they fixed the issue, but my feeling from the communication was not much good.

My report of the vulnerability abused in the breach

The same day, I had also discovered another SQL injection vulnerability – in user search. That is, the same vulnerability that was abused in the 2014 breach. I also reported it, but I decided to contact another (hopefully more friendly) admin. However, I was just told about not having enough time for handling it.

So, I was about to report it to the unpleasant admin. He was offline that time, so I had to wait. When waiting, I started thinking about giving a report that demonstrates the danger but stands in limits of white-hat hacking.

However, this takes some time. As I was doing this in my free time for my fun and someone's else profit, I did not have enough time for making the report perfect. I needed to do some other duties, maybe something school-related. So, I postponed it for indefinite amount of time and you know the result… I am really sorry for that.

What could have been done better from the reporter side?

Although I would not describe me as a perfectionist, I admit I sometimes have some perfectionistic traits in a limited way. That said, I am not perfect at avoiding perfectionism. But “perfect” is an enemy of “done”. I could have opted for a trade-off – to try to make the report perfect until some deadline. Once the deadline passes, I would report it in however imperfect form.

What could have been done better from the admin side?

This is much related to the first vulnerability report.

• Do not discourage white hats: While I understand that a vulnerability report might be something unpleasant to handle in general, they could have responded in a more kind way. I believe it was obvious I had no bad intentions and tried to behave as responsibly as possible.
• Encourage white hats: There are some companies that even reward vulnerability reports and/or put your name to a hall of fame. If vulnerability rewards are expensive, you still can have a hall of fame, like some companies (even Google) have.
• Have a contact for reporting of security issues. It is also a good idea to have security.txt file, but it should not be the only way to contact responsible persons. (I know, security.txt has started in 2017, so they could not have it. But today, it is a good idea to have one.)
• When you receive a vulnerability report but you are not the right person to handle it, forward it to someone responsible as soon as possible.

Cache-friendly secure connection for websites

While commenting Eric Meyer's article about issues that HTTPS bring to Africans, I found that this should be probably also posted as an article. I am discussing how to allow better caching while keeping a reasonable level of security brought by HTTPS.

We still need secure connection, even for public static sites

I still believe we should have a secure communication everywhere; I am not 100% sure if this should be the current HTTPS.

We need secure connection even for public static sites. The reason #1 is not encryption, it is authentication. We do not want infected routers / people with Wi-Fi Pineapple / malicious to ISPs / etc. to modify webpages we see. Without some kind of secure connection, they could for example inject some cryptominers or advertisments or malware. They could also modify the content of static pages to instruct people to do something dangerous, e.g., modify recommended amount of some chemicals.

Do we always want TLS?

The way we secure our communication does not have to be today's HTTPS, though. Encryption is needed just sometimes. On public static sites, it can kind of obscure what are you looking at (e.g., attacker sees you are looking at Wikipedia, but it is not clear what page), but traffic volume analysis can often distinguish between specific pages.

How to make it better?

Let's look at some options to make it better. There will be some tradeoffs to privacy, but we will not let attackers to affect traffic in an arbitrary way, as plain HTTP would allow. Thus, we would not make the user more prone to downgrade attacks than with today's HTTPS. Our main point is allowing the caches doing their jobs, maybe a better one than with the current state of the art HTTP caches can do.

Mixed content secured by SRI

First, we could sometimes achieve a reasonable level of security even with a plain HTTP. We could have loaded some images, stylesheets and even scripts over a plain HTTP, provided they are protected by subresource integrity (SRI). I have wondered why browsers consider even SRI-protected resources as a mixed content. They are protected against modification and they do not necessarily contain anything sensitive. I don't much need to hide the fact I am downloading jQuery 1.8.1… (Today, such change in browsers can be a bit more complex if it has to be compatible with older browsers with a more strict mixed content policy. It would ideally bring something like allowplain atributte, allowing usage of plain HTTP instead of HTTPS.)

Shared cache based on hashes

With SRI, we could go a bit further. Where explicitly approved by some extra header, the browser could just match the hash for caching purposes, even if it has not ever downloaded the specific URL. As a result, we would not needlessly download dozens of exactly same copies of jQuery or Bootstrap. We could download it just once and then use the cache. While this could serve as some minor side channel that reveals information what files are already in your cache, explicit approval through some header can make it a non-issue.

Serving signed responses from caching proxy

We could also have some caches of some signed (but probably unencrypted) data. This however goes with some privacy tradeoff and new protocol to implement, but it does not give up data authentication. A cache server could return some data with expiration time and signature, even without contacting the upstream server. This is quite more complex, but still technically feasible. We cannot use TLS at this point, because TLS serves for transport layer, which we would like to intercept. The handshake could however start as a standard TLS handshake and continue with a different protocol:

Client: ClientHello, I am trying to connect through TLS to host example.com, there are my capabilities (ciphersuites). I am able to use caching proxy instead of standard TLS.
Caching proxy: Hey, I have some content for this server cached. See my non-expired approval from the server, signed by the private key of certificate holder. I am allowed to serve you some of the requests. Plus there is the OCSP response, so you know the server's certificate is not revoked. You see, the private key holder indicates there is nothing sensitive in the URL, you can send it to me.
Client: OK, there is the full URL: htttps://example.com/contact
Caching proxy: OK, there are the data authenticated by the server.

If client or server does not support such a feature, either just because it is not implemented or because they don't want this for a reason, no other party can force the communication to go this way instead of standard TLS.

• Website owner agreement is needed: If the proxy does not have a signed and non-expired approval, it cannot force the client to reveal the full URL.
• If the browser chooses not to use this way (e.g., because of user's decision), it can insist on a standard TLS handshake.
• Standard TLS handshake can ne required for some blacklisted URLs (e.g., /api/*), POST requests or if some specific cookie is present. Those exceptions could be described in the initial approval.

Cache-friendly version?

I am, however, generally against making special cache-friendly sites, similar to past “wap” or “mobile” versions. If they have a different URL, it gets tricky to handle links. When I click a link from elsewhere, it does not necessarily point to the version I want. Also, force website owner not to use HSTS, which is probably not what we want.

Challenges

• UX issues: Maybe just some users will want such tradeoff, while some others will not. How to allow both of them making an informed decision?
• None of those suggestions is enough reviewed by others. Furthermore, description of signed caches is quite vague to properly review, because I have prefered to be concise. While I have some security and crypto background, I don't think this should be implemented without any review.
• This would require multiple parties to implement it. All the ideas require some change in browser and the website. The last one also requires important modification of the webserver and proxy. But incentives to implement this can be quite low for most people with fast Internet connection. On the other hand, the SRI enhancements are not so hard (i.e., they are much easier than extending HTTPS to some TLS alternative) and can be useful even in Europe / America on mobile connections, despite there is no proxy that can speed up loading.
• Any change in browsers is likely irelevant for people with Windows XP or something similar. On the other hand, they could be welcome anyway if their usage don't break anything.

Pebble patří FitBitu. Co to přinese?

Je už oficiálně potvrzeno, že FitBit koupil Pebble, údajně za 40 milionů dolarů. Co to bude znamenat pro fanoušky hodinek Pebble?

Článek vyšel na MyPebble.cz.

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.