Všechny velké prohlížeče už podporují WebAssembly

jj, hlavne je potreba docilit toho aby uzivatel fakt nemel ani paru, co ze ten srackoscript vlastne dela.

Ne, je to cesta, aby bylo možno provozovat plnohodnotné distribuované aplikace v prohlížeči.

Jiste, mili useri, zapomente co ste kde cetli nebo slyseli, exe je vyborna pripona a cokoli ji ma, na to kliknete.

Není rozdíl s tím jestli si jeden link v hlaviččce načte škodlivý kód.

Podle mně tedy je. Pokud mám zablokované spouštění JS, tak si hlavička může z linku načítat co chce...
Navíc, co je v linku, můžu alespoň zkontrolovat, když se načte bytecode, tak se to bude muset dekompilovat, a to je o řád složitější...

V případě WebAssembly uživatelé klikat nemusí (ani nemůžou), protože WebAssembly se spouští po načtení stránky automaticky, stejně jako Javascript.

Pěkná blbost, WebAssembly nemá se spouštěním nativních binárek nic společného a běží v sandboxu.

Slova skript a bytecode v prostředí webu/prohlížeče mě znervózňují. Nebude to takové kurvítko pro lidi, co budou chtít škodit? Minimálně ze začátku to bude obsahovat chyby. Kolik lidí to reálně využije? Není lepší, když jsou data se skripty čitelné?

Nevim jak Diskobolos, ale za me tohle zarizujou addony (jo, vim ze pro chrofox je to sprosty slovo). A nektery konstrukce v js jednoduse znamenaj, ze ten js odstreli celej.

Nemluve o tom, ze do citelnyho scriptu se maketaci a dalsi zvirada neodvazej dat zdaleka takovy hruzy, jaky vecpou do necitelny binarky.

A mluvi o bezpecnosti prohlizece ...lol ... odesilani polohy, stavu akumulatoru, idektifikace HW, primej pristup k GPU, ....

Jiste, stejne dobre jako v exe nebo elf. Takze to vlastne bude fungovat stejne jako antivirak, kterej pozna ... co bylo pred mesicem.

Ne, bezpečnost bude znatelně horší. Nyní musel Javascript projít překladačem v prohlížeči. Nově dostane interpret už připravený bytecode. Rozdíl je v tom, že v interpretu jsou nepochybně chyby, díky kterým lze docílit změny chování. Pokud vám bytecode generuje překladač, tak řada z těch chyb nebude problém, protože překladač bude generovat validní bytecode. Pokud ale mohu dodat přímo bytecode, tak ho můžu upravit tak, aby se některá z chyb projevila.

Jinými slovy - interpret bude stále stejně děravý, ale díky tomu, že mohu obejít překladač, je snažší ty díry zneužít. Ubyla nám prostě vstva ochrany tvořená překladačem.

Ostatně Java na tom byla zpočátku (vlastně docela dlouho) stejně. Zkuste se podívat, kolik tam bylo potřeba záplat na chyby "java bytecode vulnerability". Vypadají například takto:

"An attacker can create a new instance of an object without calling the proper initialization method from within the constructor of the created class. This allows an attacker to bypass security checks performed by the Bytecode Verifier to create an instance of a Class Loader object. These objects can be used to allow an untrusted applet to obtain read- and write-access to the local file system or to crash Internet Explorer."

@bez_prezdivky

Ideální by bylo praktikovat oboje, ale je zřejmé, ze dobudoucna ani to nebude stacit ...

To tezko, pokud ten bytekod vznikne z neceho jynyho nez js, tak zpetnej preklad do js, vrati neco naprosto jinyho.

Ne do JS ale do wasm metajazyka s nejakym AST, proste disassembler.

Presne to zapadá do Google ambícií s ChromeOS.....

Ale fuj, kacire klokana upalit, vplist do kola, rozctvrtit ... tohle prece je free, khull, in, a predevsim to neobsahuje vubec ale vazne vubec zadny diry.

BTW: Ted jen asi tak 10 let pockat, nez to bude umet streamovany video (jako ten flash). A za dalsich 15 let se bude vist boj za odstaneni ty neuveritelne deravy veci z povrchu zemskyho.

Hele, kdyz netusis vo cem zvanis tak zalez. Flash umi mimo jiny rtp.

Co si myslíš, že je WebRTP?

Velkou vyhodou je, ze ted muzete v svych aplikacich pouzit spoustu hotoveho C-ckoveho kodu. Treba potrebuji nejakou lepsi matematickou knihovnu tak vezmu C-ckovy zdrojak, prezenu ho do wasm a JS aplikace pak vidi API knihovny a muze s ni pracovat. Treba standardni Math.PI mam jenom na 16 desetin ale FancyMath.PI bude na 64 desetin atd.

