User: Password:
|
|
Subscribe / Log in / New account

FSF's statement: criticism, but also constructive ideas

FSF's statement: criticism, but also constructive ideas

Posted May 15, 2014 17:13 UTC (Thu) by gerv (subscriber, #3376)
In reply to: FSF's statement: criticism, but also constructive ideas by Zack
Parent article: Firefox gets closed-source DRM

"They need the marketshare to "do good"? What "good" is there left to be done if the things you are doing to gain marketshare is contrary to the reason you exist?"

You really think there's now nothing good that Mozilla could ever do? Forgive me for suggesting that this is hyperbole.

I've already seen one email that a high up person in Mozilla has received about plans to extend DRM to other things. I would not be surprised if all such emails were referred to the response given in the case of Arkell vs. Pressdram.
http://en.wikipedia.org/wiki/Arkell_vs_Pressdram#Litigation


(Log in to post comments)

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

Posted May 15, 2014 18:50 UTC (Thu) by coriordan (guest, #7544) [Link]

Everyone can still do good in the future, but this news deals a blow to people's faith in Mozilla standing firm in the future.

First H264, then a weakened form a net neutrality, and now DRM - and with Adobe. These don't make Mozilla an enemy, but people are disappointed.

Each announcement has a paragraph with a regretful tone, but still presents these compromises as being good for users.

We've heard the bad news, that Mozilla is developing DRM, but can you give us the good news? Are there good fights Mozilla fighting behind the scenes? Surely the weak bargaining position that left Mozilla feeling it was forced to do something has hardened Mozilla's resolve to exterminate DRM - what's Mozilla doing on that front, what action is behind the paragraphs with regretful tones in the announcements?

What about FSF's suggestion for Mozilla to "devot[e] as many of their extensive resources to permanently eliminating DRM as they are now devoting to supporting it"?

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

Posted May 15, 2014 23:24 UTC (Thu) by roc (subscriber, #30627) [Link]

Some examples of good news:
-- 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).
-- With asm.js etc we're getting games off Flash and onto the Web (e.g. Unity) where they work across platforms without requiring closed-source components.
-- asm.js and other stuff we're doing is keeping developers on Web standards and off the Google-controlled PNaCl/Pepper platform.
-- Given Apple and Microsoft hardly engage at all in Web standards development, if not for Mozilla Google would be improving Web standards all by themselves --- but of course that doesn't really work. In particular because with only a single implementation of a standard its bugs become de facto part of the standard. (E.g. we fixed many broken things in the Web Audio spec.) After Opera dropped out, if Mozilla (or Google) were to drop out, the "two independent implementations" principle would enfeeble Web standards development.
-- Developing and deploying free audio and video codecs (Opus, Daala).
-- Developing new safer language (Rust) and browser engine (Servo) so one day Web security won't depend on millions of lines of C++ code.
-- Developing Shumway, the best open-source Flash replacement.
-- Providing a much more open-source alternative to Android for low-end phones. If nothing else this makes it harder for Google to fully impose their will on OEMs.
-- Pushing privacy features like DNT and Collusion/Lightbeam.
-- Building free geolocation service (Mozilla Location Service).
-- Specification and implementation of WebRTC so we can get people out of closed-source (and closed-network) services like Skype/Hangouts.
-- Investing in open source libraries like Harfbuzz that the entire open source community benefits from.

I haven't even listed anything the Mozilla Foundation is doing.

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

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

> -- 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]

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]

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]

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]

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]

> 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]

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]

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]

> 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]

> 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]

> 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]

> 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]

> 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.

FSF's statement: criticism, but also constructive ideas

Posted May 15, 2014 20:16 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> I've already seen one email that a high up person in Mozilla has received about plans to extend DRM to other things.

One notable example I've seen is the plans for Keurig to implement DRM such that only Keurig-approved K-cups will be brewed. Can you share what the other targets might be?

FSF's statement: criticism, but also constructive ideas

Posted May 15, 2014 20:59 UTC (Thu) by Zack (guest, #37335) [Link]

>You really think there's now nothing good that Mozilla could ever do?

No, I think it doesn't matter anymore what Mozilla purports to be doing. Right now it's a money-burning organization that sits in between Google and Firefox, paid to wave an "open web" banner around. I might as well save Google the money.

You had *one* job, Mozilla...

FSF's statement: criticism, but also constructive ideas

Posted May 15, 2014 22:44 UTC (Thu) by dlang (subscriber, #313) [Link]

so since you are dumping anything mozilla, what browser are you going to move to that fit's your requirements better?

FSF's statement: criticism, but also constructive ideas

Posted May 15, 2014 23:41 UTC (Thu) by Zack (guest, #37335) [Link]

It's not as much about "dumping" Mozilla software, but the loss of trust in Mozilla in their role as steward of an open and unencumbered Internet.

Now, with all vendors being more or less equal, one might as well take up gerv's own suggestion and use Chrome(ium), if only in the hope to send a signal to Google that they might consider to stop spending money on Mozilla so some people will get sacked, and a leaner and meaner Mozilla might do some soul searching about what their real role in the digital world is supposed to be.

FSF's statement: criticism, but also constructive ideas

Posted May 15, 2014 23:50 UTC (Thu) by dlang (subscriber, #313) [Link]

so, to punish Mozilla for resisting and then caving to something that Chrome has been championing, you are going to stop using Mozilla and instead use Chrome in the hope that Mozilla feels bad????

Mozilla never had the power to be the Steward of the Internet. If you are upset at them for compromising that position, then you just never understood their power in the first place.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds