Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?
Posted May 16, 2014 23:44 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
> "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.
Posted May 17, 2014 6:11 UTC (Sat)
by roc (subscriber, #30627)
[Link] (5 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.
> 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.
Posted May 17, 2014 7:00 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
> 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
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.
> struct Hello
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.
Posted May 18, 2014 6:00 UTC (Sun)
by roc (subscriber, #30627)
[Link] (3 responses)
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:
> And as a bytecode, the Google's subset is almost completely
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.
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.
Posted May 18, 2014 7:16 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
> 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.
Posted May 18, 2014 11:43 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
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?
Posted May 18, 2014 12:10 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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?
> lot for proving my point.
Can you tell us about Mozilla's anti-DRM efforts?
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.
So what would: "int a = (unsigned int)2<<32;" do in a C++ code compiled into asm.js?
There are no pointer checks in asm.js, and you know it perfectly well. It's totally possible to write something like this:
> {
> char buf[20];
> int some;
> } world = {0};
>
> memset(&world, 11, 22);
> assert(some == 0); //Hmm?
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?
> into asm.js?
>
> Right, exactly the same as in PNaCl - you're at the mercy of the C++
> compiler.
http://www.ecma-international.org/ecma-262/5.1/#sec-11.7.1
> deterministic. I.e. a program in PNaCl will work on all supported
> platforms similarly. If it doesn't then it's a bug.
> 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.
Can you tell us about Mozilla's anti-DRM efforts?
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'.
So is PNaCl's behavior.
Without any modifications to JS? How about interfaces with sound, graphics and DOM?
Can you tell us about Mozilla's anti-DRM efforts?
Can you tell us about Mozilla's anti-DRM efforts?