Vědci z univerzity La Sapienza v Římě vyvinuli systém, který dokáže identifikovat jednotlivce pouze na základě toho, jak narušují signály Wi-Fi. Autoři tuto novou technologii nazvali WhoFi. Na rozdíl od tradičních biometrických systémů, jako jsou skenery otisků prstů a rozpoznávání obličeje, nevyžaduje tato metoda přímý fyzický kontakt ani vizuální vstupy. WhoFi může také sledovat jednotlivce na větší ploše než kamera s pevnou polohou; stačí, je-li k dispozici Wi-Fi síť.
SuperTux (Wikipedie), tj. klasická 2D plošinovka inspirovaná sérií Super Mario, byl vydán v nové verzi 0.7.0. Videoukázka na YouTube. Hrát lze i ve webovém prohlížeči.
Ageless Linux je linuxová distribuce vytvořená jako politický protest proti kalifornskému zákonu o věkovém ověřování uživatelů na úrovni OS (AB 1043). Kromě běžného instalačního obrazu je k dispozici i konverzní skript, který kompatibilní systém označí za Ageless Linux a levné jednodeskové počítače v ceně 12$ s předinstalovaným Ageless Linuxem, které se chystají autoři projektu dávat dětem. Ageless Linux je registrován jako operační
… více »PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
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é...
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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.
Tiskni
Sdílej:
