1) You can follow the item to track integration of WebAssembly with JSC here: https://bugs.webkit.org/show_bug.cgi?id=146064 . asm.js works fine in Safari (though I've run into crashes with Safari on iOS 7), it's just not explicitly validated.
2) binaryen does it thusly: https://github.com/WebAssembly/binaryen/blob/485b1dca62848be92f9fcce4a70a5c63eb5015ee/src/js/wasm.js-post.js#L167 4) Read more here: https://github.com/WebAssembly/design/blob/master/Security.md I've also put together a toy vulnerability that should still work in WebAssembly here: https://groups.google.com/forum/#!topic/emscripten-discuss/gGjklbJiX1c 5) Stream support for compiling modules is listed as post MVP 6) WebAssembly is little-endian by spec, so a big-endian system would need to handle that On Tuesday, November 15, 2016 at 11:14:58 AM UTC-8, Gaurav Dewan wrote: > > I have Couple of questions about latest WebAssembly status > > (1) I have seen that WASM works like charm in Chrome and FireFox and > believe check-ins are happening in Chakra(Edges). What is the state (and > any indicator of release readiness) in Safari; especially all (webkit based)* > iOS browsers*(iphone/ipad) ? Infact asm.js is absent in ios (under > development - but not sure of timelines) > > (2) What is the current recommended way of testing Wasm support (feature > detection) in browser ? > > (3) A key thing missing in asm.js is fast "allow memory growth/shrink" > option (true dynamic memory support upto 1 or 2 gb). Is it tacked in > Webassembly(wasm32) in FF and Chrome efficiently -any example test-code > (performance characteristics) ? > > (4) I see the page about webassembly security on main site but I would > like to see more papers (something like NaCl blackhat conference > presentations) and attack vectors and mitigations. How c++ based > vulnerabilities translate to WASM world(risk) and if separate WASM > pipeline/processing opens up any additional attack surface (or is the > attack surface/vector same as normal JS code) in design and browser > impleentations > > (5) Do we expect to see further improvements in WASM startup time in > Chrome/FF (wasm streaming, cache, any parallelization or others) ? Or is it > recommended to explore other avenues like wasm splitting (dynamic linking) > based on profile/early-use-code, or any other? > > [ (6) Just from theoretical point - will wasm run fine on browsers running > on big-endian(or pdp-endian) systems ] > > Thanks in advance. > > Regards > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
