Portál AbcLinuxu, 1. května 2025 17:32
Byla vydána verze 6.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí HTML, CSS a JavaScriptu Electron (Wikipedie, GitHub). Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Tiskni
Sdílej:
Tak samotné GUI bývá typicky jedno-vláknové a všechny GUI události se odbavují v jednom. Ale běžně jde pouštět vlákna na pozadí, která něco provedou, a pak předají výsledek do GUI, kde se to synchronizuje, události se poskládají do jedné fronty a postupně provedou/vykreslí.
A všechno to jsou pomalé jednovláknové šmejďárny s GUI jak omalovánky, které nezapadá do systému.Ale na druhou stranu zase aspoň zabíraj 250 MB na disku.
BTW: dřív měly prohlížeče možnost spuštění v „aplikačním režimu“, kdy otevřeli jedno okno s jednou stránkou bez nějakých dalších ovládacích prvků a v samostatném profilu. Proč se nepoužívá tohle a má každý potřebu balit ke své aplikaci i celý prohlížeč? Taková aplikace by pak mohla mít jen pár kilobajtů a nemusela by se ani instalovat.
To první by bylo řešitelné – stačí mít v tom balíčku metadata, která řeknou, kam aplikace chce mít přístup – a při instalaci nebo spuštění to potvrdíš. Asi by k tomu mělo existovat samostatné běhové prostředí nezávislé na prohlížeči – ale pořád může být v systému jen jednou a ne přibalené ke každé aplikaci.
To druhé je problém, úpadek no…
Mozilla kvôli bezpečnosti úplne zahodila XUL
Firefox má podľa mňa navrch vďaka Rustu, tak možno raz sa dočkáme nejakej obdoby XUL.XUL je nebezpecny by design, protoze bezpecnost nijak koncepcne neresi IIRC, takze jazyk, ve kterem je to implementovane to nezmeni, ani v nejmensim.
Google sa rovnako bráni spojiť prehliadač a natívne aplikácie dokopyA je to rozumne rozhodnuti, protoze propojit to je idealni cesta, jak udelat diru do systemu jako vrata. Nekteri si mozna vzpomenou, jak spektakularne se toto propojeni nepovedlo s ActiveX, ... a pritom to na papire byl tak hezky napad.
IIRC problém s XULem byl hlavněv tom, že byl pomalý - příliš vyžadoval marhsalling dat atd.Toto je opet zcela ortogonalni problem. Navic nevim, jak moc je realny ve svete, kde nekteri povazuji Electron za dobry napad. Hlavni problem XUL (z pohledu bezpecnosti) je ten, ze pluginy nejsou nicim omezene (IIRC, je to nejaky patek, co jsem se na to dival), a kazdy plugin si muze prizpusobit prohlizec podle svych predstav, coz je super vec, pokud mas nad tvorbou pluginu kontrolu. Pokud tu kontrolu nemas, vznika ti jednak bezpecnosti peklo a jednak jakykoliv zasah do prohlizece muze rozbijet out-of-tree pluginy. Poznamka na okraj. Trosku to ukazuje, jak by asi skoncil bystroushaakuv utopicky objektovy svet, o kterem tu nekolikrat psal.
Podle mého je lepší bezpečnost řešit na úrovni operačního systému1 pomocí SELinuxu, AppArmoru kontejnerů s omezenými oprávněními atd. Tzn. aplikace sice poběží pod daným uživatelem, ale nemá přístup ke všem jeho zdrojům (soubory, síť, sokety např. ssh-agenta atd.). Protože ono i když to běhové prostředí bude napsané v něčem „bezpečném“ jako Rust, stejně v tom můžou být chyby. Oproti tomu to řešení na úrovni OS má menší povrch, na který lze útočit, stojí na principu, že vše co není povolené, je zakázané, a dá se to napsat jednou a pořádně otestovat.
Případně by to šlo řešit i primitivním způsobem tak, že by každý reálný uživatel v systému měl několik doplňkových uživatelských účtů s omezenými právy, pod kterými by si mohl pouštět méně důvěryhodné procesy. Takže by stačilo mít protokol pro komunikaci s tímto podprocesem a ty pluginy by pak klidně mohly být obyčejné binárky, které si přes STDIO nebo nějaký soket s hlavním procesem posílají zprávy.
[1] jasně, v prohlížeči s mnoha současně instalovanými moduly si to musí řešit prohlížeč, ale teď se bavím o tom běhovém prostředí, viz výše, ve kterém se spouští právě jedna aplikace
Podle mého je lepší bezpečnost řešit na úrovni operačního systému1 pomocí SELinuxu, AppArmoru kontejnerů s omezenými oprávněními atd.To se přece nijak nevylučuje, naopak, to se vhodně doplňuje. Nehledě k tomu, že ten OS a jeho userspace komponenty taky musí v něčem být napsané...
31.7.2019 19:59
31.7.2019 20:33
2.8.2019 10:02
2.8.2019 20:56
2.8.2019 21:49
php.ini – taky bys asi byl klidnější, kdyby ten skript neběžel pod rootem a omezená práva měl na úrovni OS.
[1] jasně, v prohlížeči s mnoha současně instalovanými moduly si to musí řešit prohlížeč, ale teď se bavím o tom běhovém prostředí, viz výše, ve kterém se spouští právě jedna aplikacePro kontext: uz dve urovne diskuze pisu o XUL, ktere je blbe by design, ... a AppArmor nebo SELinux ti tu opravdu nepomuzou.
Podle mého je lepší bezpečnost řešit na úrovni operačního systémuIMHO nejlepsi je resit bezpecnost na nejblizsim miste, kde to jde, jinak hrozi, ze ti budou vznikat mista, ktera lze potencialne zneuzit.
Takže by stačilo mít protokol pro komunikaci s tímto podprocesem a ty pluginy by pak klidně mohly být obyčejné binárky, které si přes STDIO nebo nějaký soket s hlavním procesem posílají zprávy.Jinymi slovy, musis mit definovane rozhrani. Velka vyhoda pluginu postavenych na XUL je/byla v tom, ze muzou podstatnym zpusobem menit treba i vzhled prohlizece, rozsirovat jeho chovani zpusobem, ktery puvodni tvurce prohlizece nepredpokladal. Velkou nevyhoda pluginu postavenych na XUL je/byla v tom, ze muzou podstatnym zpusobem menit treba i vzhled prohlizece, rozsirovat jeho chovani zpusobem, ktery puvodni tvurce prohlizece nepredpokladal. Takze prohlizece se vydaly cestou web extensions, coz vede k tomu, ze sice prohlizec bude bezpecnejsi, ale nektere veci, proste nepujdou udelat, protoze to rozhrani to nepovoli.
Případně by to šlo řešit i primitivním způsobem tak, že by každý reálný uživatel v systému měl několik doplňkových uživatelských účtů s omezenými právy, pod kterými by si mohl pouštět méně důvěryhodné procesy.To je takove docela humpolacke reseni a v praxi pouzitelne maximalne na osobnim pocitaci s jednim uzivatelem. Systemovejsi reseni by bylo mit capability-based OS.
Proč se nepoužívá tohle a má každý potřebu balit ke své aplikaci i celý prohlížeč?Electron není pouze prohlížeč, ale je to Node.js + prohlížeč. V tom je celá ta pointa. (Neříkám, že to tak je dobře, jenom vysvětlení.)
Já vím, myslel jsem tím obecně to běhové prostředí. U Javy nebo Pythonu, Perlu, PHP atd. taky přece není normální a správné ke každé aplikaci to běhové prostředí přibalit (byť to někteří dělají). Aplikace je pak malé JARko nebo skript a spustím si je ve svém běhovém prostředí, které už mám nainstalované (a ve kterém mám třeba bezpečnostní aktualizace spravované mojí distribucí).
Když to vezmu do extrému, tak to už by se aplikace mohly distribuovat jako virtuálky pro KVM/Qemu, které by obsahovaly nějaké minimální jádro a Xka/Wayland a skrze VirtIO by tam byly protažené kanály pro práci např. s místními soubory nebo se sítí. Bylo by tam jasně deklarované, kam má aplikace mít přístup a víc by nemohla, protože by ji tam nepustil hypervizor. Nakonec by mi to přišlo lepší (a pro některé aplikace dobrá volba) než přibalovat k aplikaci prohlížeč+Node.js, což si podle mého bere z obou světů to horší – je to velké, neaktualizuje se to, uvnitř můžou být děravé knihovny a bůhvíco a zároveň je to běžná desktopová aplikace, která může vlastně cokoli (omezit by se musela dodatečně skrze nějaký Flatpak, Snap, AppArmor, atd.).
Node.js + prohlížečMe na tom strasne dojima, ze to jsou dva JS enginy, ktere si mezi sebou vykladaji pomoci HTTP a jeden z nejkomplexnejsich baliku kodu, ktery se v dnesnich systemech pouziva a ktery implementuje nemale mnozstvi standardu, se pouziva jen jako renderovaci jadro, protoze banda hipsteru umi jenom HTML + JS. Zajimave je, ze v minulosti byly pokusy (NeXT, Apple) renderovat uzivatelske rozhrani pomoci postscriptu, coz mi prijde jako lepsi reseni nez HTML, ale z nejakeho duvodu se to nechytlo... tak si to ted musime vyzrat do horkeho konce s HTML.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.