Slashdot Mirror

where's the detection mechanism

Here. That's CSS2, if you haven't noticed.

Go to the "poster child" of CSS: CSS Zen Garden, and see for yourself. Tons of #id tags, tons of different designs, no one really taking any two designs and combining them with ease...

That's really NOT the fault of CSS. It's like complaining about Java that it lets you use a try{}catch{} without putting anything in the catch{} block. It's not a perfect analogy, but the idea is that people don't know how to use CSS properly. Look at HTML. It has come a long way. We hardly see crap like <center> because people (in general) have learned to stop using that tag. And only that took more than a decade.

tl;dr Guns don't kill people.

Is Web Audio not good enough for you?

"Web for All
The social value of the Web is that it enables human communication, commerce, and opportunities to share knowledge. One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability. (...)"

The purpose of DRM is to make it difficult to share knowledge (for the use-cases where such sharing is considered piracy by the content-owner). The sharing of content is only encouraged in a narrow subset of people, hardware, software, network infrastructure, ... that signifies "registered paying customer using a computer trusted by us, the content-owner".

To allow the W3C to set standards using DRM is a bit like an association of voluntary fire-fighters, where one stands up to address the crowd and says "Hey! I have a great idea! Why don't we start some fires; that way we get some practice, and besides it's very cool!".

Extinguishing fires is the task of the association of fire-fighters; starting fires is the task of the pyromaniac! If the association of fire-fighters is starting fires, you can conclude there's something very wrong with it ("regulatory capture").
Except in the case of the W3C, as you say, they do not determine what happens on the internet; they do not have a regulatory rôle, only an advisory rôle.

It's not about me, Flamey McTrollerson. The W3C exists to promote open standards. DRM by definition is not open. Look over this page and tell me which of these points relates to the W3C endorsing DRM:

http://www.w3.org/Consortium/mission

DRM is a choice for the market to make, not the open standards body. If someone wants to sell your coveted program on a DRM-laden DVD, great, go out and buy it. But don't standardize that bullshit on the open web.

It's well worth reading his book:

http://www.w3.org/People/Berners-Lee/Weaving/

I hope they have better luck w/ their NeXT Cube than I have w/ mine --- still haven't found the time to work out why it quit booting.... though I may have to put some effort into that if I don't find a better alternative to Macromedia FreeHand than going back to Altsys Virtuoso.

HTML5 is not a political action committee

No, it's a (draft) standard. It is being standardised by the W3C, which is a technical standards committee with a mission statement. The goals of the W3C are inherently incompatible with any standard that defines portions that can not be implemented in a compatible way by any vendor that wishes to participate in the market, and that includes DRM.

Fine with that. But please make a DRM _standard_. Not an API to access DRM but the DRM itself.
That means, describe the DRM standard so that anyone can implement it. Even in Linux I can implement any DRM, just like I can implement any encryption, but give me a standard.

All EME is doing is to describe a API to access DRM. That's it. Don't believe me? Go to the EME proposal. See that big one: Content Decryption Module (CDM)? That is the DRM. All around it is the EME.

Just to make it clear: the EME will not standardize the SCSI. All EME is doing is to standardize what cable you use for SCSI. That's it.

It doesn't specify anything of the sort. It specifies the interface, but not any specific CDM.

Not quite true, it does specify one, totally chickenshit, "'Simple Decryption' scheme, with the key provided in plaintext, and absolutely zero protection against even the most trivial of attacks(you wouldn't even need to modify the browser, since the decryption key is in the clear.) but it remains rather fuzzy who exactly would use this, since it's totally pointless if you aren't worried about 'piracy', and it's equally pointless if you are.

It is provided as a token example of how a 'OMG, totally open source compatible!!!' CDM could be implemented; but it achieves none of the goals of any DRM proponent, while being a nuisance to non-DRM users, so it's largely cosmetic. Any actual DRM will be in a binary CDM, possibly a hardware-dependent one(eg. 'Protected media path', etc.), and anybody who would be satisfied with the 'simple decryption' nonsense will just stream in the clear for simplicity's sake.

The web was popular because it was accessible and it worked reasonably well despite most people messing their HTML up; this is a concern and some think that XHTML 1 being extremely slow (arguably a failure) and that XHTML 2 died in part because of they lacked that understanding.

Most the web is STILL in HTML 4.

As one of the volunteers, I can tell you that pretty much every angle on such topics has been covered by somebody. The best decision is not always made but there is not much trouble in the opinion dept. HTML5 complicates things slightly by using MIME types to indicate an XML or HTML parser - defaulting to the HTML parser. There is an XML form of HTML5 look at the top of the spec, then configure your webserver to send the proper http header; meta tags with http data is a lame work around and I frankly do not know how successful that will be in practice.

I suggest the parent see section 1.6 of the HTML5 spec: http://www.w3.org/html/wg/drafts/html/master/introduction.html#html-vs-xhtml

HTML5 never will be "finalized," since it's not a W3C recommendation.

Its a W3C Candidate Recommendation that is scheduled to reach Recommendation status next year.

The whole idea is that it will be a living, evolving standard, with various features being adopted piecemeal in browsers.

You are likely confusing the WHATWG HTML Living Standard (which has no number) with W3C HTML5. They are two different things.

In other words, it will always be in development and there will never be an "HTML6."

There may or may not be an HTML 6, but there is already an HTML 5.1 in development.

HTML5 never will be "finalized," since it's not a W3C recommendation.

Its a W3C Candidate Recommendation that is scheduled to reach Recommendation status next year.

The whole idea is that it will be a living, evolving standard, with various features being adopted piecemeal in browsers.

You are likely confusing the WHATWG HTML Living Standard (which has no number) with W3C HTML5. They are two different things.

In other words, it will always be in development and there will never be an "HTML6."

There may or may not be an HTML 6, but there is already an HTML 5.1 in development.

FWIW here are the WWW guidelines for accessibility. If you want to make sure your content is available for disabled people (and you should), that is a good place to check.

.. but the real question is: Can you use it to learn how to do HTML Markup?

No it will not. EME is a "non-standard". All issues of EME are by default "out of scope" and are left to the Content Decryption Modules (CDM). As of now the EME "standard" is nothing more then like a Firefox API to start up Flash or Silverlight. So if the goal is to standardize UA plugin APIs so why not do that instead of the EME proposal?

See EME should do more to encourage/ensure CDM-level interop

XSLT is an XML *implementation*. You write the transformations (the T in XSTL) in XML... So contrary to what you implied, you *do* write the programs in XML...

Well, I think the authorities on the matter disagree with you that XSLT is an "XML implementation". Calling it that would be like calling a Matrix Transformation specification the language of math itself; while the two do collide in some areas they are not the same or even comparable. XSLT, and XSL, are basically document type converters - e.g. ODF to UOF to OOXML kind of thing - an easy way to convert from one XML structure to another; yet it still needs the XML parser to support it, or add-ons like libxslt on top of the XML parsers.

Some links for ya:
XSLT on WIkiPedia
XSL at W3 Schools
XSLT at W3C
XSL at W3C

XSLT is an XML *implementation*. You write the transformations (the T in XSTL) in XML... So contrary to what you implied, you *do* write the programs in XML...

Well, I think the authorities on the matter disagree with you that XSLT is an "XML implementation". Calling it that would be like calling a Matrix Transformation specification the language of math itself; while the two do collide in some areas they are not the same or even comparable. XSLT, and XSL, are basically document type converters - e.g. ODF to UOF to OOXML kind of thing - an easy way to convert from one XML structure to another; yet it still needs the XML parser to support it, or add-ons like libxslt on top of the XML parsers.

Some links for ya:
XSLT on WIkiPedia
XSL at W3 Schools
XSLT at W3C
XSL at W3C

Ah really? EME is not limited to video.
I would argue that once EME is in place and is adopted by enough UA implementations then a new group will be formed: EME Extended. Also the same groups will push for it: Google, Microsoft, BBC, Netflix, and I guess many more, like Wall Street Journal, New York Times, etc.

Then the W3C will declare it "in scope" and for the future of the open web. And all they done is replaced Flash and Silverlight with a new binary blob inside your browser, or worse, inside your property (i.e. your computer).

That's not really the problem. Sure, it takes more code to define a reusable template than to just use HTML to define a use-one widget, but that's expected. The savings from templates come from reuse, not from using them once.

