Richard Stallman weighs in on Lib-Ray...

Apparently news about the project is getting around. I wouldn't classify Stallman's interest as an 'endorsement', though he did say that "It sounds very good...".

Of course, that was followed by "but there is a pitfall that is important to avoid." So, let's see if we can avoid it. :-)

He explains:

RMS: "Some video formats have a scheme for the menus which is so general that it allows programming. Even simple menus are implemented with a program.

"This means that videos always come with a program -- and since the people who make these are not thinking about free software at all, they don't put a free license on those programs. Thus, most videos come with nonfree software that's effectively gratuitous.

"In the old days, when menus were menus, this problem wouldn't have happened in the first place."

A little background: what he's talking about is similar to the way DVD menus work -- and I presume it is also how Blu-Ray menus work, though I haven't signed any NDAs to be sure about that.

In my response, I noted that Lib-Ray menus would be HTML, although I mentioned the need for some Javascript to access the DOM and manipulate audio and subtitle tracks for video objects.

Stallman pointed out quite correctly that this is still an opening for malware or non-free software if the Javascript comes from the movie medium:

Me: "Lib-Ray menus are HTML and CSS, and thus are declarative documents rather than executable programs."

RMS: "That is good news!"

Me: "There is a small amount of Javascript to support the menus -- basically we need Javascript URLs to attach to the DOM for the video player in order to communicate between the menu and video players systems. This package will be fixed as part of the standard (it's maybe 200 lines of code, which is basically just to make the required attribute-access code into simple function calls). Of course, this code will be free software."

RMS: "If it's normally the same for all videos, and you make it free
software, then it is ok. But why include this in the videos?
Why not make it part of a player module?"

Okay, that's a fair point. The real reason is because it's always done that way on websites, and I wasn't sure it would work to store the Javascript somewhere else. But in retrospect, I'm pretty sure that can be managed.

And we addressed some of the reasons for this declarative design for the video medium:

Me: "1) If it were a program, we'd have to trust every video release not to be a "trojan horse" -- e.g. the bootable disk image could easily be designed to take over and/or corrupt your computer."

RMS: "Indeed. It is VERY important for data files not to contain programs.
But this goes for that Javascript program too."

Me: "2) Even assuming good faith, a program-based standard would have to be continually updated to keep up with support for new hardware."

RMS: "That only applies if the standard is low-level."

[True, but the suggested bootable GNU/Linux approach would be]

Me: "3) Letting the disk take control of your system is buying into the same non-free ethos that brought us unskippable menus and the like. I want to keep the control in the hands of the user/viewer."

RMS: "I agree."

Can't get much better than that.

He further reiterates in a later follow-up:

RMS: "You need to refuse to run ANY Javascript from the device. If you need a Javascript program for this, package it in the player program, not in the device with the video. [...] If you run _any_ code from the device, that makes the scheme insecure: someone could write a device replacing the usual code with malware."

I think that's advice we're going to take. For Lib-Ray menus, we'll need to make sure that any Javascript code that we use is loaded from the player side. I have to say that definitely feels like the right choice. It may take a little bit of experimentation to be sure that this is compatible with the usual rules for sandboxing Javascript code. Even if it isn't, though, it might be worth creating an exception of some kind for the Lib-Ray player.

Comments

That a good idea. Probably You can even licence the player in a way so the js have to be free. But take care to not contaminate the content (movies, audio, text, pics). But making free JS a part of the branding rules is the main tool.

JS sandbox + limit access to media *should* protect from malware. But it will help if we can turn JS off on the player if we don't trust it (it is old and have security holes). We can still turn JS on for titles we trust.

Yeah, but it could work here. If you make it a requirement that any JS on the medium is free software to be considered "Lib-Ray compliant", then it would be no problem. There are plenty of free JS libraries, so I don't think it represents much of a creative limitation.

Of course, you can still write malware with free software Javascript, so it doesn't quite cover all of the issues, but it's a option to consider.

Yes, JavaScript are designed to be safe with untrustworthy code, but, web-browsers have frequent security updates and that is some of a burden. Now, if it is kept easy to apply upstream patches from webkit it should not be too bad. Standalone players that's off line don't really have anything to attack. If they online and have web-browsing capabilities they probably will have passwords and all kind of stuff to attac but then it is possible to install security fixes. For extra security the player can be installed in a LXC.

Must modify my earlier statement a bit - even a static HTML5 capability is a added value. Sufficient to present text material well and graphically fancy, Stuff like comics should work to.

But I want more then a "fancy VHS tape". Think a picture book were You can point at pictures to play small animations and sounds, Where animals and people can move in the picture, Where the user can explore, find small video clips and stuff like drag'n drop puzzles. There's endless possibilities and I will miss them.

However I'm all for a ability to block JS, I suggest that metadata contain a JS declaration that can be ether "None", "Optional", "Preferable" or "Essential". The branding rules can demand that a medias main features must work without JS except if the main feature it self are interactive. In the later case a sub-brand, "Lib-Ray interactive" can be mandated and it's only for those a JS setting of "Essential" is allowed.

