Hlavní navigace

Vlákno názorů k článku WebAssembly slibuje podstatné zrychlení webů, konec JavaScriptu se ale nekoná od Ondřej Žára - Nikoliv. To se právě týká druhého bodu, který jsem...

  • Článek je starý, nové názory již nelze přidávat.
  • 29. 6. 2015 19:09

    Ondřej Žára (neregistrovaný)

    Nikoliv.

    To se právě týká druhého bodu, který jsem popisoval.

    Aby mohl kód ve WebAssembly (a nikoliv nezbytně jen ten, i běžný ručně psaný JS) komunikovat s wasm-verzí těchto knihoven, bude nutné takovou jejich variantu naimplementovat.

    A jak je uvedeno v citovaném textu, " On the Web, they utilize Web APIs (for example, OpenGL is executed on WebGL, libc date and time methods use the browser's Date functionality, etc.)." To je logické, protože těžko zkompiluji řekněme knihovnu SDL do wasm tak, aby využívala jiná než webová API (canvas, webgl, web audio) - neboť bude vykonávána prohlížečem a tak se k jiným API prostě a jednoduše nedostane. To, že zdrojový kód nebude dostupný ve formě JS, ale jako binární serializace AST, je jen transportní technikálie.

    Dokladem tohoto chování je například právě https://github.com/WebAssembly/v8-native-prototype - implementace dekodéru WebAssembly, která "jen" přeskočí tvorbu AST ze zdrojového kódu. Výsledný strom operací je opět vykonáván tváří v tvář standardním JS API, která ve V8/Chrome runtime existují. Nevidím tak v této technologii nikde prostor pro přístup řekněme k FFI nebo něčemu obdobnému, dle popisovaných katastrofických scénářů.

    WebAssembly je vylepšení syntaktické a transportní vrstvy. Nezasahuje do sémentiky, bezpečnosti ani rozhraní jazyka.

  • 29. 6. 2015 18:13

    Miloslav Ponkrác

    Jak je libo: https://github.com/WebAssembly/design/blob/master/CAndC%2B%2B.md

    „WebAssembly applications can use high-level C/C++ APIs such as the C and C++ standard libraries, OpenGL, SDL, pthreads, and others, just as in normal C/C++ development. Under the covers, these libraries implement their functionality by using low-level facilities provided by WebAssembly implementations. On the Web, they utilize Web APIs (for example, OpenGL is executed on WebGL, libc date and time methods use the browser's Date functionality, etc.). In other contexts, other low-level mechanisms may be used.“

    Jinak řečeno, pokud bude ve WebAssembly jediná bezpečnostní díra, tak je to další průstřel tankem do počítačů a jejich bezpečnosti. Pootevřená Pandořina skříňka. Ale jistě se mi dostane ujištění, že tam nikdy žádná chyba nebude.

    Za mě, WebAssembly nepotřebuji, stejně tak bych rád, aby existoval web browser, který by byl zaměřen na bezpečnost. Zatím mám dojem, že web browser je rok od rok čím dál větší trojský kůň v počítači, a s WebAssembly se jen zvětší počet útočníků v trojském koni ukrytém.

  • 29. 6. 2015 14:15

    Miloslav Ponkrác

    Já považuji už současné možnosti HTML5 a JavaScriptu za bezpečnostní riziko, které se nikdy nemělo pro browser stát.

    Nicméně prohlédl jsem si design WebAssembly (https://github.com/WebAssembly/design) a mimo jiné je tam jako možnost přímé volání C/C++ knihoven z WebAssembly, což jim mimo jiné dává přístup prakticky k celému operačnímu systému a celému API hostitelského systému.

    Jestli toto je „identický přístup jako JS“, pak zřejmě je to nějaký okrajový význam slova „identický“.

    Kromě toho podle datumů v projektu se jedná o velice čerstvý projekt, na kterém ještě ani nezaschl inkoust na prvním souboru. Takových předpovědí a tehcnologií ve stylu „technologii, kterou jsme začali dělat od včerejška zcela změní a ovládne svět“ bylo už víc, než atomů ve vesmíru a dnes po nich pes neštěkne.

    Takže vlastně ani není jasné, co to je, co to bude umět, kam se to vyvine, pokud to neuhyne na úbytě což je nejpravdědpobnější.

    Můj soukromý názor je, že webový browser je zahnojen technologií více, než dostatečně. Na bezpečnost se v browseru nedbá a jednou z toho bude velmií bolet svět hlava.

    Dejte na mě, WebAssembly bude jedna z těch věcí, o které velmi brzy přestaneme slyšet a nikdo si ani nevzpomene. A bude to jedině dobře.

  • 30. 6. 2015 8:41

    fd (neregistrovaný)

    Rekl bych, ze by jste si to mel precist jeste nekolikrate, a pak mozna pochopite, ze prave o to, aby se nic znova implementovat nemuselo, jde v prvni rade.

  • 2. 7. 2015 11:17

    Anonymous (neregistrovaný)

    Presne tak. Kdyz uz chci mit "webovou" stranku s vykonavanym kodem, at se to deje podle standardu html. Prijde mi (uz hodne dlouho), ze z weboveho prohlizece vznika novy operacni system, takze budu mit operacni system, v nem spustim webovy prohlizec, ktery bude pro webove aplikace operacnim systemem.
    A jak to cele jde dohromady s tim, ze se stale vice prosazuje to, ze se vypocetni vykon presouva nekam na servery? To by spise melo vest k tomu, ze se cela staticka "webova stranka" vygeneruje na serveru a prenese do klienta a pri kazde akci pregeneruje znova.

  • 29. 6. 2015 14:47

    Ondřej Žára (neregistrovaný)

    Myslím, že bude nutné si ty dokumenty pročíst o něco zevrubněji.

    Nikde se nemluví o přímém volání libovolných systémových knihoven. Spolupráce s kódem C/C++ je zmiňována:

    1) na úrovni kompilace C/C++ do WebAssembly,

    2) na úrovni modularizace knihovního kódu tak, aby "knihovna1.wasm" mohla využívat API "knihovna2.wasm". U obou souborů se samosebou jedná o zdroje stažené z webu, opět v rámci sandboxu prohlížeče a bez přístupu k hostitelskému systému.

    Pokud je někde v design dokumentech napsáno něco o možnosti přímého volání systémových knihoven (u nich je vlastně jedno, v jakém jazyce byly napsány, že?), pak bych byl velmi rád, kdybyste mi tu část mohl konkrétně odkázat.

  • 29. 6. 2015 13:55

    Ondřej Žára (neregistrovaný)

    WebAssembly ovšem nepřináší nic nového na úrovni přístupu k HW. V tomto směru je na tom identicky, jako JS či asm.js.

    Tvrzení "Cim rychlejsi neco ma byt, tim bliz to musi mit pristup k HW" mi přijde velmi silné. Troufl bych si tvrdit, že přestože je možné získat výkon bližším přístupem k hardware, rozhodně to není *jediný* způsob, jak něco urychlit.

  • 29. 6. 2015 13:51

    fd (neregistrovaný)

    Cim rychlejsi neco ma byt, tim bliz to musi mit pristup k HW a tim vetsi rizika (a deravost) to sebou nese. Nakonec, proc nenabidnout browseru exe (nebo jiny primo spustitelny format), staci browser naucit, ze to ma bez reci spustit.

    Spousta lidi si vypina i js - at uz z duvodu zvyseni bezpecnosti nebo snizeni "nasralinu" v krvi. Zkratka a jednoduse, neprijde mi jako dobry napad michat dohromady web a aplikace. Predevsim kvuli bezpecnosti BFU. Tak jako ctenar novin neocekava, ze mu noviny odemknou byt, neocekava BFU, ze mu web ukradne fotky z disku.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).