XBL 2.0 is not a W3C standard, its a W3C Working Note -- which is very far from a standard -- that has a big fat "no one is maintaining or implementing this" on it.

It seems to be dead because the competing HTML Template (current W3C working draft) model was more successful in attracting commitments from implementers.

Short == Better when it is a website with millions of people accessing it. Every single BYTE counts.

Also, HTML Templating exists too.

And finally, the reason it was gone isn't because of this, but because Web Components (parent of Templating) is what replaced it.
It is far more in line with HTML than generic XML is. XML is painful.
Web Components Spec
Templates are deliciously simple to work with as well.

It's been superceded by Web Components: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html

That's why it's dead.

Outdated? You could still buy a new Wii through normal retail channels in 2012 (maybe you still can). Less than a year of support is the standard now?

Part of me wonders if this is because these are the exact features the Wii U doesn't support in its Wii mode, so it removes a reason someone might replace their broken Wii with a new Wii instead of a Wii U... but I also wonder how many zombie-Wiis are out there, downloading weather and new Miis every night, even though they haven't been turned on in years. It reminds me of the cost of running the HTML DTD servers, constantly serving millions of completely unnecessary requests.

The short answer is that there aren't a lot of people working on the problem. There are 7,000,000,000+ people in the world. There are 60 people in the Web Payments Working Group at W3C, of which only around 10 are actively working on the problem. It's a hard problem and there aren't that many programmers, systems engineers, standards makers, writers, bloggers, lawyers, etc. that are willing to put in the hard work to solve the problem. If you think this is an exception to the rule, you'd be wrong. There are only around 40 people really working on HTML5... and that work reaches over 1.5 billion people.

We've been working on the Web Payments stuff for 7+ years and I've always been kind of floored at how quickly most tech folks backpedal away from creating a truly revolutionary financial system on top of the Web.

If you're interested in lurking or especially helping, please join the Web Payments group... we need every helping hand that's available: http://www.w3.org/community/webpayments/

We are building the technology out in the open, transparently. Anyone can join the group. There are no fees, there are no prerequisites for joining. You can read the minutes from every one of the design meetings, and even listen to the audio here (we record everything): http://payswarm.com/minutes/

Here's an example of one such meeting: https://payswarm.com/minutes/2012-07-10/

Why design the financial system in this way? We need to show people that, unlike the way our current financial system is developed and run (behind closed doors), that we're taking a radically new approach to building the basis of the financial network that we hope all of humanity will use. This financial network is open and decentralized, like the Web.

If this interests you, I urge you to join and lurk (or preferably, participate): http://www.w3.org/community/webpayments/

Hi, I'm the chair of the Web Payments group at the World Wide Web Consortium (W3C). Just pointing out that the Mozilla mozPay() API is part of a greater push in the standards community to make payments a core part of the Webs architecture. This includes buying/selling digital goods, donations, crowd-funding, all the way to equity and loan-based crowd-financing for start-ups. Note that the mozPay() API is centralized, which even folks at Mozilla will tell you is not ideal. The eventual goal is to create a decentralized payment architecture that is designed for the Web from day one. We plan to put these advanced financial tools into the hands of all Web developers so that anyone with a website or blog has access to this open financial network.

You can read more about the PaySwarm standardization work here, which is mentioned at the end of the Mozilla mozPay() blog post: https://payswarm.com/

The first commercial implementation of these specifications launched three days ago: http://blog.meritora.com/launch/

If you're interested in following what's going on, join the Web Payments group at W3C: http://www.w3.org/community/webpayments/

Relevant:

http://www.w3.org/community/fedsocweb/2013/02/11/socml-a-standardized-social-media-data-standard/

See the bug: EME is not limited to video.

The EME CDM is not limited to just video and could well implement an entire
HTML engine defeating the good work of many to allow users to customize the
presentation of HTML. I suggest there is not way to achieve such a restriction
within the space of solutions acceptable to the proponents.

Did you even looked at the Article or read it?
The EME proposal will not eliminate proprietary plugins. All EME is do is to standardize an interface to access those proprietary plugins. Look at the graphic: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
Do you see the big block "Content Decryption Module (CDM)"? That is the proprietary plugin.

