BitLocker se dá připojit v Linuxu, alternativní systémy v telefonech a tabletech

9. 3. 2020
Doba čtení: 17 minut

Sdílet

Na přelomu února a března proběhl dvanáctý InstallFest. Mluvilo se například o tom, jak do Linuxu připojit disky zašifrované pomocí BitLocker, jak funguje správce oken Sway ve Waylandu či jak měřit cenzuru.

Lukáš Bařinka: bash script from scratch

Konferenci tradičně zahájil Lukáš Bařinka svou přednáškou o shellu. Mohl by vám shell pomoci při řešení problémů? V první řadě byste si měli říct, co potřebujete vyřešit. Poté je potřeba vybrat vhodné nástroje, které udělají co nejvíce práce za nás. Dalším krokem je vytvořit obecnou kostru a nad ní první prototyp. Tím dokážeme, že takové řešení je možné a má smysl se tím dále zabývat. Nakonec vytvoříme finální skript, který už budou moci používat další uživatelé.

Konkrétní příklad se zabýval kreslením grafu na základě předem naměřených dat. Pro vykreslování grafu můžeme použít nástroj gnuplot, který na základě vstupních dat a příkazů vykreslí obrázek. Umíme už nakreslit graf, můžeme vytvořit kostru našeho skriptu.

Na začátku skriptu je dobré uvést, co daný skript dělá. Pokud to neuděláte, skončíte s mnoha skripty rozesetými po systémech, o kterých už nebudete vědět, co dělají. Náš skript bude vytvářet obrázky, které spojí do jedné animace. Je dobré začít komentáři, ve kterých popíšete, jaké kroky vás čekají. My tedy potřebujeme vytvořit obrázek, přejmenovat ho a poté po sobě uklidit. Tuto část budeme opakovat pro každý snímek. Výsledek můžeme spojit pomocí  ffmpeg.

Pokud náš kód už funguje, můžeme postoupit k vytvoření dalšího prototypu. Někdy se vyplatí vrátit se o krok zpět a zvážit, jestli by nebyl vhodnější jiný přístup. Můžeme tak například dynamicky generovat skript, který pracuje s našimi daty a v každém kroku se posune. Pokud máme funkční výsledek, můžeme se rozhodnout svůj skript vylepšit.


První variantou je přepsat staticky uvedené hodnoty tak, abychom je například automaticky počítali podle vstupních souborů. Můžeme se také zamyslet nad tím, zda je rozumné vytvářet dočasné soubory v lokálním adresáři. Lepší variantou je využít adresář /tmp , který je přesně pro tyto účely vyhrazen. Jenže jak své soubory nazvat? Pokud to uděláme staticky, může dojít ke kolizi s jiným programem nebo s více instancemi stejného skriptu. Můžeme vymýšlet náhodná jména souboru a vymýšlet tak dlouho, dokud nenarazíme na unikátní. Může tu ale dojít k souběhu, obecně to nejsou dobré postupy.

Existuje příkaz mktemp, který tohle řeší. Jeho úkolem je vytvářet soubor či adresář atomicky, kdy pak nemůže dojít k problému se souběhem. Můžeme pak také snadno doplnit testy na to, zda je soubor s daty čitelný a zda obsahuje jen regulérní data. Pokud některý z testů selže, skript nedoběhne a neuklidí po sobě. Můžeme použít vestavěný příkaz trap, který umožňuje asynchronně reagovat na příchozí signály.

Nakonec můžeme předat přepínače a argumenty, aby mohl náš skript používat běžný uživatel. Přidáme tak například nápovědu, přepínač verbose pro delší výstup a další přepínače pro úpravu výstupu. Používá se k tomu příkaz getopts, který postupně načítá jednotlivé přepínače a ukládá je do vybrané proměnné.

Šimon Let: kontextová historie shellu

Historie v shellu funguje dobře, když potřebujeme najít jen předchozí příkaz. Stejně tak pokud si pamatujeme část předchozího příkazu, můžeme použít třeba Ctrl-r. Co když si dostatečnou část příkazu nepamatujeme? Nebo jsou si příkazy příliš podobné? Chybí nám tedy něco dalšího, podle čeho bychom mohli hledat a nespoléhat se jen na textový obsah příkazu.

