Mono Abandons Open Source Silverlight

mikejuk writes "The Mono project is about the only group of people actively talking up .NET and developing it, but in an interview Miguel de Icaza has admitted that Moonlight, the Mono version of Silverlight, isn't worth the effort any more. He said, 'Silverlight has not gained much adoption on the web, so it did not become the must-have technology that I thought [it] would have to become. And Microsoft added artificial restrictions to Silverlight that made it useless for desktop programming. These days we no longer believe that Silverlight is a suitable platform for write-once-run-anywhere technology, there are just too many limitations for it to be useful.'"

Netflix

[jakimfett]

Now, if only Netflix would abandon it so that I don't have to boot into windows to watch movies...if it can be done for android, why not PC?

Re:Netflix

[King InuYasha]

Netflix on Android and iOS use raw video streams. No DRM or other funny business.

Yes and No

[pavon]

Silverlight (and XNA, and Windows Phone 7, etc) basically refer to overlapping collections of .NET libraries (often referred to as profiles) which different environments support. The set of libraries that Xamarin provides for Android development is a superset of the libraries available in Silverlight 4. However the intent isn't for you to write Silverlight applications that happen to run on Android. The idea is to write all your common code using the .NET Base Class Libraries (BCL; which are included in the ECMA standard), and then write your interface using (wrappers) around the native libraries for Android (or iOS or WP7 or Silverlight or WPF or ASP), for each platform you release on.

Re:How do we strong arm Ultra Violet distributors

[Microlith]

The funniest part about that Talk page is that "JimTheFrog" is, according to his user page:

Jim Taylor is Head of Technology and Product Development for UltraViolet/DECE, the online entertainment equivalent to DVD and Blu-ray.

So basically, that entire talk page is about the lead of that DRM-centric disaster defending what is fundamentally a customer-hostile technology. I'd call him a shill but he's probably tasked with "maintaining the message" on places like Wikipedia to make UltraViolet seem less fundamentally shitty than it is. And his dickish attitude towards Linux seems unsurprising, given that he

was DVD Evangelist at Microsoft.

Re:Netflix

[TheRaven64]