No DRM can work without a proprietary plugin. Right now it's Flash or Silverlight and you can download it if you want to use Netflix or other services. In the future your operating system have a CDM installed and is tied to some sort of TPM chip.

As a bonus, because DRM is now a web standard, it will be used for everything. Want to print that web site? Sorry no can do. Want to skip that ad? No can do. Want to save that Youtube video? No can do. etc, pp.

TFA is usually full of crap... maybe you should have a read straight from the horse's mouth:

https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#goals

the new form inputs are long overdue

It's not like the subject of forms has not been touched before. HTML5 is going the entirely wrong direction. Instead of modularizing a solid XML dialect (or several), we get a bunch of tags cobbled together from various other XML projects and a parser that approves of tag soup. Canvas has nothing to do with hypertext markup, forms have nothing to do with hypertext markup. They belong in their own modules or XML dialects. The sectioning tags are incomplete and a poor substitute for The XHTML Role Attribute, which, unlike the HTML5 sectioning tags, is extensible.
Take a look at XHTML 2, in particular things like XHTML Hypertext Attributes Module and tell me how HTML5 is anything but a step in the wrong direction.

the new form inputs are long overdue

It's not like the subject of forms has not been touched before. HTML5 is going the entirely wrong direction. Instead of modularizing a solid XML dialect (or several), we get a bunch of tags cobbled together from various other XML projects and a parser that approves of tag soup. Canvas has nothing to do with hypertext markup, forms have nothing to do with hypertext markup. They belong in their own modules or XML dialects. The sectioning tags are incomplete and a poor substitute for The XHTML Role Attribute, which, unlike the HTML5 sectioning tags, is extensible.
Take a look at XHTML 2, in particular things like XHTML Hypertext Attributes Module and tell me how HTML5 is anything but a step in the wrong direction.

the new form inputs are long overdue

It's not like the subject of forms has not been touched before. HTML5 is going the entirely wrong direction. Instead of modularizing a solid XML dialect (or several), we get a bunch of tags cobbled together from various other XML projects and a parser that approves of tag soup. Canvas has nothing to do with hypertext markup, forms have nothing to do with hypertext markup. They belong in their own modules or XML dialects. The sectioning tags are incomplete and a poor substitute for The XHTML Role Attribute, which, unlike the HTML5 sectioning tags, is extensible.
Take a look at XHTML 2, in particular things like XHTML Hypertext Attributes Module and tell me how HTML5 is anything but a step in the wrong direction.

the new form inputs are long overdue

It's not like the subject of forms has not been touched before. HTML5 is going the entirely wrong direction. Instead of modularizing a solid XML dialect (or several), we get a bunch of tags cobbled together from various other XML projects and a parser that approves of tag soup. Canvas has nothing to do with hypertext markup, forms have nothing to do with hypertext markup. They belong in their own modules or XML dialects. The sectioning tags are incomplete and a poor substitute for The XHTML Role Attribute, which, unlike the HTML5 sectioning tags, is extensible.
Take a look at XHTML 2, in particular things like XHTML Hypertext Attributes Module and tell me how HTML5 is anything but a step in the wrong direction.

Suppose a user sends me a threatening message on some site online. With DRM I can't save it. Suppose I want to save a video so I can play it later (maybe I need to play it offline for my assignment work). Again, if it's DRM'd I can't do that. I don't want my computer to work against me, and I don't think that should be a "standard".

Perhaps the better question is why should DRM be a standard? Why should computers disobey their owners for the sake of corporate greed? Why do media companies pretend that the world will end if DRM isn't added to HTML5?