Můžeme přidat kontext, což může být například aktuální adresář. Je to postaveno na tom, že v různých adresářích používáte různé příkazy. Můžeme také ukládat exit code, čas a datum, předchozí příkazy a podobně. Důležité může být to, zda jsme některý příkaz už dříve z historie vyvolali. V takovém případě je pravděpodobné, že ho budete hledat znovu. Pokud budeme historii synchronizovat napříč systémy, může nás také zajímat, odkud daný příkaz přišel.


Tento problém řeší projekt RESH, což je zkratka pro Rich Enhanced Shell History. Je to náhrada za reverzní vyhledávání, které běžně voláme pomocí Ctrl-r. Poslouchá také stisky šipek a umí si tak zapamatovat, který příkaz uživatel vyhledával. Projekt je napsaný v Go, velmi jednoduše se instaluje a nemá téměř žádné závislosti.

Ovládá se jediným příkazem reshctl, který umožňuje zapínat a vypínat různé vlastnosti. Poté už stačí jen v shellu použít Ctrl-r a začít psát jednotlivá slova, která se mají v daném příkazu vyskytovat. Poté si můžeme vybrat pomocí šipek, volitelně příkaz editovat a spustit. Příkazy pak můžeme filtrovat například podle adresáře, ve kterém se nacházíme.

RESH je zatím prototyp, který čeká další vývoj a doplňování funkcí. Autorem je sám Šimon Let a bude rád za jakékoliv nápady či zpětnou vazbu, která mu umožní projekt dále rozvíjet.

Jan Uhlík: Sway – tiling wayland compositor

Dlaždicoví správci oken nám umožňují elegantně pracovat s mnoha velkými okny. Umožňují nám také pohodlně pracovat s více různými monitory v různých konfiguracích. Základním principem je, že nově otevřené okno vždy využívá celou volnou plochu. Přednáška se nezabývala podrobně prací s dlaždicovými správci oken, ale spíš vztahem k desktopovému prostředí v Linuxu.

Grafické rozhraní v Linuxu funguje tak, že pokud systém obdrží signál od klávesnice nebo myši, předá jej přes jádro do displej serveru. Ten si uvědomí, že se signál týká konkrétního okna a předá signál do aplikace. Jak bude komunikovat displej server s aplikací, je dáno zvoleným protokolem. Od osmdesátých let se používal protokol X11, který funguje také po síti. Dnes ovšem spoustu funkcionalit displej serveru přebírá jádro operačního systému. Pořád ale používáme X11, takže aplikace musí implementovat spoustu nepoužívaných věcí. V roce 2008 byl proto vymyšlen nový protokol Wayland, který vše dramaticky zjednodušil a přenesl práci do jádra a aplikací.


Došlo také ke spojení displej serveru a správce oken. Proto také není možné používat správce oken i3, pokud zároveň používáte Wayland. Proto vznikl Sway, který sice na první pohled vypadá stejně jako i3, ale používá Wayland. Jde o velmi mladý projekt, který vznikl vloni v červnu, ale současné verze už jsou běžným způsobem použitelné.

Z uživatelského hlediska přináší použití Waylandu například různou úroveň zvětšení pro různé displeje, které mají různé DPI. Součástí projektu jsou různé utility jako swaylock pro zamčení displeje či swayidle pro automatické zamčení. Někdy to ale nechcete, třeba když koukáte na seriál, nechcete pořád zadávat heslo. V konfiguraci je proto možné nastavit, pro která okna otevřená na celou obrazovku se nemá displej zamykat.

Pro zobrazení stavových informací v panelu slouží utilita waybar, která na rozdíl od i3status umí zobrazovat ikony skrytých aplikací na všech obrazovkách. Připravená je celá řada užitečných modulů, které umožňují zobrazovat či nastavovat řadu věcí. Zatím tam není zobrazováno rozložení klávesnice, ale není problém si dopsat vlastní skript.

Pro pořizování screenshotů je možné také použít nové utility jako grim, wf-recorder a slurp. V konfiguraci je pak možné si jednoduše přidat klávesovou zkratku, která umožní rychle sejmout obrázek a uložit ho do správného adresáře.

Pro přecházení mezi různými konfiguracemi monitorů se hodí utilita kanshi, ve které je možné vše nastavit a pak stačí jen připojit jinou sadu monitorů a celý desktop se automaticky přenastaví. Jako emulátor terminálu je doporučován alacritty, ovládání podsvícení obrazovky zajistí light a změnu teploty obrazu v závislosti na denní době umožní  redshift.

Petr Černohouz: PaaS komponenty jako cesta k DevOps bez Ops

