Názory k článku
Všechny velké prohlížeče už podporují WebAssembly
-
j (neregistrovaný)
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, ....
-
strepty (neregistrovaný)
Ale je aj bytecode. Vo Windows existuje managovany a nemanagovany C++, ten prvy ma bytecode ten druhy nie a skompiluje sa na strojovy kod. Nic to nemeni na tom ze nikto nema potuchy co je v kode telemetrie napisane, ci uz je to kod managovany alebo nie. Kazdy velky soft pod Windows je teraz pisany v managovatelnom kode a nemate sancu vykradnut ich napady lebo to je zlozite.
-
Aha, ty mluvíš o obskurním managed C++. Tak to tě mohu uklidnit, to se tohoto článku netýká, snad tě zmátlo, že je tam použito slovo bytecode.
A obecně - ani kompilace do strojového kódu ani do bytecode není obecně žádnou zárukou toho, že tomu nikdo neporozumí. To že jsi to nepochopil ty neznamená, že to nedovede nikdo další, není to ekvivalentní jev.
-
strepty (neregistrovaný)
"obskurním managed C++. " ak sa Vam nepaci managovane C++ (neviem preco obskurne, bezne sa pouziva) co budete robit ked uvidite C kompilatory pre WebAssembly.
Nie nepisal som o sebe. Ja som pisal ze nikto nevykradol napady v kodoch a z toho som vyvodil ze kody nikto nevedel rozlustit. Alebo poznate konkretny opak spetneho inzinierstva? -
Pokud se běžně používá, tak máš patrně na mysli C++/CLI?
Co myslíš tím "vykrást nápady v kódech"? A jak víš, že to nikdo neudělal? Konkrétní opak zpětného inženýrství najdeš na jakémkoli warez fóru. Je běžné, že populární programy s komerční ochranou jsou cracklé během pár dní a to se nejedná o managed, ale stroják, kde je přímo záměr, aby to cracknout nešlo. Vypadá to, že máš poněkud přehnané představy o složitosti kompilovaného kódu.
Mimochodem čas od času se hrabu ve strojáku x86, není to pro každého, ale ani to není nepřekonatelné. Proti tomu je dekompilace .net nebo JVM bytecode vyloženě triviální. A wasm nebude o nic složitější. -
strepty (neregistrovaný)
"cracknout nešlo" Napriklad taky Windows 10 som este craknuty nevidel. Najst jednu podmienku a prepisat ju na negaciu je jedna vec a zistit ci v kode nie je napriklad trojsky kon je vec uplna ina. Oproti tomu vykradnut funkciu napriklad na doostrenie obrazka musi byt hracka, keby to zistili autori tak by boli sudy a bolo by okolo toho halo, ale take veci sa nedeju, a moj osobny nazor je ze taku uroven porozumenia kodu uz ani ludia nedosiahnu.
-
lol2 (neregistrovaný)
nerob zo seba sasa ked tomu nerozumies. Svojho casu ked sme pravadzkovali privatny wow server tak sme cez IDA disasemblovali wow.exe a hladali v nom ako v blizzarde poprehadzovali bajty v response packetoch.
Neviem co do toho tahas nejaky windows 10? Ostatne zrovna crackov na windows najdes 4 prdele a mozes si rovno vybrat ktorym smerom prdele to chces cracknut.
Za dalsie - heuristika ti asi nic nehovori, pritom sa v AV pouziva dobrych 30 rokov. WASM bude pouzivat nejake API ktore ma jasne definovane metody a to vsetko sa da detekovat.
-
strepty (neregistrovaný)
" lol2 Svojho casu ked sme pravadzkovali privatny wow server tak sme cez IDA disasemblovali wow.exe a hladali v nom ako v blizzarde poprehadzovali bajty v response packetoch."
Takze po pozreti kodu v IDAe pre wow.exe dokazete povedat na 100% ze tam nemaju trojskeho kona? Ona to je celkom relevantna otazka ked pracujete vo firemnom prostredi a chcete zaistit aby sa citlive informacie nedostali von. Windows 10 pouzivam ako priklad ktoremu na admin fore kazdy rozumie, napriklad ja o wow.exe nemam ani tucha ( a je pre mna dost divne ze by komunikacia bola v exe subore a nie v dll ale asi to tak je ked to poviete ). Inak ak mate funkny crack na win10 tak dajte link. ja taky nepoznam. Ale myslim taky ze neprestane fungovat po pol roku. -
j (neregistrovaný)
2Karell: Ty netusis naproto vubec co to je byt deterministicky ze?
Deterministicky (vetsinou) neni ani preklad ze zdrojaku do binarni podoby. Existuju (velice vyjimecne) prekladace, ktere deterministicke jsou = stejny zdrojak da vzdy exaktne stejnou binarni podobu. V drtivy vetsine pripadu to neplati. Uz jen proto, ze kompilator provadi vsemozne optimalizace na zaklade okolniho kodu.
Zpetny preklad neni deterministicky NIKDY. Neexistuje zadny zpusob jak z binarniho tvaru ziskat zpet originalni zdrojovy kod. Existuji jen zpusoby, jak vygenerovat kod, ktery (v idealnim pripade) dela totez. Pricemz toho vygenerovaneho kodu kldine muze byt i neakolikanasobne vice, nez puvodniho zdroje, potazmo i naopak, ale to by opet byl spis extrem.
Tudiz zvanis o vecech, o kterych nic netusis, ani paru nemas, bez se zeptat crackeru, proc nekdy trva mesice neco cracknou, dyk to prece neni zadnej problem, proste vemu binarku, z ty si vygeneruju zdrojak, a v nem si prectu co kde zmenit, trivka ne?
-
K těm velice vyjímečným překladačům můžeš studovat zde
https://wiki.debian.org/ReproducibleBuilds
Jak vidíš, běžné gcc umí zhruba 20k balíčků reprodukovatelných.Pokud si myslíš, že optimalizace implikuje nedeterministický překlad, tak jsi stále ještě nepochopil význam slova "deterministický".
Už se poněkud opakuji, výrazy "deterministický překlad" a "stejný zdroják jako originál" nejsou ekvivalentní.
Já nikde netvrdil, že někdy crack netrvá měsíce ani jsem netvrdil, že se to dělá přes dekompilaci. To je poněkud zvláštní vedení diskuze vymyslet si výroky a ty pak vyvracet.
-
KateStříbrný podporovatel
Takže maintaineři debianu lžou… Prosímtě, jdi jim vysvětlit že snaha o Reproducible Builds je nesmysl a vlastně jim to nefunguje, i když jim to funguje.
-
To jen ten nedostatek vzdělání :(
Deterministický algoritmus má při stejném vstupu vždy stejný výstup. Příkladem může být nahrazení písmene "A" za písmeno "B" v daném textu. Nedeterministický algoritmus je například takový, který náhodně (i když dělat cokoliv skutečně náhodně je u počítačů trochu problém) vybere písmeno "A" v daném textu, a nahradí ho za písmeno "B".
https://cs.wikipedia.org/wiki/Deterministick%C3%BD_algoritmusKdyž vezmete daný bytecode a proženete ho daným dekompilátorem, tak bude výsledek vždy stejný. Je to tedy deterministický proces.
To máte zřejmě na mysli je problém analýzy chování programu. Strojový kód i řada jazyků umožňují konstrukce, u kterých se obtížně dokazuje, že nějaké věci nedělají. Příkladem může být kód, který modifikuje jiné části kódu (dopředná modifikace). Když chcete zjistit jestli kód nevolá řekněme funkci pro formátování disku, tak ji v kódu nenajdete, ale ona se tam může dostat v průběhu provádění programu, což se analýzou kódu zjišťuje velmi špatně. Řeší se to sandboxingem, kde se kontrolují akce prováděné programem během jeho provádění. Další možnost je použít nějaký jazyk, který neumožňuje použít nebezpečné konstrukce. Typicky je to C# a java, méně typicky různá rozšíření jazyka C. A i bytecode bývá typicky navržený tak aby neumožňoval nebezpečné konstrukce, a aby se dal relativně snadno analyzovat. Nezapomínejte také, že z funkčního hlediska je bytecode shodný se zdrojákem (v tom je princip překladu).
-
Karel (neregistrovaný)
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."
-
j (neregistrovaný)
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.
-
KateStříbrný podporovatel
Kravka jsem já, asi si nás spletl :D
Ale jinak umí jen urážet, zvykej si :) -
Boo (neregistrovaný)
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.
-
nemo22 (neregistrovaný)
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.
-
j (neregistrovaný)
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.
-
tnr (neregistrovaný)
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.
-
Diskobolos (neregistrovaný)
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.
-
Alfonz (neregistrovaný)
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.
-
Diskobolos (neregistrovaný)
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.
-
Alfonz (neregistrovaný)
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/
-
Diskobolos (neregistrovaný)
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.
-
Proc by nebyl?
A zbavit se zavilosti na DX ti prijde spatne ? Jinak, OpenGL velke enginy samozrejme podporuji, migrace na WebGL je snadna (pokud uz ji neumi).Ale bral bych to pozitivne - aspon treba konecne dojde k rozsireni k Linuxu na desktopu, kdyz bude 99% aplikaci vc. her pro bezneho uzivatele v prohlizeci ;-)
-
To je blbost.
Nikdo to do JS prepisovat nebude, pouze pouzije Emscriptem k tomu, aby se existujici C/C++ prelozilo pomoci LLVM/clang do JS/wasm.
UT4 (jak uz bylo napsano) to podporuje velmi dlouho.
A FB uz od minuleho roku ma "Gameroom", ktery chce "konkurovat" Steamu jako herni platforma - vse samozrejme v prohlizeci.
Apple zase pripravuje WebGPU - API nad vulkan/opengl/direct3d prave pro pouziti z webu.Takze ano, toto je urcite budoucnost minimalne znacne casti her na PC platforme.
-
Konzole si myslim, ze to mine - tam je naopak cilem vyzdimat z HW posledni kapku vykonu vzhledem k tomu, ze konzole jsou obecne zarizeni s nizsim vykonem a dlouhym zivotnim cyklem - takze tam urcite nikdo nebude takto plytvat vykon.
Ale co se tyka PC gamingu - tak tam to urcite realna budoucnost je, zejmena na mensi / causaul hry, je to jednoznacne benefit a nejlepsi mozna platforma.
-
Ten benefit je v tom, ze se ostatni jazyky nebudou muset kompilovat do Javascriptu jako do ted, ale do k tomu primo navrzenymu bytecodu. Coz zjednodussi vyvoj prekladacu. Zadny negativa to nema, protoze Javascript zkopilovanej treba z Elmu nebo ClosureScriptu taky nema s puvodnima zdrojakama nic spolecnyho a cist to nebude o moc jednodussi nez ten dekompilovanej bytecode.
-
Diskobolos (neregistrovaný)
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í/syntaktický 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.
-
Filip JirsákStříbrný podporovatelV bytekódu tohoto v takovém rozsahu nedocílíte - musíte mít sandbox.
Proč? Jaký je rozdíl v tom, jestli mám v textovém souboru napsánowhilenebo jestli mám ten samý význam zakódovaný v binárním souboru jako bajt07? Nevím, jak přesně wasm vypadá, ale nějak jsem nepostřehl, jak všichni ti odpůrci ve zdejší diskusi přišli na to, že wasm bude něco zásadně jiného, než JavaScript zapsaný v binární podobě. -
Nevím přesně, jak je to implementováno, ale spíš než přidávání složité funkcionality jde o přeskočení několika fází interpretru - parsování atd.
Samozřejmě je nutné ohlídat vstupy tak jako u všeho, ale to v principu není nijak složité. Sandbox už tam je tak jako tak, v tom se nic nemění. Rozdíl oproti javě a flashi je ten, že tenkrát to měly na starost firmy, které neměly bezpečnost tak ošetřenou a dodávalo se to jako binárka, prostě typický rozdíl mezi open a closed source. -
Diskobolos (neregistrovaný)
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ů.
-
A ohledně kamenování - když někdo píše objektivně snadno vyvratitelné nesmysly, tak to prostě uvedu na pravou míru, stejně tak, když někdo používá pojmy jejichž význam nezná.
To že s novým kódem přijdou nové chyby nerozporuji, ale je to argument se kterým jsme to mohli zabalit u děrných štítků nebo ještě dříve. -
Diskobolos (neregistrovaný)
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?
-
> 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).
To jsi evidentne nepochopil smer vyvoje aplikaci poslednich 5 let - protoze ano, presne takove aplikace se delaji, proto jsou tak extremne popularni ruzne SPA frameworky (Angular, React), protoze se v nich dela to, co drive byla desktopova aplikace s podobnym komfortem (lokalni data, okamzita reakce).
A i tam se toto muze vyuzit - vsak konec koncu napr. webpack uz ma vyvoj naplanovany - https://github.com/webpack/webpack/milestone/16 -
Diskobolos (neregistrovaný)
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. -
> 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.
Skoda, ze to nikdo nerekl autorum Unreal Enginu nez ho na WebGL preportovali, ze to vlastne nefunguje a nema to zadny smysl :-)
Ze se zjisti, ze to je chybny krok - proc? Prohlizece se dale zrychli (jejich runtime enginy), CPU/GPU vykon dale poroste, stejne jako rychlost internetoveho pripojeni. Stejne jako se nikdo nevraci k desktopovym aplikacim od webovych (resp. rozhodne ne majorita uzivatelu), tak to nebude zde jine.
A prohlizec je z tohoto pohledu idealni aplikacni platforma - ma ji, potrebuji ji uplne kazdy. A diky temto technologiim zaroven vendor ziska pristup k mnohem vetsimu marketu, nebude muset resit napr. portaci na Mac OS, eventualne na Linux (i kydz co si budeme rikat, to moc vendoru nedela), je to win win situace.