It might also help to read what media companies have proposed for HTML5 DRM. The BBC wants to be able to take legal action against anyone that bypasses the DRM (even if the user isn't infringing copyright itself).

Or ISP provided webspace, I've seen a lot of that.

The last time I tried personal web space that ISPs provide at no additional charge, it had four key drawbacks. First, no CGI or other server-side processing was allowed; it was for static pages only, and some ISPs even failed to enable server-side includes to establish a common header and footer. Second, I remember a lot of these being limited to single- or double-digit megabytes of storage; good luck fitting video. Third, HTML storage APIs such as cookies and IndexedDB isolate one origin (scheme, host, and port) from another, but they don't isolate path prefixes within an origin. http://home.example.com/~someone_else/ can view and modify resources created by http://home.example.com/~you/. And finally, cool URIs don't change. I haven't seen an ISP that provides for forwarding of bookmarked URLs once the user changes ISPs, such as by moving to a city served by a different ISP.

Only if you really messed up.

Too bad the W3C is now working on DRM for the web.
Encrypted Media Extensions

It is not possible to have an open web and have DRMed content. You cannot give me the keys and the encryption scheme and to expect DRM to work.

Microsoft, Google and Netflix want to add DRM-hooks to W3C HTML5 standard
The BBC Petitions the W3C to Implement DRM for HTML5

It's just like Flash or Silverlight but with the blessing of the W3C.
Open source browsers and open source systems like Linux cannot support the Encrypted Media Extensions, without binary blobs.

Mod parent up.
WebRTC specification: http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcdatachannel

A nice experiment using WebRTC for P2P traffic in browsers: (well Chrome only for now, actually)
https://github.com/piranna/ShareIt#readme

ShareIt is a javascript P2P filesharing system. And yes, if you are thinking about a torrent-isch setup, that is in the works also, one is called Ampere.

[Invalid] - Markup Validation of ht tp://www.code.org/ - W3C Markup Validator

Errors found while checking this document as -//W3C//DTD HTML+RDFa 1.1//EN!

Result: 222 Errors, 127 warning(s)

(Also funny that the w3 uses a '(s)' after 'warnng' but not for 'error'.)

So its a FEATURE that they do NOT follow the STANDARD ... ok.

The specification at issue is not a standard, its a Candidate Recommendation. Ikay, that's a technicality, but more importantly:
They are following it; both the per-origin quotas themselves and the controls regarding preventing use of affiliated origins to circumvent the quotas are recommendations (should), not a requirements (must), of the spec, so even if they were not implemented at all, the implementation could be following the spec completely.
Further, the spec never defines criteria for determining affiliated origins with regard to the controls preventing circumvention of per-origin limits, so the fact that it doesn't prevent the particular use of related origins that were at issue in this test doesn't mean they don't have controls of the type recommended.

It's not intended behavior being exploited. Did you even read the summary?

I read the summary. The author of the summary, however, has not read the spec, or, if they have, has failed to understand all of the following (a) that both the use of per-origin quotas is a recommendation, not a requirement, of the spec; (2) that the use of controls to prevent the use of affiliated origins to circumvent the recommended per-origin quotas are also recommendations, not requirements, of the spec, and (3) that the spec actually doesn't define what constitutes an affiliated origin, so that even if per-origin quotas and affiliated-origin identification-and-blocking were required by the spec, it would be impossible to judge whether any particular implementation complied with the requirement.

If they understood any of those points, they wouldn't describe this as a "bug".

Not fixing a bug for a long time is not a "stable target". It's a failure to fix a bug

It's both, though if if there's a simple workaround available, sometimes the stability aspect is actually the more important in terms of being able to build working sites and web apps on the platform.

The real killer is when bugs are introduced, which is why I'm so down on the six-weekly cycle of Chrome and Firefox. They keep breaking stuff that used to work. To be fair, often these things are cosmetic, and while they're mildly irritating, they probably get fixed again six weeks later and no real harm is done. But sometimes the regression isn't just cosmetic, it stops things working at all. And then it isn't Google or Mozilla whose guys get paged at 10pm because my client's customers can't use the web app my clients paid for. (Would you like to guess why we won't include those browsers in our support contracts any more?)

A "different" box model. Yeesh. No, I'm sure you're right about this.

Even IE6 supported a standard-compliant mode that used the W3C box model. Remember where "quirks mode" came from? All you had to do was put a valid doctype on your page.

Moreover, to the extent that it applied since early CSS wasn't as uniform in allowing things like padding and margins to be specified anyway, pretty much all the browsers used to use that traditional model. It wasn't just IE, Netscape did the same. The W3C didn't standardise the way the major browsers worked.

So it's rather unfair to attack IE as if it was somehow either going it alone or defying the existence of then-new standards.

Still, if the traditional box model was such a dumb idea, at least it's dead now. That's why the CSS3 UI module provides a box-sizing property that allows the stylesheet author to switch explicitly to using an old-IE-style model (they called it border-box), which is supported in every major browser of recent years (including IE8+).

Even popular web design bloggers like Jon Hicks and Chris Coyier have promoted the border-box model as a useful tool, and obviously I agree with them. It makes far more sense if you're trying to implement a moderately complex page layout, particularly in the era of responsive/adaptive designs, to have the assigned width of an element reflect the total width it needs including all visible parts.

One day we'll surely all see the light.

As far as the box model thing goes, most of the world saw the light at least 3-4 years ago, even if you didn't notice.

As far as rapid release cycles go, we're not there yet, but I think the push-back from people who need to get real work done will start to overtake the new-shiny factor that makes for fun blog posts fairly soon. Lots of people do get the point anyway, but it's becoming more obvious as blog posts promoting new shiny that only works in WebKit or (less often) only works in Gecko are starting to come along, and more and more people are noticing that this is just IE-vs-Netscape all over again, but with more browsers this time.

> with an active community that cares about
> standards,

Sometimes. And sometimes not so much. Compare Gecko and WebKit's CSS 2.1 support (based on the official test suite) at http://www.w3.org/Style/CSS/Test/CSS2.1/20110323/reports/results.html for example.

Or note the behavior of the editors of the Transitions and Animations spec drafts (who did nothing for a few years, until editors who were not associated with Apple took over the job).

The WebKit community has many members who deeply care about standards. How much the community overall and the project as a whole care is very variable.

> has an explicit policy of trying to behave like other
> browsers where possible

For various values of "possible". e.g. https://bugs.webkit.org/show_bug.cgi?id=36084 is a long-unfixed spec-compat and other-browser-compat issue that's "impossible" to fix because there are Dashboard widgets and such depending on the current WebKit behavior.

> listens to feedback, and fixes bugs.

Unless it's inconvenient to one of Apple or Google to
do so, of course.

But yes, generally speaking it's a reasonably run development project, which means it listens to feedback and bugs generally get fixed eventually.

> They are the opposite of IE in those critical
> respects.

You must be thinking of IE6 circa 2004 or so, when there was no IE team.

The IE team did quite a bit of listening to feedback and fixing of bugs in the late 2000s, and is doing it again now that it exists again. Of course they're not fixing them in IE6 no more than WebKit is fixing bugs in whatever fork it is Android 2.2 is shipping. But you might want to take a look at IE9 and IE10 sometime if you haven't already.

Actually AutoCAD has an integrated lisp interpreter, so you could load Visual Lisp files and edit the source and see the output. There might be other programs like this elsewhere, but I know AutoCad let's you do this. There are lots of Visual Lisp files on the net.

You could also use emacs to do some drawing in SVG format, rendering it using the Emacs SVG mode. You could also write it all in elisp and use an s-expression to xml conversion script in an auto-revert buffer. Whether you would want to do that is of course a wholly different matter.

As far as I understood the EME the W3C will not define any particular implementation, but will provide an interface to Content Decryption Modules. Vendors can then set a key and the CDM will decrypt the content.

So basically it's the same as with codecs. The W3C failed to define a set of open codecs and they are not defining any particular DRM.
I guess that means that the system or the browser will provide such CDM with the help of TPM and the W3C just provides a standard set of API to set keys and decrypt content.

It's just like Flash or Silverlight, with the minor difference that the DRM will run in your system.
See https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0176.html

The question that lies open before us is: given that DRM exists, should it be implemented through proprietary plugins or should it be possible to hook it somehow into the open web platform?

How it can be possible to have an open platform and to "hook" DRM in it? DRM and an open platform are a contradiction. Good, you can give me the keys and the encryption scheme of your DRM and ask me to "follow the rules" to not copy the data. Anything other then to ask me polity to not copy your movie with the keys and the encryption scheme you just gave me, will be a closed platform.

It's a difficult question in part because even if you have the clear
goal that DRM should be eradicated — which you'll find is a view
actually shared by many people who support EME (in this form or another)
— there is no way to prove which path will most likely succeed in
attaining that goal.

I do know what will not archive that goal: to accolade DRM to a W3C standard. How can you say that people are opposing DRM and are actively working on a DRM W3C standard?

It certainly seems to be the case that platforms that probably
should have died a while back (e.g. Flash, Silverlight) survive to this
day because they support DRM.

Yes and now you are working to bring this to the open web. Which is not possible in an open web anyway, because you can't give me the keys and the encryption scheme and expect any security. So you can just drop the DRM in the first place and give me the content unencrypted.

We can all make guesses, we can have intuitions, but if we're being
honest there's no telling which strategy is most likely to succeed in
either eliminating DRM or turning it into something that's user friendly.

So that is the true agenda. To hook DRM in the open web as much as the user is not aware of it? That means turn the control over to the content producers. So basically, he is admitting defeat to Flash and Silverlight and wants to incorporate proprietary components in the open web. But by that in the future if you want to see "premium content" (from W3C) you have to accept those proprietary components in your open browser.

So what was the goal again for the W3C? To replace Flash and Silverlight with W3C proprietary components? I guess that's where the money is made.

So not much will change from the mosaic of "shitty proprietary standards" that we have today. It's just that the developers of those plugins don't want to handle media presentation anymore, and with this standard they can only care about data encryption and user surveillance. I'm afraid we can't even dream of seeing CDM plugins on Linux.

Read for example the concerns of this person from Mozilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944

Here, read this: http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0137.html, this person puts it very clearly: WTF is the W3C doing trying to *hinder* an open accessible web? DRM is against what their purpose in life as an organisation is.

Did "the Director" die, or something??

The trouble is that the properties that make a DRM system actually useful(ie. some degree of robustness, enough information about their environment to 'rights manage' in some granular way, and so on) require fairly extraordinary powers over the client system.

The 'Encrypted Media Extension' itself doesn't; because it defines almost nothing(one 'baseline' encryption mechanism that is little more than a toy obfuscation system, along with standardization of some interfaces for asking the non-joke DRM module questions); but it is designed to plug into DRM systems that do, which is the only reason that it has any support at all.

Consider, for example, the BBC's little request list:

Unless it is 'sufficiently secure that there would be the possibility of legal action in the event of bypassing it.', no go.

Unless it 'securely identifies a type of device', no go(browser UA is explicitly noted as not being good enough)

Unless it allows 'identification of the context in which the content appears', no go.

And 'The ability to pass further restrictions to the graphics rendering path if available'.

A set of requirements like that is both a fairly stock summary of what a DRM system should be capable of to be worthy of the name and a set of demands that certainly aren't going to be met in any non-tivoized OSS implementation, and wouldn't even be particularly easy to meet on something that isn't a closed box.

Essentially, once the pointless little baseline case is immediately ignored by anybody who would ever actually use the system(since, if you don't want DRM, you won't want the hassle, and if you do, the baseline is far to pitiful to be worth anything), EME is a 'standard' for 'how to use javascript to talk to an entire black-box video rendering mechanism, upon which there will be enough demands that it will almost certainly be platform specific'. Pretty much exactly the same situation as having the video player stuck in a blob of Silverlight or Flash, except that (because this is HTML5, man) the wicked 'browser plugin' has been renamed a 'content decryption module'(which, as the spec notes, 'CDM implementations may return decrypted frames or render them directly, and 'CDM may use or defer to platform capabilities'). In all but name, it's the definition of a few javascript APIs for interacting with a black-box video path more or less identical(if not worse, given the more robust support for invoking the hardware-protected 'platform capabilities' now present on a lot of consumer gear, which something like Flash was always too dubiously competent to do in any serious way) to the plugin-based video player arrangements of the past.

That suggests a fundamental misunderstanding of encryption.

Yes, it suggests my fundamental misunderstanding of the obvious.

The point is to prevent the owner of the computer from accessing the data, so it probably is incompatible with Free Software.

http://www.w3.org/community/pua/wiki/Digital_Rights_Management#DRM_is_against_open_source_software

The file concept doesn't exist on iOS.

Which is probably why an element from HTML3 (let alone 5) went unimplemented for the first five years of iOS: <input type="file"> . Apple could have implemented this by introducing a concept of "object with a MIME type that an application is willing to back up or to share" even if not called a "file" to the user. So much for supporting the whole web.