DevOps není žádná role ani tým, je to kulturní změna. Cílem je bourání bariér mezi vývojáři a adminy. V praxi je potřeba změnit zkostnatělé nasazování. Obvykle se totiž nasazuje zvykově s přesným pořadím manuálních kroků. Čím větší firma, tím více procesů definujících, které kroky může kdo udělat. Velmi často se také admini bojí vzdávat se moci. Obvykle jakákoliv snaha o změnu vede k ještě větším komplikacím.

Jak z toho ven? Pokud dáte vývojářům vlastní server, nebude ho nikdo dohledovat a nikdo aktualizovat. Vývojáři potřebují zprovoznit jednu aplikaci a mají pocit, že za zbytek zodpovídáte vy. Místo toho se osvědčilo dávat vývojářům rovnou k dispozici platformu. Připravíte jim pipelines s možností mírného upravení. Nemůžou pak dělat libovolné zběsilosti, jaké by mohli dělat u svého serveru.

Takové prostředí je jednoduše spravovatelné spolu s kódem, ale je potřeba předem promýšlet architekturu. Platform as a Service je prostředí, kde už je připravené běhové prostředí pro daný jazyk a je možné nasazovat vlastní aplikaci. Komponenty můžete získat u cloudových poskytovatelů jako AWS, Azure, Heroku, MongoDB Atlas a podobně. Druhou variantou je vytvořit si podobné prostředí na vlastní infrastruktuře pomocí Kubernetes nebo třeba OpenShift.


Má to samozřejmě i svá negativa. Jeden z problémů je, že pokud dáte vývojářům platformu, může vám snadno vzniknout anarchie. Běží mi to pomalu, přidám si pět nodů a poběží to rychle. Nebo něco nefunguje, tak si raději povolím všechno. Mohou tak výrazně vyrůst náklady, protože vývojáři místo optimalizace raději vytíží další zdroje. Administrátoři pak mohou objevit hrozné věci. Vaše práce tak nekončí tím, že předáte vývojářům platformu. Musíte jim to také dobře podat.

Před nasazením PaaS komponent je potřeba dobře znát problém, který řešíme. Musíme také dobře edukovat vývojáře, aby věděli, co jim to přinese a jaké problémy to vyřeší. Nebuďte také příliš optimističtí při propočtech nákladů. Jako u všech cloudů dejte pozor na odchozí provoz. Zásadní je také být vývojářům k dispozici a komunikovat s nimi. Je lepší poradit než jen kritizovat.

David Heidelberg: mobilní telefony a tablety s GNU/Linuxem v roce 2020

Pokusy dostat Linux na telefony běžných uživatelů lze datovat už na dobu před 15 lety. Siemens SX1 nebyl s Linuxem pro běžné uživatele příliš použitelný, Neo1973 selhávalo zase zejména z hlediska výkonu, Nokia 900 byla sice zajímavým počinem, ale nakonec ji zařízli manažeři Microsoftu, kteří do Nokie přešli. Docela dobrým řešením našeho problému by byla Jolla, která sice funguje dobře, ale některé komponenty jsou stále proprietární. To mi nepřipadá jako nejlepší řešení.

Dnes tu máme dva hráče: Google a Apple. Realita je taková, že Android není open source, tím je pouze projekt AOSP. Bude vám v něm ale chybět hodně věcí, které potřebujete pro běžné používání telefonu. Pokud například aplikace potřebuje používat služby polohy, potřebujete API, které je součástí uzavřeného Androidu. Musíte tedy používat Android, ať chcete nebo ne. Pokud nasadíte AOSP, dostanete jen částečně funkční systém.

Je ale vlastně na trhu prostor pro dalšího hráče? Microsoftu se na trhu chytrých telefonů prosadit nepodařilo. Proč by se to tedy mělo podařit někomu dalšímu? Odpovědí je soukromí. Nikdy si totiž nemůžete být jisti, že jsou vaše data anonymizována. Pro Google je totiž uživatel produktem a zákazníkem je ve skutečnosti tvůrce aplikace.


Proč tedy mít na telefonu přímo nainstalovaný Linux? Neexistuje jedna velká firma, která by měla přímý vliv na celý ekosystém. V základu tedy dostanete soukromí, protože už nejste produkt. Stejně tak dostanete svobodu, protože vám nikdo nediktuje, jak máte systém používat a jak si ho přizpůsobit. Zvyšujete tím také svou produktivitu, protože máte možnost využít pokročilejší vlastnosti systému. Linux bude mít na mobilním zařízení také vyšší výkon. Java má svoje výhody, má své opodstatnění, ale její výkon není optimální. Příjemná je také možnost oddělit aplikaci od zbytku systému, pokud si ji chceme vyzkoušet.