If JavaScript works on the Internet I don't see a reason why it shouldn't be available in Lib-ray menu system... I think it will really hurt the format if it takes a too restrictive route.

Maybe you should just have an option where the user can select "full blown menu system with JavaScript" and "I'm not sure if I trust this" and just give him mini-menus. The author of the movie could then either add two different menus or just implement one of them and let the player do the rest of the work (i.e. fall back from "full blown" to "simple" or from "simple" to "comes with the player" or "just start playing main movie")

Disabling JS do not close the security issues. It take only a img-tag (or any other tag with a url) to phone home. Web-kit must be hacked/configured (I know nothing about it's design) to only allow access to file-urls and only on the media. That should likely solve most issues with JS to... But it must be checked that the JS engine don't bypass the net layer somewhere (web-sockets comes to mind).

If the user can allow the media access to the net it can just as well have it everywhere. Making stuff like timeline based comments like soundcloud possible.

That feature is not essential thou, just allowing external links that open in an external browser after the user have confirmed it is good enough for external linking (cower the need for a "pay as you like" / "pay for free" scheme). It is desirable to be able to set up group work, collect test result etc but not essential.

But to deliver rich content - JS is essential. Think data visualization in a math learning media, a diagnostic test generating a targeted playlist in any learning media. A web-comic with added interactive animations as extra (or even main feature), minigames, etc.

It's stuff like that that add value - a simple menu system to play the media is at best equally good as a filebrowser + traditional media player. That combo already supports dropping in extra sub-titles etc. As I envision download and file sharing as distribution You want the media file to contain all the extra stuff that traditional comes with the package (interviews, photos, art, fun).

Maybe this is naive, but it might be best to limit the functionality of the browser and JavaScript runtime. It's no longer a "video" if it touches an off-card URL or anything outside the menu's DOM.
Meanwhile, no security is foolproof, but you only need to worry about people picking the locks of doors that exist. A browser needs all the doors, whereas this doesn't.

You contacting RMS about the ethics of your standard has given me much greater comfort in my pledge. If the standard allows for things like programs, then it at least needs to allow for the containment of source and for free (re)distribution thereof. I'm not sold on the idea that programs are necessary for the format, but I hadn't given it much thought until now.

Yes, I think that the .js from the device should not be allowed to contact resources on the user's network unless the user gives permission. MS IE had/has zones of trust, so you can specify how much access you want to grant, such as network access, cookies, etc. You could grant that trust to the author, publisher, media, or drive. You could also allow the publisher of the files to sign the entire device/files/site somehow so you can use SSL certificates for trust. The certificates would probably have to be slightly different since you are validating files instead of a web server. PGP signing comes to mind, although you would not want to sign the entire video file since it is too huge to do at once. If you wanted the video to be signed, it would have to validate as a stream somehow. Perhaps in blocks. This might come in handy if you want to know that the contents arrived to you unaltered from the author.

Publishers want to give their users a rich experience. The menu as a fixed menu approach will stunt the format. Making this work like any HTML5 website that your web browser can browse to should be more than secure enough and highly functional at the same time. Anything more locked down than that (excluding restricting network access) seems to be a bit too excessive and unnecessary. It seems like what RMS is asking for is like a modernized Gopher protocol. Could you imagine what the Internet would be like if we still used Gopher instead of HTTP/HTML? Granted, it may be more standardized and accessible, but it would have held back a lot of progress made in user interfaces from remote servers.

If someone want to publish broken media it's really there problem. Most sane people ether ignore that crap or download fixed versions. These publishers will use blue ray anyway and should not be allowed to cripple the format for all the rest.

In theory js is sandboxed and running js from the device should be no problem. Some extra measures need to be taken to avoid 'phoning home' and maybe to restrict access to the media.

In practice there will be security holes in the sandbox and it will add some maintenance load to produce timely security fixes. So I can see some benefit with including all js with the player.

Sadly that is the end of delivering a rich experience. I see not mush point anymore over just delivering a video file.

I have not read all your docs so maybe this has already been covered, but I'd like to be able to author the "disk" and also have this whole authored package function on the Internet. I think Adobe had a way to do this, but I think it was all wrapped up in Flash. I want something that is mobile-friendly too.

It sounds like your plan to have the menus be stored as HTML would support this.

I do not understand why the same origin policy for JavaScript and other security features that web browsers have could not be used to sandbox the JavaScript code that is stored on device. This problem has been around for a long time and I think another solution does not need to be invented. A device should be treated the with the same same origin policy that web browsers use to prevent cross-site scripting and other vulnerabilities. Instead of "cross-site scripting", think "cross-device scripting" or think of the device as just another website on the Internet. In fact, since you are already using a web browser, why not just treat the device as a web browser would for any website on the Internet? If it worked this way, you could simply copy the contents from the flash media to a web server without any changes, and you have instant streaming.