LoveFilm in the UK just switched from Flash to Silverlight, because of reason 2: the studios refused to keep licensing them for streaming with Flash, believing that Silverlight was somehow more secure (which it probably is, on the basis that it's so unpopular that no one as yet has cared enough to crack it). This has effectively rendered their streaming useless to me, as neither of the machines that I want to stream video to run a Silverlight-supported OS.

Re:DRM vs. locked bootloaders

[tlhIngan]

That's why the Nook Tablet came with a locked bootloader, whereas the original Nook Color spawned a large ROM'mer community. Netflix required it in order to let them use their app. I think I'd rather deal with DRM for paid downloads than have my whole device locked down.

If you want Netflix HD you need a locked down Android. Netflix (with standard def) is available for all Androids - locked or not. It's why the Nook tablet's netflix video is better than the Kindle Fire's - the Fire's drawing from the SD low res stream, the Nook from the HD stream.

Re:Netflix

[Guspaz]

It is, of course, impossible that Netflix might have chosen Silverlight because of technical reasons, such as the effectiveness and seamless nature of its bitrate scaling support... If memory serves, the browser-based alternatives to Silverlight for this functionality at the time they switched didn't work as well.

No, it's obviously a conspiracy. Microsoft isn't capable of developing an effective platform for anything.

Re:What will it be replaced with?

[fuzzyfuzzyfungus]

When it comes to DRM peddlers, it isn't clear that that will be the choice.

. Take a look [w3.org] at this 'Encrypted Media Extensions' proposal. Most of it just lays out a bunch of proposed javascript for requesting keys and passing them to a decryption module whose implementation is left vague(aside from the one, seemingly completely pointless, 'simple' case where a static, known, key is used for no obvious reason).

Now, have a look at the goodies: In the diagram at the beginning "CDM may use or defer to platform capabilities". And look also at section 8.5:

"Can I ensure the content key is protected without working with a content protection provider?"

"No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support."

"Can a user agent protect the rendering path or protect the uncompressed content after decoding?"

"Yes, a user agent could use platform-specific capabilities to protect the rendering path."

So, unless you want to use the (seemingly entirely pointless) 'clear-key' case, this 'open' proposal boils down to a mixture of hot air and admissions that the good stuff would necessarily be implemented in closed (probably 'platform', which increasingly means 'cryptographically locked firmware') sections.

Can an OSS browser protect the key from the user? No. The specification explicitly says as much. And if the key is known and the cyphertext has been downloaded, the game is over. Period. So, right there, only closed (either binary-only or OSS-tivoized) implementations of key handling need apply. Can an OSS media rendering path protect the content from the user? No. The specification says as much. Only if media rendering is handed off to a binary or hardware/firmware component can that be provided.

Essentially, this proposal achieves the magnificent breakthrough of allowing a DRM streaming stack to use the browser's HTTP transfer mechanisms instead of those in the flash plugin. Key handling and media path? Those are either completely in the clear, or necessarily handed off to user-opaque sections.

Further, if you want to 'protect the media path' and ensure key security(even in a binary module) that implies such radical capabilities as protected memory regions that cannot be read by even the highest-privilege user-controlled processes(so, either a locked kernel, or an 'open' kernel under a locked hypervisor, PS3 linux style) as well as locked audio and video output paths, potentially locked cache areas on mass storage devices, and so forth.

Given this, it really comes down one of two ways: The first option is Tivoization: Yeah, it's 'open'; as in 'you could build the code and run it on some other hardware without a locked bootloader'. The second is some sort of TPM-style 'secure remote attestation' setup: It's 'open' as in "yes, you can modify it if you want; but remote hosts will refuse to deal with you if your attestation signatures come back nonstandard"(see also: Google/android DRM and what happens if you root your device...)

For good or ill, you can't make a piece of hardware serve two masters. If you want DRM to work, the platform must ultimately be controlled by the vendor, possibly with little sandbox areas for the user to amuse himself. If you want the user to control the platform, DRM cannot be more than a (perhaps frustrating, perhaps trivial) exercise in obfuscation and cat-and-mouse trickery.

DRM solution for Android/Linux - please help

[incalito]

A few weeks ago I started to manage the new VOD platform. It's local, working only in my country, so its name is not relevant here. Project was started by a movie distribution company, seeking diversification and alternative to their DVD sales business, without the technical competence. They hired programming company, deeply Microsoft-related (partnership and so on). As you can expect, the platform was based on .NET/Windows Server, using IIS Smooth Streaming with PlayReady DRM, and Silverlight player. Then the problems with interoperability have started, as CEO quickly discovered, this solution has not worked on his iPad or iPhone, nor the Mac OS X playback was free from errors (most people in the company are appleheads, after all its movie business).

I come to the company as the manager with technological expertise (working a few years as the hosting guy/web developer, mostly in open source technologies), to oversee the work done by these external programmers. Our business strategy was to rely on presence on many different platforms, but now we're locked in. Luckily we were able to come on Samsung SmartTV platform, but only due to PlayReady implementation on these devices. We find a developers to prepare for us iOS app (Apple devices are PlayReady certified) and Sony PS3 app (also PlayReady certified). The advisors declared that there is no chance in moving our platform to Android and Linux, because THERE ARE NO DRM SYSTEMS AVAILABLE for these platforms.

The problem is that we have partners building their own settop boxes with Android on board, who want to use our VOD service as the source of premium video content for their users. The Android app would be great, but we cannot stream movies from our catalogue without DRM protection. I know that DRM sux, and is easy to circumvent, but you know, its a requirement put there by major movie producers - we cannot ignore that.

With these restrictions, we're looking for technological solution to bring our VOD content to the Android, and if it could be possible, to desktop Linux (at least Ubuntu). I've found Google DRM system: http://www.widevine.com/drm.html [widevine.com]. Does anyone here has expertise in working with it? Can we use IIS to stream content encoded with this Widewine DRM? Please give your advice, maybe the Flash-based solution would be better, at least AdobeAIR still works on Android?