Dnes je k dispozici několik funkčních linuxových systémů optimalizovaných pro mobilní zařízení. PureOS je systém postavený na Debianu, který je rozšířený o některé speciální balíčky. Je to stabilní systém, který vás nezklame. Když běží na vašich serverech, udělá dobrou práci i na vašem telefonu.

Další možností je PostmarketOS, který je zase založený na Alpine Linuxu. Je to jednoduchá a minimalistická distribuce, která běží bez systemd a je možné ji provozovat také na starších jádrech z Androidu. Existují i další distribuce postavené na Ubuntu nebo Manjaro.

Existuje také několik uživatelských rozhraní. Jedním z nich je Phosh, které staví na GNOME. Vzniklo proto, že se vývojáři Purismu rozhodovali, zda portovat GNOME Shell na mobilní zařízení. Dospěli k názoru, že bude lepší napsat nějaké odlehčené řešení pro telefony. Podobně existuje Plasma Mobile, UBPorts, Mer či Jolla.

Pokud máme zájem si Linux na telefonech vyzkoušet, jsou k dispozici tři možnosti: dva hotové telefony a jeden komunitní. Purism Librem 5 se zaměřuje na soukromí a stará se o to, aby se žádná uživatelská data nedostala ven. Je to hardware i software, takže pokud si ho koupíte, nemusíte se o software vůbec starat a pouštět terminál. Librem 5 má na svém boku také tři přepínače, které skutečně odpojí napájení od Wi-Fi, modemu a senzorů včetně kamery a mikrofonu. Všechen vyvíjený kód jde zpět do Linuxu. Pravděpodobně ve čtvrtém kvartálu letošního roku půjde telefon do produkce, odhadovaná cena je 749 dolarů.

Další z možností je PinePhone od PINE64. Vzali hardware, který má v Linuxu dobrou podporu, a postavili na něm telefon. Nemusí se tedy starat o podporu v software a bude mít poměrně dobrý výkon. Cena bude velmi příjemných 145 dolarů, dočkat bychom se měli také ke konci roku 2020. Software je zcela na vás, ve výchozím stavu dostanete PostmarketOS.

Poslední možností je nainstalovat si Linux do běžného androidího telefonu či tabletu. Je to velmi jednoduché, stačí opsat pět příkazů a během 10 minut máte funkční tablet s Linuxem. Nejzajímavější jsou momentálně zařízení s čipsetem MSM8916, což jsou levnější telefony z roku 2015. Podpora pro ně je velmi dobrá, je velká šance, že všechno bude fungovat správně. Momentálně také běží portace na Samsung A6+, který se dodnes prodává.

Na vývoji se může podílet každý. Je možné například připravit baliček, adaptovat oblíbený software pro malý displeje (pomocí libhandy), optimalizovat software pro šetření baterie či implementovat OpenPush. To je alternativní implementace push notifikací. Pokročilí uživatelé mohou zkusit nainstalovat Linux i na zatím nepodporované zařízení. Stačí sepsat popis hardware a předat ho linuxovému jádru. Jste schopni obvykle Linux nabootovat i na něčem, na čem doposud nikomu neběžel.

Martin Prudek: Turris:Sentinel – sběr dat a dynamický firewall znovu a lépe

Turris byl původně výzkumný projekt sond pro český internet, který běžel už od roku 2014. Integrální součástí byl sběr dat, do kterého se museli uživatelé sond zapojit. Už tenkrát nás zajímala data o útocích, ze kterých vycházel už tehdy greylist a dynamický firewall. Občas se podařilo zaznamenat nějakou nešťastnou událost v domácí síti, o které byli konkrétní uživatelé informováni.

Původní řešení uCollect bylo psané na fixní počet zařízení a obsahovalo spoustu nevyužívaných funkcí. Hlavní roli v architektuře hrála databáze, do které přicházela obohacení o nová data a z ní se získávaly exporty pro analýzu. Tohle fungovalo dobře, pokud běžel původní projekt Turris. Po příchodu routeru Omnia přestal systém stačit, do centrální databáze už nebylo možné přidávat další klienty ani další statistiky.

Vznikl proto nový systém Sentinel, který je především škálovatelný. Chtěli jsme být připraveni na libovolný počet klientů. Výsledkem je velmi zjednodušený systém, který už jen dělá to, co je potřeba. Z původního použití databáze jsme si odnesli jisté trauma, takže jsme se rozhodli pro proudové zpracování dat. Odpadá tak přetěžovaný centrální bod a vše je postaveno na pipelines.

Pro každý zdroj dat je k dispozici jedna pipeline složená z „hloupých“ součástek. K propojení byl vybrán protokol ZMQ, což je něco jako TCP na steroidech a umožňuje zřídit jednoduše load-balancich. Nevýhodou je vysoká míra abstrakce nad nižšími vrstvami, která komplikuje ladění. Pokud dojde k chybě mezi vrstvami, je pro nás velmi těžké ji odladit. Většinou spíš doufáme, že se to spraví samo.

Zatím se ze Sentinelu získává jediná analýza – pro dynamický firewall. Každá získaná IP adresa sbírá trestné skóre podle závažnosti provinění. Poté se může dostat do našeho greylistu a pokud nějakou dobu problémy nedělá, tak vyprší a je z něj opět vyřazena.

Vojtěch Trefný: BitLocker v linuxovém prostředí

BitLocker je nativní technologie pro šifrování disku v Microsoft Windows. Poprvé se objevil v roce 2006 ve Windows Vista, s menšími změnami se používá dodnes. Ve Windows 8 se změnil algoritmus na AES-CBC a od Windows 10 je to AES-XTS. Neexistuje dokumentace k metadatům, ale existuje dostatek veřejných informací, na jejichž základě mohla vzniknout řada svobodných implementací.

Proč se tedy mají linuxáci zajímat o šifrování ve Windows? V současné době bohužel stále neexistuje technologie pro šifrování disku, která by fungovala v prostředí MS Windows i v Linuxu. V ideálním případě byste stejnou šifrovanou flashku připojili do Windows i do Linuxu bez potřeby instalace nějakého nástroje třetích stran.

Na každém zařízení jsou v metadatech uloženy dva druhy klíčů: klíč FVEK se používá přímo k šifrování dat a sám je šifrován pomocí klíče VMK. Ten je šifrován některým z více způsobů, podle toho, jak je dané zařízení chráněné. Flash disk je chráněný heslem, v případě systémového disku se obvykle používá čip TPM.

V Linuxu se proti tomu používají dvě spojené technologie: Device Mapper a dm-crypt. První jmenovaný je modul pro mapování blokových zařízení na další bloková zařízení, mezi kterými leží takzvaný target. Jedním z nich je právě dm-crypt, který se stará o šifrování a dešifrování dat mezi těmito blokovými zařízeními. Je možné jej používat přímo, ale není to tak uživatelsky přívětivé. Obvykle se používá LUKS pro standardní ukládání a správu metadat.

Princip obou řešení je podobný, protože BitLocker i LUKS implementují stejný standard pro ukládání šifrovaných dat na disky. Bylo by možné upravit Device Mapper tak, aby dokázal pracovat s disky zašifrovanými BitLockerem? Možné to je, potřebujeme jen znát šifrovací algoritmus, inicializační vektor, klíč a umístění šifrovaných dat.

Teoreticky by tedy bylo možné použít Device Mapper přímo, ale bylo by potřeba mu připravit složitou konfiguraci. Pro zjednodušení už máme utilitu cryptsetup, který od verze 2.3.0 podporuje získání metadat z BitLockeru. Stačí tedy použít argumenty bitlkOpen či bitlkDump a připojit zařízení. V současné době je podporováno chránění klíčů pomocí heslem nebo recovery heslem. Naopak nepodporované metody jsou TPM, smart karty, startup key a podobně. Co se týče šifrování dat, podporovány jsou všechny používané šifry, protože to jsou stejné, jaké používá LUKS. Metadata jsou podporována pouze ve verzi 2, tedy pro Windows 7 a novější.

Teď už zbývá jen automatická správa nově připojených zařízení, o což se stará démon UDisks. Pokud je správně na základě informací z udev identifikováno zařízení šifrované BitLockerem, dojde k automatickému připojení. Tohle je připravené, podpora bude k dispozici v další verzi.

Karel Kočí: kdy se kód čte jako kniha?

