While I doubt this will work, at least its a first step before people threaten to fork the standard. Thus, it gives W3C time and perspective on what the future could become for HTML.<p>To run and view DRM content, you must use closed and by extension, proprietary software. That has always meant increased costs in either price (license) or performance. If one sufficient popular product refuses to pay that cost, the web will become splinted into groups of working vs non-working websites for a subset of users. Given that every company has a incentive to decrease costs, this is just a matter of time.<p>Hopefully W3C will realize that this is not a future they wish to have.
Since no one else is writing the obligatory HN "I like the idea, but it will not work." comment, here it is.<p>I really like the general idea of a way to validate websites for privacy issues. In the best case they should even do this client side. But I think that they need to figure out two rather hard problems, one economically and one rather philosophical.<p>The economical problem is, why should any web site owner use it. I simply do not see a strong incentive.<p>And the philosophical is, what is actually meant by freedom? I see a lot of edge cases besides DRM which are sketchy, like user tracking. But to reliably stop user tracking, it is likely necessary to ban cookies ( which have of course a lot legitimate uses). And JS is a different can of worms, it can be used to spy on the user. The list goes on, iframes and third party content? Does freedom HTML get tainted by it?
I just don't get this obsession with not letting anything like DRM into an open spec for HTML. Copyright owners have every right to use DRM and in many cases thats the only way we are ever going to get access that content without monstrosities like Flash.<p>I'm not arguing that DRM works or that we shouldn't be allowed to "remove" it from media we legitimately own (we should be allowed to) but we shouldn't decide that DRM is evil because it isn't. Its the legislation around it that is, DRM is necessary to help prevent capsule mass piracy, we all know it isnt perfect and never can be but if it lets me watch a film or tv show without flash or some other junk then I'm all for there being hooks to enable it in HTML.
We should not have to label our websites 'FreedomHTML' because we <i>don't</i> use some APIs. Those are the websites which use these specific features which should be called 'SomethingElseHTML'.<p>I really hope that browser vendors will at least require some kind of explicit opt-in for borderline APIs such as EME.
What I don't get about the DRM issue: If there's no DRM possible with the video tag, then it's IMHO more likely that big content owners won't use the video tag than it is likely that they will go DRM free.<p>Too many workable alternatives to <video> exist. They might not work as well (not provide as much DOM integration, use more CPU power), but they do work.<p>So for me the question is: What is more important to us? Getting rid of plugins that are a hassle to keep up-to-date and open a whole lot of privacy and security issues? Or being idealists about keeping media free of DRM?<p>As long as a lot of media is served using plugins, browser vendors can't disable plugins (just like MS had to back-pedal with cutting plugin support in Win8), as long as <video> and <audio> don't support DRM, media will be shown using plugins.<p>A way to break the cycle and get rid of the plugins (which is a much worse issue than DRMed content IMHO) is to allow content publishers to use native browser features and a way to allow them to do that is to allow DRM.
Tell me which doctype to use, add the support into chrome and firefox (which is basically an "if doctype htmlFree;then do not load drm; fi") and I will use this tomorrow.
What does this achieve? If a <i>profile</i> only <i>omits</i> features, then browsers that do support EME and other omitted features therefore also support FreedomHTML. So if Chrome supports EME, they can still say they support 100% of the FreedomHTML profile.