Co se tyce bezpecnosti je to sandbox, na disk primo nesahnes, na pamet primo nesahnes, na sit primo nesahnes. Prinejhorsim zhodis browser.

Aby za chvilku neodstranili ten problem, ze z toho cool wasm nikam nesahnes kdyz uz to tam spisujes :-)

Lebo nieje nad to riesit komplenejsiu matematiku, grafiku, vlastne vsetko v browsery pomocu js. To je proste ta jedina sprvna a najoptimalnejsia cesta na ktoru sme prisli po desatrociach vyvoju sw.
Zacinam s laskou spominat na obavy z Y2K. Oproti tomu co sa teraz deje to bol taky pekny joke.

No ono buffer overflow chyby a rozne exploity su by design o tom ze si sahas na tend disk nepriamo. Rozhodis sandal browseru a potom lezes kam potrebujes bez pardonu a opytania.

Mozno pred 20 rokmi :-) Dnes su OS uz trosku inde. V macOS nerozhodis sandal, vo win10 nerozhodis sandal a zrejme aj Linux to uz ma dajak poriesene. Tym nechem povedat, ze je to nepriestrelne ale aj keby taka chyba bola tak browsery su updatovane denne a OS next business day.

Ano, vidíme to denně ....

jj, je to poriešené lepšie než kedy predtým... preto počet CVE v roku 2017, ktorý ešte neskončil, už je 2x vyšší než za celý minulý rok:

https://www.cvedetails.com/browse-by-date.php

Tak to jiste, viz o fous vejs. Pust si ten exac, dyk je to bezpecny, mas prece ten operacni system no ne?

Ale jo, pro nektery tupejsi ... pseudokod ...

reknemez, ze zavolam neco jako x = new(y) ... reknemez, ze browser to !interpretuje! jako #FE56AC78 mno a co se asi tak stane, kdyz mu zvenku, v tom uzasnym bytekodu ... poslu #FF56AC78. Jo aha, to nikdo nevi. Protoze az do ted to nastat nemohlo, takze to nikdo neresil. Takze muze nastat naprosto cokoli, od neskodnyho padu browseru po ziskani kontroly nad OS.

Hlavne ten bytecode definovany v wasm nema nic spolecneho se skutecnou interpretaci ci prekladem do nativniho kodu,ktery browser interne dela... toto je ekvivalentni podpore dalsiho jazyka jako js,ktery je ale navic extremne jednoduchy na zpracovani/preklad.

Zadny jednotny interni bytecode neexistuje mezi prohlizeci.

To ted stranky budou tezit bitcoiny 4x rychleji nez v javascriptu ze ? :-)

Proč zdejší skeptiky kamenujete? Nemusím mít přece znalosti SW inženýra, abych věděl, že přidávání (složité) funkcionality vede k zanášení chyb a rizik do budoucna. Java a flash v browseru byly problémem po celou dobu své existence a taky na to dojely. Chyby a díry v jejich implementaci se řeší/využívají dodnes. A myslet si, že sandbox vše spasí je taky mýlka. Je to další vrstva, která může a bude obsahovat chyby/slabiny (tím spíš, že bude x implementací pro jednotlivé browsery). A co se týče souhlasů, to tu vůbec neřešme - znalý uživatel si to pohlídá a BFU všchno odklikne. Rozumějte, nikdo nebrojí proti pokroku. Když to ale nepřinese nic nového (tj. nic co by neuměl samotný JS), tak je to vzhledme k výše uvedenému napováženou. Můžeme diskutovat o výhodě rychlosti samotného vykonání kódu skriptu. Jenže kompilace samotného kódu JS vs běh bytekódu v sandboxu se dle mého +/- vyrovná - při běžném použití. Jestli ale někdo chce dělat obrovské (skoro nativní) aplikace v browseru (aby využil rychlost bytekódu), tak to nepochopil princip vývoje aplikací v prohlížeči (otevřte si taskmanager/ps a podívejte se na režii prohlížeče). Z mého pohledu tedy argument o rychlosti padá. Osobně tam nevidím žádný další zásadní benefit.

Ten nejzasadnejsi benefit jsou HRY :-D Playstation 5 a XXXBoXXX budou jiste cloudove s minimalnim OS a bez disku (neco na styl AppleTV). A ty hry pobezi na forknutem chrome prave pres wasm. Jsou proste spousty kodu v C-cku ci jinych synchronnich jazycich a prepisovat je do asynchronniho JS nemusi byt vzdy jednoduche. A nac vubec, kdyz to staci skomiplovat pro "procesor" s "instrukcni sadou" wasm.

