Comment by chime | Hacker News Reader

Comment by chime | Hacker News Reader

Parent Full thread

> If we're going to transition to a plug-in free web then we need HTML5 video to support these extensions.

The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow should not be encumbered because of contractual obligations of today. I fail to see the technical reason why encryption is necessary for Netflix. HTML5 is a technical spec. It does not need to be riddled with extensions to fulfill business needs.

I can't view a stream if I'm not a paying member logged in to the website or XBox/Roku/AppleTV device. Once I am able to view the stream, encryption or not, I can record it through a number of hardware/software mechanisms if I am technically savvy. If I'm not technically savvy, I can't record it regardless of encryption. If I can somehow access the stream without logging in, say the files are stored on CDN and available to everyone over HTTP(S), then you should work on preventing that.

W3C/HTML5 are designing specs for the long haul. I am pretty sure I will be writing web apps in a decade too, like I did a decade ago. iTunes no longer has DRM'ed audio. Who knows, in a decade, Hollywood will give up DRM too, with pressure from Netflix, Apple, Amazon, and Google. But if engineers at these very companies that should be pushing for open-web, insist on burdening the spec to cope with DRM, I doubt we'll ever see that future.

> The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow should not be encumbered because of contractual obligations of today.

And when we live in your Star Trek-style technoutopia, then we won't have to worry about business concerns in specs. Specs have had business concerns in them since... ever.

I agree with you that business needs give rise to specs. That's pretty much how most of the specs are born. MS wanted to make Outlook Web Access behave more like the desktop version and came up with XMLHttpRequest - which went into the spec and made the web of today suck significantly less. That wasn't my point.

I'm talking about adding in mechanisms to support restrictions because of current legal situation. If you add in extensions that help DRM video, why not start adding in support for extensions that can prevent SSN or medical history from being displayed on the screen unless the local machine sends a valid fingerprint signature to the server? Of course that sounds ridiculous. Something like that doesn't belong in the spec. I fail to see the difference between that and EME.

> XMLHttpRequest... made the web of today suck significantly less.

I would argue the exact opposite.

I am curious. What are your arguments?

Likely referring to web-apps that require Javascript support and have no fail over code.

This is more a problem with the developer of said site and not an issue with XMLhttprequest as you can build apps that are progressively enhanced for it and don't fail completely when JS/XMLHTTP is disabled.

If you've upvoted or downvoted anyone here on HN, you have benefited from XMLHttpRequest.

HN doesn't use XMLHttpRequest. View source to see that.

    Specs have had business concerns in them since... ever.

Good specs haven't.

Good specs do. You might write a spec that describes the functional requirements of a claims processing system, because your current system is 20 years old and can't cheaply be modified to comply with legislative changes.

An obvious "business concern" is that any replacement system will accommodate future legislative changes. This has nothing to do with the functional (user) requirements (form design and submission process), and yet might dramatically change how you design and write such a system.

DRM, or rather the encryption scheme that makes it DRM, is much the same in that a design that supports it could similarly support related but more benign capabilities, such as compression or translation.

That too will influence an implementation, and makes such a non-functional requirement as important as a functional requirement.

The media companies know we'll always eventually be able to bypass any DRM they place on their media. But they still feel obligated to use it, partly for legal reasons. If they make their content available through a completely unrestricted video stream and then try to sue someone who infringes on their copyright, the defense's first question will be "well if you didn't want someone copying your content why didn't you place any of the available restrictions on it?" I don't think this would be a valid argument but it's not a risk many media companies would probably want to take.

> If they make their content available through a completely unrestricted video stream

That was my point. Why is it completely unrestricted? How hard is it to check a cookie and 401 if I'm not logged in? And if someone can fake an HTTPS cookie, they can do a lot more damage than download a video.

Reply on news.ycombinator.com