Názory k článku
Mozilla, Intel, Red Hat a Fastly formují Bytecode Alliance pro běh WebAssembly všude

To oznámení je psané takovým manipulováním stylem. Chápu to tak, že chtějí distribuovat balíčky ve formě bytekódu a bezpečnost se má řešit jakýmsi sandboxováním modulů.

13. 11. 2019, 09:19 editováno autorem komentáře

Zatímco běžně se soft distribuuje jako nativní binárka a bezpečnost se neřeší ani tím sanboxem.

13. 11. 2019, 09:38 editováno autorem komentáře

Běžně se knihovny distribuují ve formě zdrojových kódů, nikdo netvrdí, že je to bezpečné.

Nikoli, knihovny nativních aplikací, které používáte na počítači, se distribuují ve formě binárek. To, že máte vedle binárky k dispozici i zdrojové kódy, je jiná věc – a u WebAssembly to může být úplně stejně. Distribuce ve formě zdrojových kódů je běžná např. v Gentoo nebo Linux From Scratch, ale na Windows, Macu i většině linuxových distribucí se distribuují už přeložené binárky.

já to srovnávám se systémy jako npm a pypi. Tam se buildí lokálně, nebo alespoň existuje ta možnost.

Nehodnotím Bytecode Alliance, jen to oznámení. Kdyby ho napsali stručně a bez obrázků, působilo by důvěryhodněji.

Zatímco běžný soft si pouštím sám na své vyžádání a pod svým dohledem, jak to bude s bytecode někde na webové stránce? Budu mít možnost revize zdrojového kódu (třeba jak se o to snaží debian s reprod buildy)? Budu moci ovlivnit jeho puštění?

Nebude. Jedná se o webassembly mimo prohlížeč. Na webové stránce je to právě bezpečné, prohlížeč je sandbox.

Jakým dohledem? Sledujete jaké soubory to čte, sludejete sharkem jaké data to odesílá? Snapshotujete disk a kontrolujete změny v FS proti původnímu snapshotu?

Na webu máš problém už teď s JavaScriptem (který pokud je minifikovaný a třeba i obfuskovaný, tak se taky analyzuje těžko). Půlka webů bez JS nefunguje a nic než to spustit ti nezbývá.

web nemá k ničemu citlivému přistup, pokud nevyplníte formulář citlivými daty

Webassembly se nedostane dál než javascript, nešáhne si na soubory, ... je to něco jako zkompilovaný javascript do bytekódu. Nechci kecal ale wasm se asi načítá přez javascripit takže zakázáním javascriptu se zakáže i wasm.

Tak rychlej a ani konec to nebude. Ale na 90 procent se zde budou forky.

1. Hadam sa dozijem obdobia, kedy sa prestanu zneuzivat webove technologie na desktope (uz tu mame neskutocne hrozny Electron).
2. Ja by som bol radsej keby dana Aliancia zatlaci na vyvoj dalsej funkcionality WebAssembly ako pristup k domu a tym zrusi monopol javascriptu na webe.
3. Sandboxyng sa nerovna bezpecnost. Casto sa stava, ze prinesie viac komplikacii pre serioznych vyvojarov ako pre tych, co by vam chceli skodit, lebo ti si najdu cestu, hoci nebude fungovat u vstekych.

"1. Hadam sa dozijem obdobia, kedy sa prestanu zneuzivat webove technologie na desktope (uz tu mame neskutocne hrozny Electron)."

nevypadá to tak, popularita elektronových aplikací roste.

"2. Ja by som bol radsej keby dana Aliancia zatlaci na vyvoj dalsej funkcionality WebAssembly ako pristup k domu a tym zrusi monopol javascriptu na webe."

v čem to bude jiné než současné transpilery?

14. 11. 2019, 09:31 editováno autorem komentáře

"nevypadá to tak, popularita elektronových aplikací roste."
Zial exponencialne rastie aj zratie RAM, velkost isntalaciek, znizuje sa responzivita programov.
Ja chapem, preco si ho niektori deveopery vyberaju, ale pre pouzivatela vyhody neprinasa.

"v čem to bude jiné než současné transpilery?"
Tranpilery stale narazaju na to, ze je pod nimi javascript, ze sa ti moze stat ze v jazyku co ani nepozna NULL ti vyhene undefines zo strasnou chybou. Ak sa nebyvime len o supersete javascriptu (ako Flow alebo typescript) tak aj na vykon.
Ked sa bavime o prenosilnosti, tak je stale problem vyvjat pre vsteky browsre, lebo kazdy implementuje ine featury a niektore dropne (v tomto je Chrome majster), takze ostatni musia dohanat co si Google vymsli. Takze mas na jednej strane roztiepenost JS enginov a transpilerov ci babelu na druhej strane mas jednoduchu VM na interpretaciu bytecodu a vsteky ostatne jazykove a runtime featury si uz riesi samotny prekladac do bytecodu.

Podla mna by to prinieslo jednoduchsiu konsolidaciu a stabilitu medzi prehliadacmi a sucasne vyvojaom slobodu.

"Tranpilery stale narazaju na to, ze je pod nimi javascript, ze sa ti moze stat ze v jazyku co ani nepozna NULL "

to je na kompileru, aby to poznal, webassembly bytekód také nemá typovou kontrolu.

14. 11. 2019, 11:00 editováno autorem komentáře

>to je na kompileru, aby to poznal, webassembly bytekód také nemá typovou kontrolu.
Ale jazyk nad nim uz ano. A kedze ely modul je pod kontrolou tohto jazyka....

> Tranpilery stale narazaju na to, ze je pod nimi javascript, ze sa ti moze stat ze v jazyku co ani nepozna NULL ti vyhene undefines zo strasnou chybou.

Javascript NULL samozřejmě "pozná".

A nevím, jaký je rozdíl mezi " undefines zo strasnou chybou" a třeba Javovou NullPointerEx­ception.

"Javascript NULL samozřejmě "pozná"."
"A nevím, jaký je rozdíl mezi " undefines zo strasnou chybou" a třeba Javovou NullPointerEx­ception."

V tom, ze javascript ma plno nepeknych vlastnosti, ktore presakuju do prekladaneho kodu (null/undefined, volanie veci co nejstvuju, runtime chyby, porovnavanie,...).

Skusal som vela prekladacov do JS, fable, Elm, TypeScript, Flow, ale pri kazdom presakuje javascript vysie a neumoznuju tak vyuzit plny potencial jazyka. K tomu nechcem mat len prekladac do nedebugovatelneho javascriptu, chcem mat plnohodnotny jazyk a slobodu jeho vyberu. Co WebAssembly umozni.

Jdes s tim pozde. V Rustu uz se treba docela slibne rozjizdi pouzivani webassembly pluginu v nativnich programech. Ta technologie neni spatna a webova je v zasade jenom podle nazvu.

Myslíte projekt Watt ( https://github.com/dtolnay/watt )? Pokud ano, tak bych tomu úplně webassembly plugin neříkal. Pokud to chápu správně, tak se to používá pouze při kompilaci a výsledná binárka WASM runtime vůbec neobsahuje.

Ne, myslim https://medium.com/wasmer/executing-webassembly-in-your-rust-application-d5cd32e8ce46