V systému Android a dalších systémech se slovo „blob“ často používá k označení softwaru s uzavřeným zdrojovým kódem. Konkrétně binární nebo proprietární bloby jsou fragmenty, které ovládají klíčové hardwarové funkce a jsou zahrnuty bez zveřejnění jejich zdrojového kódu. V telefonech a tabletech to ovlivňuje modem, GPU, GPS, fotoaparát nebo Wi-Fi, takže jejich přítomnost omezuje to, co můžeme auditovat, upravovat nebo opravovat. Bez těchto komponent se mnoho zařízení nebude správně spouštět nebo nebude mít přístup ke všem svým funkcím , a proto vzniká dilema: pohodlí versus svoboda a ověřitelná bezpečnost.
Debata není nová a prostupuje ekosystémem open-source softwaru: některé projekty pragmaticky akceptují bloby, aby zajistily funkčnost systému, zatímco jiné je odmítají, aby zachovaly transparentnost a kontrolu uživatele. Diskuse je obzvláště intenzivní v Androidu, protože téměř celý hardwarový stack se spoléhá na proprietární ovladače , což vysvětluje, proč se pokusy o vytvoření zcela open-source telefonů potýkají s technickými a právními omezeními již léta.
Co přesně jsou binární nebo proprietární bloby v Androidu?
V žargonu komunity svobodného softwaru je binární blob objekt načtený do jádra nebo systému bez přístupu ke zdrojovému kódu. Jedná se o předkompilované binární soubory poskytované výrobcem namísto technické dokumentace , která by umožňovala vytváření ovladačů s otevřeným zdrojovým kódem. To je běžná praxe u grafických procesorů, síťových čipsetů, mobilních modemů a řadičů RAID a v systému Android se to rozšiřuje na velkou část hardwaru zařízení.
Když dodavatel publikuje komplexní manuály a specifikace, vývojáři mohou psát ovladače s otevřeným zdrojovým kódem a spravovat je v komunitě. Problém nastává, když dodavatel nedokumentuje nebo si nevynucuje dohody o mlčenlivosti , což nutí vývojáře integrovat svůj proprietární blob do oddílu dodavatele . Systém se tak stává závislým na daném binárním souboru, jeho licenci a podpoře, kterou se dodavatel rozhodne v průběhu času poskytovat.
Důsledky jsou jasné a komunita je rozsáhle zdokumentovala: uživatelé nemohou upravovat ani dále distribuovat odvozené verze těchto binárních souborů; jejich přenositelnost je omezena na několik architektur; jejich kvalitu a správnost nelze ověřit; nelze s jistotou auditovat zabezpečení ani detekovat zadní vrátka ; a v případě chyb nebo zranitelností je komunita nemůže opravit bez zásahu dodavatele. Dodavatel může navíc kdykoli ukončit podporu, takže funkční zařízení zůstanou bez kritických aktualizací.
Aby se zmírnil nedostatek nativních ovladačů, někdy se k vytvoření vrstvy kompatibility používají obalovací moduly. Tyto obalovací moduly umožňují použití ovladačů určených pro jiné systémy , ale neřeší základní problém: komponenta zůstává neprůhledná, závislá a často křehká, když čelí změnám v hostitelském systému.
Ve světě systémů BSD a GNU/Linux nacházíme širokou škálu postojů. NetBSD, FreeBSD a DragonFly BSD v určitých případech akceptovaly bloby, aby poskytovaly funkce, které by jinak neexistovaly. OpenBSD a LibertyBSD zastávají pevný postoj, že do svého stromu distribuce žádné bloby nezahrnují , a upřednostňují ověřitelnou bezpečnost a transparentnost. Mezi 100% bezplatnými distribucemi vynikají gNewSense, Trisquel a Parabola svým aktivním odporem vůči blobům.
Rizika, důvody odmítnutí a pozice v komunitě
Důvody, proč se vyhýbat binárním objektům blob, vývojáři i pokročilí uživatelé opakovaně opakují. Mezi kritické body patří svoboda použití, přenositelnost, správnost, bezpečnostní audit a údržba a nejsou teoretické: ovlivňují každodenní život těch, kteří chtějí dlouhodobě spolehlivý systém.
- Nelze je upravovat ani dále distribuovat.Uživatel nemá kontrolu nad softwarem, ani si jej nemůže přizpůsobovat svým potřebám ani sdílet vylepšení.
- Omezená přenositelnostObvykle jsou kompilovány pouze pro několik architektur a není možné je migrovat na jiné systémy.
- Ověření nemožnéNeexistuje způsob, jak ověřit jeho přesnost ani vnitřní kvalitu.
- Nulový bezpečnostní auditBinární soubor by mohl skrývat zadní vrátka nebo spyware, aniž by ho kdokoli zvenčí snadno odhalil.
- Bez opravy komunitouV případě chyb nebo zranitelností závisí oprava výhradně na poskytovateli.
- Volatilní podporaVýrobce může upustit od údržby a ponechat zařízení odkryté.
Nadace pro svobodný software (FSF) aktivně propaguje systémy, které se vyhýbají blobům, a doporučuje bezplatné distribuce, jako jsou Trisquel, Parabola a gNewSense. Dokonce rozlišuje mezi bloby firmwaru a jádra a propaguje kampaně za otevřený firmware a BIOS , které eliminují závislosti na proprietárním bootování.
V mobilním sektoru FSF podporuje iniciativy zaměřené na plně open-source telefony. Nedávným příkladem je LibrePhone, jehož cílem je nahradit poslední zbývající proprietární komponenty v projektech, jako je LineageOS, prostřednictvím reverzního inženýrství a vývoje open-source alternativ. První fáze byla financována z darů s cílem důkladně zdokumentovat model telefonu a nahradit uzavřené binární soubory kus po kusu . Výzva není jen technická, ale i právní, a to kvůli přísným dohodám o mlčenlivosti, které chrání dokumentaci čipů od dodavatelů, jako jsou Qualcomm a Broadcom.
Jiné projekty se řídily pragmatičtějšími strategiemi. Například GrapheneOS a LineageOS odstraňují software od Googlu a posilují zabezpečení a soukromí (viz návod na vytvoření vlastní ROM ), ale zachovávají si proprietární objekty blob, aby bylo zařízení použitelné. Nesplňují sice ideál 100% svobodného softwaru, ale nabízejí rozumnou rovnováhu mezi funkčností a kontrolou s nadějí, že posunou toto odvětví k větší otevřenosti.
Android, mobilní hardware a řídicí stěna
Pokud se zamyslíme nad Androidem bez blobů, okamžitě nás napadne Replicant, který se od roku 2010 snaží nabídnout zcela bezplatnou alternativu. Projektu se sice podařilo odstranit komponenty od Googlu, ale narazil na realitu hardwaru: bez oficiální dokumentace byla reimplementace kritických ovladačů nemožná . Proto dnes funguje pouze na starších telefonech s omezenými funkcemi, což je kompromis, který mnoho uživatelů nemůže akceptovat.
Závislost na objektech blob je nejpatrnější u mobilního modemu (základní pásmo), GPU, GPS a fotoaparátu. Tyto komponenty jsou z komerčních a duševních důvodů nejodolnější vůči otevření a bez nich není signál, grafická akcelerace ani slušné fotografie. Prioritou iniciativ, jako je LibrePhone, je proto izolovat a nahradit tyto komponenty, počínaje výběrem zařízení, u kterých je tato práce proveditelná a dokumentovatelná.
Mezitím dochází v tomto odvětví k pohybu. GrapheneOS oznámil spolupráci s významným výrobcem Androidu na rozšíření svého operačního systému nad rámec Pixelu, což byl požadavek, který byl historicky uložen kritérii zabezpečení a aktualizací. I když stále vyžaduje proprietární objekty blob, jeho rozšíření naznačuje, že někteří výrobci začínají brát tyto standardy vážně , s potenciálem, že trh ve střednědobém horizontu přijme otevřenější postupy.
Chromebooky, Coreboot, Libreboot a problém s bloby
Chromebooky a firmware s otevřeným zdrojovým kódem tento problém jasně ilustrují. Google implementoval Coreboot do svých zařízení, ale to neznamená úplnou absenci blobů. FSF těmto notebookům neuděluje certifikaci „respektuje vaši svobodu“, protože stále obsahují proprietární komponenty , zejména v oblastech, jako je GPU a Wi-Fi. Například mnoho karet Atheros funguje bez blobů, ale ne všechny, a už vůbec ne ty nejmodernější; navíc v Chromebookech mohou být moduly Wi-Fi připájeny nebo používat proprietární konektory.
V grafice byla historická situace smíšená. Nvidia se svými čipy Kepler nabízí s open-source ovladačem Nouveau velmi slušné výsledky, včetně manuálního přetaktování jádra a paměti pro obnovení továrních frekvencí. V raných generacích, jako je Maxwell, bylo možné dosáhnout částečného (jádrového) přetaktování, zatímco u jiných přetrvávají určitá omezení . Navzdory významnému pokroku v open-source ovladačích čipy AMD stále vyžadují k fungování proprietární firmware; bez něj je GPU prakticky nepoužitelné.
Pro ty, kteří chtějí používat GNU/Linux na Chromebooku bez spoléhání se na proprietární 3D, se doporučují lehké desktopy jako LXDE nebo Xfce, protože nevyžadují 3D akceleraci. Jedná se o pragmatický přístup, pokud neexistuje žádná bezplatná alternativa s dostatečným výkonem . Změna hardwaru (například Wi-Fi karty v noteboocích s Mini PCIe) však může vést ke ztrátě záruky a na nových počítačích není vždy proveditelná.
Libreboot posouvá tento ideál ještě dále než Coreboot: eliminuje bloby hned od začátku, automatizuje kompilaci a instalaci a poskytuje obrazy ROM připravené k flashování spolu s nástroji, jako je FlashROM a integrovaný GRUB. Jeho cíle zahrnují distribuci pouze svobodného softwaru, usnadnění používání i neexperty, rychlé spouštění, vylepšené zabezpečení a plné možnosti přizpůsobení . Na oplátku podporuje méně hardwaru, a to právě proto, že mnoho systémů se stále spoléhá na proprietární komponenty pro spouštění nebo inicializaci kritických subsystémů.
- Pouze svobodný softwareVyhýbá se proprietárnímu mikrokódu, uzavřené inicializaci videa nebo proprietárním modulům a odrazuje od přidávání komponent, jako je Intel Management Engine.
- Více automatizaceOd kompilace až po instalaci, s uživatelsky orientovanou dokumentací a kanály komunitní podpory.
- Předkompilované ROM: obrázky připravené k nahrání do flash disku, a to i v nestandardních velikostech (např. 16 MiB), pokud to vyžaduje upravený hardware.
- snadné aktualizaceŽádné DRM ani zámky od výrobce; možnost libovolného upgradu nebo downgradu.
- Rychlá odezvaTváří v tvář selháním nebo zranitelnostem komunita reaguje rychle, na rozdíl od typické setrvačnosti proprietárních firmwarů.
Co se týče procesorů, Chromebooky s procesory ARM byly chváleny pro nízkou spotřebu energie a absenci aktualizovatelného mikrokódu, na rozdíl od Intelu. Zmiňují se také pozitivní aspekty, jako je použití open-source softwaru v integrovaném řadiči (EC) u některých modelů . U Intelu se však objevují obavy ohledně kombinace mikrokódu, technologií vzdálené správy, jako je AMT, a přítomnosti subsystému Management Engine, který mnozí považují za neprůhlednou oblast s potenciálními riziky pro soukromí a bezpečnost.
Celkový obraz vede k nepříjemnému závěru: většina uživatelů spouští své počítače s uzavřeným firmwarem plným objektů typu blob a jejich nahrazení vyžaduje odborné znalosti, čas a kompatibilní hardware. Reverzní inženýrství je pomalé, drahé a nejisté, takže pokroky přicházejí ve vlnách a často jsou specifické pouze pro několik modelů.
Nezaměňovat s Blob Storage: cloudové úložiště objektů
Termín „blob“ se v cloudu objevuje také s velmi odlišným významem: Binary Large Object, synonymum pro datový objekt. V této souvislosti je Blob Storage (S3, Azure Blob Storage, Google Cloud Storage) služba pro ukládání a načítání nestrukturovaných dat ve velkém měřítku. Nemluvíme o proprietárních řadičích, ale spíše o souborech a metadatech uložených jako objekty v kontejnerech , přístupných prostřednictvím API, SDK a nástrojů CLI.
Typická struktura má účet úložiště jako jmenný prostor v kontejnerech a v rámci těchto kontejnerů objekty s binárními daty, metadaty a jedinečnými identifikátory. Poskytovatelé nabízejí cenové a výkonnostní úrovně (hot, cool, archive) na základě četnosti přístupu s odolností prostřednictvím replikace a globální dostupnosti.
Mezi nejběžnější případy použití patří publikování a distribuce multimediálního obsahu (obrázky, video, audio) a hosting statických webových stránek (HTML, CSS, JS a obrázky). Slouží také jako základ pro datová jezera a analýzy, ukládá strukturovaná, polostrukturovaná a nestrukturovaná data pro big data a strojové učení . V podnicích funguje jako úložiště dokumentů, PDF a digitalizovaných záznamů.
- Výhoda: elastická škálovatelnost, odolnost díky replikaci, globální dosah, nastavitelné náklady a snadná integrace s analytickými službami.
- Omezení: vyšší latence než blok, jiná sémantika než souborový systém a pomalejší obnova na úrovni souborů.
Integrace Blob Storage do reálných řešení je přímočará: vytvořte nebo použijte účet, vygenerujte kontejner, nastavte zabezpečené přihlašovací údaje a nahrajte objekt s jeho metadaty a zásadami přístupu. Tento pracovní postup funguje se sadami SDK v JavaScriptu, Pythonu nebo Javě a s rozhraními příkazového řádku, jako je Azure CLI nebo AWS CLI . Je to přirozený způsob, jak ukládat datové sady pro umělou inteligenci, podnikové zálohy, statický obsah pro webové a mobilní aplikace nebo propojit ETL kanály s Power BI nebo jinými nástroji BI.
Existují dokonce specializované konzultační firmy, které navrhují zakázkové architektury pro AWS a Azure, kombinující kybernetickou bezpečnost, aplikovanou umělou inteligenci a datovou analytiku. Jejich služby sahají od vývoje softwaru a agentů umělé inteligence až po hardening a dashboardy , s projekty, kde je Blob Storage páteří pro trénovací datové sady, zálohy, statické soubory a škálovatelnou analytiku. Je důležité zdůraznit: toto použití slova „blob“ nemá nic společného s proprietárními bloby v jádře; zde mluvíme o cloudových datových objektech.
Soukromí, zabezpečení a jak se v systému Android orientovat s minimem blobů
Pro uživatele, kteří se zajímají o soukromí a kontrolu, rozumný přístup obvykle zahrnuje výběr zařízení s dobrou podporou komunity, volbu ROM zaměřených na zabezpečení a minimalizaci závislosti na Googlu, kdykoli je to možné. LineageOS a GrapheneOS snižují expozici a posilují systém , i když nemohou eliminovat všechny bloby kvůli hardwarovým omezením. Je zásadní zkontrolovat stav podpory každého modelu a dostupné aktualizace zabezpečení.
Pokud hledáte stolní nebo notebookové počítače s menším počtem proprietárních komponent, je prozkoumání hardwaru kompatibilního s Corebootem nebo Librebootem známou možností, ačkoli výběr je omezený a instalace vyžaduje pečlivou pozornost. Kontrola stavu grafické karty, Wi-Fi karty a bootovacího firmwaru před nákupem zabrání pozdějším překvapením. V prostředích, která nejsou náročná na 3D, pomáhají lehké desktopy jako Xfce nebo LXDE vyhnout se závislosti na proprietární akceleraci.
Je také důležité řídit očekávání: dosáhnout 100% open-source systému Android je dnes extrémně obtížné , takže praktickým cílem je zmenšit oblast uzavřených systémů a zaměřit se na projekty s audity, rychlým aktualizováním a přísnými bezpečnostními zásadami. Komunita již léta prosazuje zpřístupnění klíčových komponent mobilního hardwaru; spolupráce s výrobci bude klíčová pro převedení tohoto tlaku do otevřené dokumentace a ovladačů.
Kromě mobilních zařízení se veřejná diskuse o firmwaru, mikrokódu a neprůhledných subsystémech (jako je Intel Management Engine) právem rozšířila. První software, který se spustí při zapnutí zařízení, je nejcitlivější a jakékoli chyby nebo nedokumentované chování mohou ovlivnit vše, co následuje. Snížení počtu blobů na této vrstvě, pokud je to proveditelné, poskytuje skutečné výhody v oblasti zabezpečení a schopností reakce na incidenty.
V technologických médiích se o tomto přetahování mezi okamžitou funkčností a dlouhodobou svobodou široce píše. Některé redakce poukázaly na to, že projekty jako LibrePhone a pokroky v systémech zaměřených na soukromí vysílají odvětví zprávu: pokud se nikdo nechopí iniciativy, úplná otevřenost se sama od sebe nestane . I když to není ani krátká, ani levná cesta, každá část nahrazená otevřenou komponentou zvyšuje možnost auditu, vylepšování a údržby systému bez žádání o povolení.
Abychom to uzavřeli: v systému Android jsou binární objekty blob cenou, kterou platíme za fungování hardwaru, ale také bariérou, která brání nezávislému auditu a opravám. Dokud se ovladače a firmware s otevřeným zdrojovým kódem nerozšíří, nejlepší strategií je zůstat informovaný, pečlivě si vybírat zařízení a volit projekty se silnou bezpečnostní historií , přičemž vždy rozlišujte mezi „blobem“ jako proprietárním binárním souborem jádra a „blobem“ jako datovým objektem v cloudu – dvěma odlišnými světy, které sdílejí název, ale nikoli význam.
