Can you tell us about Mozilla's anti-DRM efforts?

Posted May 16, 2014 2:00 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: Can you tell us about Mozilla's anti-DRM efforts? by roc
Parent article: Firefox gets closed-source DRM

> -- Standardizing and implementing improvements to Javascript to make Web apps better. Other vendors aren't so keen to do this since they have their own proprietary platforms to protect (.NET, Dart, PNaCl, etc).
So Mozilla decided to create its own proprietary platform - asm.js. Complete with dysfunctional memory management, threading and graphics.

Thanks a lot.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 16, 2014 2:53 UTC (Fri) by roc (subscriber, #30627) [Link] (14 responses)

I suspect you're trolling, but in case you're not:

asm.js apps run on all major browsers, because their behavior is entirely determined by existing Web standards (JS, WebGL, Web Audio, etc) already implemented by those browsers. That's about as far from "proprietary platform" as you can get. All we did is define a special subset of JS, document that subset, and optimize for it. Other browser vendors are also optimizing their engines for these apps.

You can call it dysfunctional if you like, but it's bringing stuff like Unreal Engine and Unity to run on a fully open source, open standards stack, so it's clear win for Mozilla's principles.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 16, 2014 3:02 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

It does not run well enough for real apps on unmodified browsers. And definitely without threading and smart MM.

So Mozilla just created yet-another-bytecode, and it is about as ugly as it gets.

What's more, WebKit is moving towards using LLVM for JavaScript optimization. So on those platforms asm.js is just unnecessary and stupid layer.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 16, 2014 15:55 UTC (Fri) by raven667 (subscriber, #5198) [Link] (3 responses)

I'm not an expert but what you are saying doesn't make any sense to me. asm.js just defines a subset of real, valid, javascript not another language or bytecode, allowing javascript interpreter makers to make better optimization decisions, you can perform optimization steps which might produce invalid programs if the full javascript language features were being used. Whether those optimizations are performed by LLVM or not seems immaterial, in fact I don't see why an LLVM based optimizer wouldn't have the same constraints as any of the others, it should be able to do a better job on the subset which asm.js defines.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 16, 2014 16:12 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

asm.js is bytecode that just happens to be a valid JavaScript. And so it's super-ugly as a result.

As any other bytecode, it needs a virtual machine/JIT for it. It's just fairly easy to adapt Mozilla's JIT to work with it, but some kind of special treatment is needed nonetheless.

Having JS as an extra layer above LLVM rather than thin PNaCl wrapper is simply stooopid.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 17, 2014 6:15 UTC (Sat) by roc (subscriber, #30627) [Link] (1 responses)

> some kind of special treatment is needed nonetheless.

You keep repeating this, but it's not true. Every valid asm.js program is a valid JS program, and its behavior is the behavior defined in the JS spec, so any compliant JS engine will run it correctly.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 17, 2014 7:01 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Except that all currently existing JS implementations are non-compliant without special fixes (yes, even Mozilla required patches). Mostly because such an abuse of JS stresses too much sanity.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 16, 2014 23:22 UTC (Fri) by roc (subscriber, #30627) [Link] (8 responses)

Your first point is untrue. For example, here's a Unity-based game that works pretty well on Chrome (v36 here): http://beta.unity3d.com/jonas/DT2/

Exposing LLVM bitcode as a bytecode format is a poor technical decision. LLVM was not designed for this role. In particular LLVM bitcode exposes undefined behavior, so if your program accidentally relies on any undefined behaviors, its behavior can change any time Google updates the PNaCl implementation (i.e. every six weeks), as well as varying across CPU architectures. See https://developer.chrome.com/native-client/reference/pnac... for more information. Even more information here:
http://permalink.gmane.org/gmane.comp.compilers.llvm.deve...
The behavior of asm.js code is fully defined by the JS specification, which makes it the better technical solution for a portable code format.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 16, 2014 23:44 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Let's see...

> "Your version of Chrome is to old to run this content. You need at least Chrome 35. Press Ok if you wish to continue anyways."

Nope, doesn't work. And I have the newest version of Chrome. So thanks a lot for proving my point.

> Exposing LLVM bitcode as a bytecode format is a poor technical decision. LLVM was not designed for this role.
And so? PNaCL seems to work fine with only minor modifications and restrictions for LLVM. I managed to hack a Rust-to-PNaCl compiler in a weekend, for example.

And consequently, all the PNaCl undefined behaviors are present in asm.js, except for the stuff with bitshifts (I think).

> The behavior of asm.js code is fully defined by the JS specification, which makes it the better technical solution for a portable code format.
Yeah, except that JS spec was written by poo-flinging monkeys. If LLVM bitcode is simply a bit awkward in places, Asm.JS is just full-blown ugly.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 17, 2014 6:11 UTC (Sat) by roc (subscriber, #30627) [Link] (5 responses)

> Nope, doesn't work. And I have the newest version of Chrome. So thanks a
> lot for proving my point.

I tried it in Chrome dev (36) and it did work. I don't know why it doesn't work in Chrome 34, but I assume it's just a bug that Google fixed after that. They certainly didn't "add support for the asm.js platform" in 35.

> all the PNaCl undefined behaviors are present in asm.js

That is completely wrong. Every single behavior under the "Not Well-Defined" list on Google's page, if present in a C program compiled to asm.js via Emscripten, will produce a JS program which will have the same behavior on any spec-compliant JS engine. For example, an out-of-bounds pointer access in asm.js turns into an array-out-of-bounds exception that must fire in exactly the same way on all JS engines.

asm.js may be ugly, but it's still the technically superior solution.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 17, 2014 7:00 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> I tried it in Chrome dev (36) and it did work. I don't know why it doesn't work in Chrome 34, but I assume it's just a bug that Google fixed after that. They certainly didn't "add support for the asm.js platform" in 35.
They did just this, in effect. Safari also doesn't work, btw. Abusing corner cases of a spec to make a bytecode out of JS has its consequences.

> That is completely wrong. Every single behavior under the "Not Well-Defined" list on Google's page, if present in a C program compiled to asm.js via Emscripten
So what would: "int a = (unsigned int)2<<32;" do in a C++ code compiled into asm.js?

Right, exactly the same as in PNaCl - you're at the mercy of the C++ compiler.

And as a bytecode, the Google's subset is almost completely deterministic. I.e. a program in PNaCl will work on all supported platforms similarly. If it doesn't then it's a bug.

> For example, an out-of-bounds pointer access in asm.js turns into an array-out-of-bounds exception that must fire in exactly the same way on all JS engines.
There are no pointer checks in asm.js, and you know it perfectly well. It's totally possible to write something like this:

> struct Hello
> {
> char buf[20];
> int some;
> } world = {0};
>
> memset(&world, 11, 22);
> assert(some == 0); //Hmm?

And you'll get a good old undefined behavior in the C/C++ sense. Also dependent on compiler settings, like structure alignment.

> asm.js may be ugly, but it's still the technically superior solution.
No, it's not. For example, it still lacks threading - which CAN NOT be added to asm.js without adding quite a lot of stuff to JS itself.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 18, 2014 6:00 UTC (Sun) by roc (subscriber, #30627) [Link] (3 responses)

> So what would: "int a = (unsigned int)2<<32;" do in a C++ code compiled
> into asm.js?
>
> Right, exactly the same as in PNaCl - you're at the mercy of the C++
> compiler.

Given it's undefined behavior in C++, the C++ compiler can turn it into any JS it wants. But the JS it produces will run the same way on any spec-compliant JS implementation. For example, if the compiler generates the obvious JS code "2 << 32", the JS engine will compute 2, because the JS spec requires the shift count be masked by 0x1F before the shift:
http://www.ecma-international.org/ecma-262/5.1/#sec-11.7.1

> And as a bytecode, the Google's subset is almost completely
> deterministic. I.e. a program in PNaCl will work on all supported
> platforms similarly. If it doesn't then it's a bug.

That's not true in this case. If you read the Google page I quoted, PNaCl does not specify the results of all shifts: "There is still some architecture-specific behavior." They say it's "potentially fixable" but there's no indication they intend to fix it. You could argue "it's a bug" but it's hard to distinguish between implementation bugs and design bugs in PNaCl since it has no fully detailed spec --- one of the reasons why it's an inferior solution.

> There are no pointer checks in asm.js, and you know it perfectly well.
> It's totally possible to write something like this:
>
> struct Hello
> {
> char buf[20];
> int some;
> } world = {0};
>
> memset(&world, 11, 22);
> assert(some == 0); //Hmm?
>
> And you'll get a good old undefined behavior in the C/C++ sense. Also
> dependent on compiler settings, like structure alignment.

The behavior of the C++ code is undefined. The behavior of its JS translation is defined. That matters because it means once you've tested it in one JS VM you'll get the same behavior in other VMs.

The threading stuff is an issue. We're working on it, and I think you'll be surprised by how simple we can make the solution.

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 18, 2014 7:16 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> They say it's "potentially fixable" but there's no indication they intend to fix it. You could argue "it's a bug" but it's hard to distinguish between implementation bugs and design bugs in PNaCl since it has no fully detailed spec --- one of the reasons why it's an inferior solution.
It's a bug and they're planning to fix this, once a good trade-off can be found. And you might notice that it's almost the only real issue. The rest are more of a kind: 'Your program will crash differently on various platforms if you try to do something stupid'.

> The behavior of the C++ code is undefined. The behavior of its JS translation is defined. That matters because it means once you've tested it in one JS VM you'll get the same behavior in other VMs.
So is PNaCl's behavior.

> The threading stuff is an issue. We're working on it, and I think you'll be surprised by how simple we can make the solution.
Without any modifications to JS? How about interfaces with sound, graphics and DOM?

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 18, 2014 11:43 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)

> How about interfaces with sound, graphics and DOM?

Well, we already live in a world where direct access to such things can only (safely) happen from one thread anyways (Qt, GTK, and others I'm sure). Maybe they're working on something like signals and slots which work across threads? Or proxy objects to use in other threads?

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 18, 2014 12:10 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

They'll have to repeat what PNaCl has been doing - create something that is functionally indistinguishable from PPAPI.

After all, PPAPI has only one fatal flaw - http://www.drdobbs.com/windows/a-brief-history-of-windows... I believe, that it describes the current Mozilla perfectly...

Can you tell us about Mozilla's anti-DRM efforts?

Posted May 22, 2014 1:15 UTC (Thu) by foom (subscriber, #14868) [Link]

My most recent favorite example of cross-browser fast asm.js is Python:
https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/

Note that Chrome and Firefox do behave differently there: Chrome starts out slower, but ends up running the pypy-asmjs code faster than current-firefox.