Hacker News Reader

Comment by sowhatquestion | Hacker News Reader

I distinctly remember being upset about DRM in the '00s, back when it was being used to place onerous restrictions on content that people had ostensibly "bought" (CDs, DVDs, AAC audio files, etc.). Now that it's being used to prevent people from saving streams... I hate to say this, but please remind me why I should be upset? I never had any illusion of "owning" a stream. Not only that, I would rather stream than own in most cases.

View on HN

Because it's a lot harder to make a competing web browser now. You'll have to buy the secret binaries from one of the DRM providers, if they'd even be willing to sell.

Firefox, which is open source, both sandboxes the Adobe decryption module—giving the browser control over the world that the Adobe module sees—and fetches it at startup from Adobe's site. It seems almost impossible that you'd be unable to hit the same URL from your own browser and put it inside your own sandbox such that the module can't tell it's not running inside Firefox. You have the hard constraints that the module can't examine the outside world except through the sandbox, and the sandbox itself is open source.

Edited to add: Widevine, the (Google-owned) decryption module Chrome uses, has no license fees. http://www.widevine.com/

For Widevine, it looks like the following would be required:

    Completion of legal agreements
    Delivery of a Widevine documentation package
    Technical discussion to understand the device type, chipset, and review the Widevine robustness rules
    Exchange of libraries, SDKs, and integration documentation
    Keybox request and fulfillment (as needed)
    Client integration testing

For piggybacking on the Firefox binary, maybe that would work but sounds like something you might get a cease and desist for.

Anyhow, if everyone agree to make the binaries 100% free as in beer (like Cisco did with H.264), then that's better than nothing and makes writing new browsers easier.

But the future is in new devices, operating systems, and virtualization. Being provided binaries limits freedom to make new things. And of course who knows what backdoors are in them.

(Edit to add: this is a great discussion, http://www.reddit.com/r/debian/comments/25kbi7/next_firefox_... -- note that the tracking/privacy/backdoor issues with this are huge.)

Openh264 from Cisco may be free as in beer but as it only supports the baseline H.264 profile it's effectively useless.

As an actual example of the problem, there are millions of PowerPC Macs out in the world that run perfectly adequately with Linux and are capable of playing HD video. Is the opaque binary blob hardware-independent?

If it is then I can't even imagine what its purpose is supposed to be. If my "hardware" is a virtual machine that captures the video output to a file then the blob isn't even doing anything. And if it's not hardware-independent then there are obviously going to be innumerable minority platforms that it doesn't support.

"there are millions of PowerPC Macs out in the world that run perfectly adequately with Linux and are capable of playing HD video"

I think you might be too optimistic on this one.

Not to mention most of these are probably running with 512Mb to 2GB RAM (G5 iMacs go to 2GB, PowerMacs to 8GB, some go to 16GB)

I suspect you could coax 720p out of a 1GHz+ G4 if the code was sufficiently optimized -- another obvious problem with putting the video decoder in a black box.

But more importantly, the point is not the exact quantity of particular models of PowerMac in existence, the point is that if I have one which is otherwise capable of it, this nonsense interferes with me doing it.

And the same goes for every other thing that doesn't fit a mold. What about Linux on a PS3? What if I have a PA-RISC/Itanium/Power/etc Unix workstation? What if I'm using X forwarding so that my "browser" is really running on an UltraSPARC server?

It breaks anything the central planning committee didn't contemplate a priori or can't be bothered to fix. And it's not just old hardware, it's anything new or different. It keeps new platforms from getting off the ground.

I think they have given up to prevent you from capturing the output. The binary blob does decryption and decoding in one step, which prevents you from replaying the compressed stream.

I don't understand how that is even supposed to be useful. The output is still digital HD video. The higher the quality of the video the fewer compression artifacts there are going to be and the less having to re-encode once will make any difference whatsoever. And it would only have to be re-encoded once regardless of how many times it's played back or copied subsequently. If they're hoping for some kind of VHS-style degradation of the video quality they obviously haven't actually tested it.

> fetches it at startup from Adobe's site

Source?

Anyway, even if you can download and sandbox the Adobe module it might be a violation of the license agreement. This can even be a criminal offence in many countries because of special laws about circumventing DRM!

What about operating systems and hardware platforms not supported by Adobe or Google? PowerPC, MIPS, Tizen, *BSD, etc.

It's a convoluted process, but Firefox pings the update server, which returns a list of proprietary blobs to potentially install.

It looks like this with Cisco's OpenH264 plugin and Adobe's CDM: https://aus4-dev.allizom.org/update/3/GMP/36.0a1/20120222174...

I'm not a fan of DRM, but I don't find this argument very convincing. It's pretty much impossible for anybody to create a new mainstream browser at this point. The standards are huge and complex and require seriously optimised implementations to get acceptable performance.

Which is why we only have a handful of competitive browser engines today, and all of them are based on code at least 15 years old. The last time somebody created a serious new mainstream browser (that wasn't just a re-skin of an existing one) was 7 years ago, and it was still largely based on existing code, despite having the backing of one of the biggest tech corporations on the planet. The standards have become vastly larger and more complex since then, and security and performance expectations much higher. Just keeping up with all the new standards is hugely expensive. The cost of a DRM module from Adobe is surely the least of your worries if you want to create and maintain a new browser.

It is a hard problem to crack, we should give up.

> The last time somebody created a serious new mainstream browser (that wasn't just a re-skin of an existing one) was 7 years ago, and it was still largely based on existing code, despite having the backing of one of the biggest tech corporations on the planet.

We're working on one (Servo) :)

And we are working on another (gngr) :)

To make matters worse: Three of the four major browser vendors are also DRM vendors. Google, Microsoft, and Apple all have their own DRM modules. EME therefore gives them a lot of control over the browser market and media market.

Four of them are also working on their own mobile devices/OS. Which gives them even more incentive to lock out competition.

The basic principle that we have lost is that the standardized part of the web has always been fully open. You can look at the source of any page, figure out how some cool CSS or javascript trick works and copy it. You can download any image you see and modify it. This in contrast to, for example an iPhone app, it's closed, unmodifiable, secret, hostile to tinkerers. Flash video was closed but it was not a web standard, this is.

First, it is simply not true that the standardized parts of the web have been fully open. There have been scores of proprietary features, including those with no source availability or even documentation, that have become web standards because browser vendors built or reverse engineered them and web developers used them.

Standardization is a good thing, but you're being a bit selective claiming web standards have always been open and source available. It doesn't always happen that way. It didn't happen that way for image codecs, for example.

Second, plug-ins most certainly are and have been a Web standard.

NPAPI was implemented in multiple browsers from multiple different vendors and has been used by dozens of major software companies and thousands of lesser companies, commercial and open source, for browser integrated features.

That you don't consider de facto standards to be standards doesn't mean they aren't.

Reply on news.ycombinator.com