Proč bychom se vlastně měli zabývat kvalitou kódu? Protože kód píšeme jen jednou, ale mnohem častěji ho čteme. Čitelný kód je verifikovatelný a rozšiřitelný. Pokud jste kód zveřejnili jako open source, budou vám do něj ostatní ochotni přispívat. Budou vás mít rádi současní i budoucí kolegové a bude vás mít rádo vaše budoucí já, které bude za dva roky do kódu koukat.

Základní koncept pro zlepšení čitelnosti říká, že kód má nejen fungovat, ale má hlavně sdělovat myšlenku o své funkci. Každý znak (i prázdný) by měly být promyšlené, abyste vždy věděli, co říkáte čtenáři. Kód by měl být také segmentovaný, měl by naznačovat důležitost pomocí pojmenování a omezení přístupu. Dodržujte styl jazyka, když píšete v Pythonu, pište jako v Pythonu.

Poté byly v přednášce ukázány konkrétní koncepty jako: pojmenovávejte nepojmenované, nepřehánějte to s vatou, nepřipravujte se zbytečně na třetí světovou, jmenujte obecně a exaktně, čtenář není kompilátor, i nejlepší kód vyžaduje komentáře a dokumentujte globální proměnné. S dokumentací je často problém, že se při vývoji zapomíná na její aktualizaci. Je potřeba navázat testy na dokumentaci a také nutit sebe i kolegy, aby se dokumentaci věnovali.

Jan Pavlinec: úvod do měření internetové cenzury

Přednáška se zabývala testováním blokování domén, IP adres nebo jednotlivých webových stránek. Pokud cenzuru vykonává vláda, může tím ovlivňovat populaci. Cenzurovaná témata se často mění v čase, v závislosti na politických událostech. Když jsou v Číně velké oslavy komunistické strany, je to přímo měřitelné mírou cenzury.

Podobná měření mohou odhalit také nasazení některých technologií. Například v roce 2009 projekt Tor zjistil, že Írán nahradil řešení firmy Smartfilter za vlastní řešení. Můžeme také zjistit, jestli nedochází k porušování nějakých sankcí. Dříve měření pocházela především z univerzit, takže šlo jen o krátké časové úseky věnované konkrétnímu průzkumu. Data pak byla publikována v rámci nějaké práce ve velmi agregované podobě.

Dnes je daleko větší tlak na měření v reálném čase. Díky tomu máme průběžně k dispozici mnoho dat, která se získávají velmi jednoduše. K dispozici jsou například mobilní aplikace, které mohou průběžně měřit data v mnoha sítích.

Cenzuru je možné provádět pomocí DNS, blokování IP adres, blokování konkrétních URL, omezování rychlosti nebo různou kombinací uvedených metod.

Monitorovat cenzuru je možné například pomocí sítě sond RIPE Atlas, která ale umožňuje detekovat jen blokování IP nebo DNS. Není možné provádět HTTP dotazy, takhle možnost v sondách z bezpečnostních důvodů není.

Další možností je OONI, která je součástí projektu Tor. Cílem je poskytovat otevřené nástroje a poskytovat data i nástroje pro měření cenzury. Obsahuje tři komponenty: sondu, explorer pro prohlížení dat a další komponenty pro analýzu dat. Můžete měřit blokování IP, DNS či HTTP požadavků. Jsou tam i speciální testy na blokování komunikátorů, Toru či proxy serverů.

Projekt CensoredPlanet.org je provozován University of Michigan a nezapojuje žádné dobrovolníky. Snaží se oslovovat velké množství otevřených DNS resolverů, snaží se dotázat na různé domény a poté na základě odpovědí analyzovat, které domény jsou ve kterých zemích blokovány.

Poslední představenou možností byl NetBlocks.org. Ten má k dispozici vlastní hardwarové sondy, které provozují dobrovolníci. Kontroverzní funkce je zabudována přímo do projektového webu. Když jej navštívíte, stáváte se automaticky dobrovolníkem a váš prohlížeč začne měřit cenzuru ve vaší zemi.

bitcoin_skoleni

Nejširší pohled pak nabízí velké společnosti jako Google, které sledují výpadky připojení. Vlastní metriky má také Tor, který monitoruje změny v počtu připojených uživatelů či změnu druhu připojení. Zajišťují tak, aby státy nemohly zablokovat všechny uživatele.

(Foto: Anna Kapitánová)

Autor článku

Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. Studoval počítače a média, takže je rozpolcen mezi dva obory. Snaží se dělat obojí, jak nejlépe umí.