Emscripten and New Javascript Engine Bring Unreal Engine To Firefox 124
MojoKid writes "There's no doubt that gaming on the Web has improved dramatically in recent years, but Mozilla believes it has developed new technology that will deliver a big leap in what browser-based gaming can become. The company developed a highly-optimized version of Javascript that's designed to 'supercharge' a game's code to deliver near-native performance. And now that innovation has enabled Mozilla to bring Epic's Unreal Engine 3 to the browser. As a sort of proof of concept, Mozilla debuted this BananaBread game demo that was built using WebGL, Emscripten, and the new JavaScript version called 'asm.js.' Mozilla says that it's working with the likes of EA, Disney, and ZeptoLab to optimize games for the mobile Web, as well."
Emscripten was previously used to port Doom to the browser.
Re:Remember the good old days? (Score:3, Interesting)
Yeah, now instead of just floppies as a virus transmission medium, they're really write-once run everywhere.
No more customizing ASM for elf/win32. Better yet, because it's delivered over HTTP in a browser that's already authenticated to a proxy server if there is one, we have an instant authenticated outbound tunnel which can utilize json-p to establish a backchannel as long as the browser is open to any other HTTP service!
But best of all, the new and improved technology ships in with built-in advertising frameworks, remote execution tracking, user analytics, the ability to sniff platform information, and built-in DRM -- if I unplug my server nobody can run the app ever again.
Look -- you can call it progress because the UX is improved, because the system is faster than the old ones (the same way my phone is faster than an old TI or the ENIAC ...)
But I dispute your use of the word progress, as do many other wholly reasonable individuals. The system runs are fractions of native speed on poorly specified, highly ambiguous platforms. It strips away my control of local execution, and 'just happens to' hand over information that was traditionally not reported to all types of unidentified third parties.
Beyond that, a lot of this completely and utterly circumvents the traditional IT process. What used to involve testing, specification has been replaced with "requires chrome 21+" -- except it will import three different scripts, which will load 20 more remote scripts (all anonymously namespaced to avoid conflict/collision), load 4 different versions of jQuery between them (CDN will speed it up if done properly) -- any single one of which *might* be swapped out at any time without notification to IT.
And any single one of which is technically capable of doing all of the horrible things I mentioned above -- in addition to delivering the traditional problems in the form of a real exploit.
You can keep your damned progress, and I'll keep my computer.
Re:Javascript engine evolution (Score:5, Interesting)
I suspect the security concerns about WebGL are overblown. The code that runs on the GPU are vertex and fragment shaders. The shader language is very limited and exposes only a small surface between the host and the GPU. You can load/compile shader code, assign uniforms/attributes, share frame buffers and textures and that's about it. It's not as though the coder gets unfettered access to the entire DirectX stack.
Both firefox and chrome sanitize shader code so shaders can't play with whatever unsafe features some GPU might implement. One strength of WebGL (and OpenGL ES that's it's based on) is that the fixed function OpenGL API is gone; everything is done with shaders. That means the huge user-land fixed function API is gone and you're left with a simple API that just loads shader code and data (vectors, textures etc.) So the user-land attack surface is relatively small.
Vulnerabilities have been found in individual drivers but they've been few and fixed quickly. WebGL exploits are highly unlikely to be portable; they'll attack certain versions of GPU+drivers on certain OSs... broadly successful exploits won't be feasible.
Re:Javascript engine evolution (Score:2, Interesting)
I suspect the security concerns about WebGL are overblown. The code that runs on the GPU are vertex and fragment shaders.
And that's enough. I went to an opengl class where we would write vertex/fragment shaders. You know what? Most of the times I locked my machine was because I carelessly wrote an infinite loop. The code runs at the GPU so everything comes to a standstill, it seems macosx at least is unable to interrupt badly behaved GPU code.
So at least you can trigger a DOS attack. And I'm sure you can do funnier stuff given the attacks the previous year were malware flashed video cards to stay persistant accross reboots.
Conclusion: if you can't imagine where's the problem, don't worry, you simply lack imagination. Other more clever people will fill in the gaps for you.