OK, v herním průmyslu se točí spoustu peněz a může to být argument. Na druhou stranu si myslím, že pro náročné hry není prohlížeč určen (možná že takový trend je, nevím). Tetris ano, Call of duty 5 rozhodně ne. Navíc přepsat existující kód Cčka nebude tak jednoduché, jak to prezentujete - specifický způsob práce s periferiemi (a jiné, např. omezení plynoucí ze sandboxu) budete muset přepsat do "wasm". To nebude žádná sranda.

nejake demo abys videl ze wasm + webgl je pohoda:

https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html

a Unreal Engine 4 uz nejaky ten patek podporuje target wasm+webGL

https://www.bit-tech.net/news/gaming/pc/epic-unreal-engine-4-16/1/

To jsi mi dal, FF na 6GB RAM:
Downloading (32.15s) 125MB
Building shaders (15.49s)
Compiling WebAssembly...

Btw webgl není diretx (když už jsme u toho snadného přepisování kódu v C). Ukázka pěkná, celé to pozadí odporné. Opravdu je tento typ úloh vhodný pro prohlížeč? Připadá mi to jako Boing 737 co má na zádech raketoplán Discovery na denních letech Paříž - Bombaj a zpět.

Překladače JS v prohlížečích tu už jsou a fungují dobře. Teorie formálních jazyků, překladače a interpretace udělaly ze skriptovacích jazyků plnohodnotné nástroje vývoje. Na určitý okruh problémů je to vhodný nástroj. Kdyby autoři řekli, že parsery/kompilátory JS dají pryč a nahradí bytekódem, tak budete mít pravdu. Navíc, lexikální/syn­taktický analyzátor Vám (mimo jiné) zajišťují/hlídají validitu/strukturu JS skriptu. Jinými slovy, pustí Vás jen tam, kam budouch "chtít". To je v prostředí prohlížečů a internetu zásadní benefit. V bytekódu tohoto v takovém rozsahu nedocílíte - musíte mít sandbox.

Argument o teoriích formálního zprac. jazyků o příspěvek výše. Myslet si, že programátoři Adobe/Oracle neřešili bezpečnost jinak, než vývojáři Google/Mozilla, je poněkud zcestné. Chyby se dělají i v OS. Ano, přijde se na ně třeba dříve, na druhou dáváte opravdu vynikajícím vývojářům se zápornou motivací nástroj pro hledání zadních vrátek. Věřte mi, že oni ty chyby najdou tam, kde průměrný OS vývojář nebude mít ani tušení. Podívejte se na security logy velkých OS projektů.

Vyvratitelné nesmysly - ano, máte pravdu. Jenže nemůžete lidem upřít jejich podvědomé obavy z podobných technologií. Já osobně si myslím, že jsou oprávněné.

Ad děrné štíty - to je obecný argument, když už není co říct. Já si třeba myslím, že vynaložené úsilí se mělo dát jinam - na kvalitu jádra samotného prohlížeče. Prostě nervat do něj za každou cenu kdejakou technologii/fičuru. Např. stále nedokážu pochopit, proč spotřebovává můj spuštěný FF v poslední verzi ve správci úloh 5,3 GB RAM. Nehraju hry, semtam konzumuju a především vyvíjím obsah (cca instalovaných 5 doplňků). To je opravdu stojí takovou režii? Musíme mit v operačním systému daší pseudo-operační systém (prohlížeč)? Z části chápu argumenty proč ano, ale také vidím ty nevýhody, rizika. Proto jsem zpátečník?

Srovnávat implementace Angular, React s aplikacemi typu unreal je blbost. To je asi takový rozdíl jako mezi vzduchovkou a dělem ráže 205mm. Mě nevadí implementace JS FW, které jsou postavené na interakci s DOMem a zajišťují onen dojem nativní aplikace - to je OK.
Mě vadí, že z prohlížeče se dělá neco co není - operační systém. Objevování novinek v IT se děje periodicky každých 15/20 roků. Za 10 roků se zjistí, že je to chybný krok. Z prohlížeče buď vznikne samostatný operační systém (google), nebo se začnou prohlížeče vracet k původní myšlence (jednoduchost).
Složitost systému dosáhne své meze a je motivací ke změně. Takto to funguje ve všem. Mě jenom udivuje, že současní vývojáři prohlížečů si toho jaksi nejsou vědomi a s klapkami na očích tlačí káru ke srázu rychleji, než by museli.

Souvisi nejak nasazeni WebAssembly s tim, ze nektere weby zacali vyuzivat klientske stanice k tezbe cryptomen?