Tim Berners-Lee Endorses DRM In HTML5, Offers Depressingly Weak Defense Of His Decision
from the welcome-to-the-locked-down-web dept
For the last four years, the Web has had to live with a festering wound: the threat of DRM being added to the HTML 5 standard in the form of Encrypted Media Extensions (EME). Here on Techdirt, we’ve written numerous posts explaining why this is a really stupid idea, as have many, many other people. Despite the clear evidence that EME will be harmful to just about everyone — except the copyright companies, of course — the inventor of the Web, and director of the W3C (World Wide Web Consortium), Sir Tim Berners-Lee, has just given his blessing to the idea:
The question which has been debated around the net is whether W3C should endorse the Encrypted Media Extensions (EME) standard which allows a web page to include encrypted content, by connecting an existing underlying Digital Rights Management (DRM) system in the underlying platform. Some people have protested “no”, but in fact I decided the actual logical answer is “yes”. As many people have been so fervent in their demonstrations, I feel I owe it to them to explain the logic.
He does so in a long, rather rambling post that signally fails to convince. Its main argument is defeatism: DRM exists, the DMCA exists, copyright exists, so we’ll just have to go along with them:
could W3C make a stand and just because DRM is a bad thing for users, could just refuse to work on DRM and push back wherever they could on it? Well, that would again not have any effect, because the W3C is not a court or an enforcement agency. W3C is a place for people to talk, and forge consensus over great new technology for the web. Yes, there is an argument made that in any case, W3C should just stand up against DRM, but we, like Canute, understand our power is limited.
But there’s a world of difference between recognizing that DRM exists, and giving it W3C’s endorsement. Refusing to incorporate DRM in HTML5 would send a strong signal that it has no place in an open Internet, which would help other efforts to get rid of it completely. That’s a realistic aim, for reasons that Berners-Lee himself mentions:
we have seen [the music] industry move consciously from a DRM-based model to an unencrypted model, where often the buyer’s email address may be put in a watermark, but there is no DRM.
In other words, an industry that hitherto claimed that DRM was indispensable, has now moved to another approach that does not require it. The video industry could do exactly the same, and refusing to include EME in HTML5 would be a great way of encouraging them to do so. Instead, by making DRM an official part of the Web, Berners-Lee has almost guaranteed that companies will stick with it.
Aside from a fatalistic acceptance of DRM’s inevitability, Berners-Lee’s main argument seems to be that EME allows the user’s privacy to be protected better than other approaches. That’s a noble aim, but his reasoning doesn’t stand up to scrutiny. He says:
If put it on the web using EME, they will get to record that the user unlocked the movie. The browser though, in the EME system, can limit the amount of access the DRM code has, and can prevent it “phoning home” with more details. (The web page may also monitor and report on the user, but that can be detected and monitored as that code is not part of the “DRM blob”)
In fact there are various ways that a Web page can identify and track a user. And if the content is being streamed, the company will inevitably know exactly what is being watched when, so Berners-Lee’s argument that EME is better than a closed-source app, which could be used to profile a user, is not true. Moreover, harping on about the disadvantages of closed-source systems is disingenuous, since the DRM modules used with EME are all closed source.
Also deeply disappointing is Berners-Lee’s failure to recognize the seriousness of the threat that EME represents to security researchers. The problem is that once DRM enters the equation, the DMCA comes into play, with heavy penalties for those who dare to reveal flaws, as the EFF explained two years ago. The EFF came up with a simple solution that would at least have limited the damage the DMCA inflicts here:
a binding promise that W3C members would have to sign as a condition of continuing the DRM work at the W3C, and once they do, they not be able to use the DMCA or laws like it to threaten security researchers.
Berners-Lee’s support for this idea is feeble:
There is currently (2017-02) a related effort at W3C to encourage companies to set up “bug bounty” programs to the extent that at least they guarantee immunity from prosecution to security researchers who find and report bugs in their systems. While W3C can encourage this, it can only provide guidelines, and cannot change the law. I encourage those who think this is important to help find a common set of best practice guidelines which companies will agree to.
One of the biggest problems with the defense of his position is that Berners-Lee acknowledges only in passing one of the most serious threats that DRM in HTML5 represents to the open Web. Talking about concerns that DRM for videos could spread to text, he writes:
For books, yes this could be a problem, because there have been a large number of closed non-web devices which people are used to, and for which the publishers are used to using DRM. For many the physical devices have been replaced by apps, including DRM, on general purpose devices like closed phones or open computers. We can hope that the industry, in moving to a web model, will also give up DRM, but it isn’t clear.
So he admits that EME may well be used for locking down e-book texts online. But there is no difference between an e-book text and a Web page, so Berners-Lee is tacitly admitting that DRM could be applied to basic Web pages. An EFF post spelt out what that would mean in practice:
A Web where you cannot cut and paste text; where your browser can’t “Save As…” an image; where the “allowed” uses of saved files are monitored beyond the browser; where JavaScript is sealed away in opaque tombs; and maybe even where we can no longer effectively “View Source” on some sites, is a very different Web from the one we have today.
It’s also totally different from the Web that Berners-Lee invented in 1989, and then generously gave away for the world to enjoy and develop. It’s truly sad to see him acquiescing in a move that could destroy the very thing that made the Web such a wonderfully rich and universal medium — its openness.
Follow me @glynmoody on Twitter or identi.ca, and +glynmoody on Google+
Filed Under: drm, eme, html, html5, tim berners-lee
Companies: w3c
Comments on “Tim Berners-Lee Endorses DRM In HTML5, Offers Depressingly Weak Defense Of His Decision”
I hope he at least had the decency to not give this quote whilst cashing his check.
This has already happened. Lots of sites use "minimized" JS which is incomprehensible to humans; and some sites have basically no HTML content, and will not work with JS disabled (e.g. Google Groups).
Re: Re:
minimized !== black hole binary blob
there’s plenty of services that will reverse that pretty that js up for you to reverse engineer on your own time.
Re: Re: Re:
But in some cases it still won’t have comments, or descriptive variable names.
Re: Re: Re: Re:
that’s still got nothing to do with DRM. that’s most relative to obfuscation..
Re: Re: Re:2 Re:
I wouldn’t say it’s got nothing to do with DRM, but you’re right, obfuscated source code (or good old-fashioned binaries) are not the same thing as DRM.
>It’s also totally different from the Web that Berners-Lee invented in 1989
As long as people continue to support companies that are anti-user, proprietary, and open standards averse nothing will change.
Advertising funded mass surveillance insecurity is the future we chose.
Re: Re:
What do you mean, we?
Re: Re: Re:
What have you done today to dismantle the surveillance state?
Tim Berners-Lee Took MPAA In On W3C
Perhaps in an alternate world, I would’ve listened to him. But he lost all credibility when me made MPAA a board member of the W3C. At that point it was over – it was clear he was in bed with them.
Not only does DRM require more permission that I want to grant code provided as a binary blob, it also opens holes for various nefarious acts, like unmasking anonymous users. This especially applies if the User cannot disable it, as any content frqm a site could be a Trojan for such purposes.
As Cory Doctorow has repeatedly pointed out, effective DRM means somebody else controls your machine, and you do not.
Re: Re:
Or it would, if “effective DRM” weren’t an oxymoron.
Re: Re:
What is the differences between a plugin like flash, silverlight, or the new EME plugin? I seriously don’t understand. As far as I know you can simply disable EME in the about:config section of FireFox at least. (media.eme.enabled) That should disable it’s use and you won’t be able to watch netflix, amazon, et al at least without using another plugin like flash or silverlight.
If people have the choice to turn it off, why is everyone still complaining?
Re: Re: Re:
The difference is between installing a plugin to allow content to be played, and letting the site install code to play the content.In the second case you can only decide whether to let sites do that, if your browser give you that much control.
Re: Re: Re:
The difference is that Flash and Silverlight, along with ActiveX, Java applets, mobile apps, etc. are all standalone applications provided and supported as a product by the vendor who wants that particular, non-Web platform to succeed. If Silverlight doesn’t work in Firefox, it’s Microsoft’s fault.
Making EME a Web standard moves the burden on to browser vendors to make this stuff work. If EME doesn’t work in Firefox it’s Mozilla’s fault.
Re: Re: Re: Re:
“Making EME a Web standard moves the burden on to browser vendors to make this stuff work. If EME doesn’t work in Firefox it’s Mozilla’s fault.”
I wouldn’t say that, the plugins for EME are easy to see and can be disabled as well. Just search about:config for media.gmp in FireFox and chrome://plugins shows them in Chrome.
Re: Re: Re:2 Re:
EME is a proprietary module loader, so that both the loader and the loaded module as closed source. Also, it has the potential to become alike JS, an essential component for many sites.
Re: Re: Re:2 Re:
Google recently removed the ability to disable it in Chrome — and even in the Chromium branch.
Re: Re: Re:3 Re:
Leigh,
I just realized this, so I simply went to the install directory. (C:Program Files (x86)GoogleChromeApplication56.0.2924.87) and deleted the WidevineCdm folder. Probably not the best option, but at least it’s something.
Tested with https://demo.castlabs.com/ and it won’t play DRM.
Re: Re: Re:2 Re:
You, unfortunately, don’t know what you’re talking about.
Javascript sealed away in a tomb
I, for one, would love to see Javascript, and any authors who require users to run Javascript in order to use their page, sealed away in forgotten tombs, never to be seen again.
Re: Javascript sealed away in a tomb
I get where you’re coming from, but…there are cases where JS is frivolous and unnecessary, and there are cases where it’s absolutely necessary.
Do you really want to go back to third-party plugins for audio, video, and web-based apps, and reloading the entire page every time you submit data to a server?
Re: Re: Javascript sealed away in a tomb
Generally no, but there should always be a download link that can be used. And anyway, what do those have to do with JS? Unless someone is writing a codec in JS, the browser can decode a video just as it can with images (images also being optional).
I’ll make an exception for DRM. Anyone putting DRMed things on the web should have to deal with the pain of external plugins. "We" should never try to make it easy for them.
The problem here is that some web developers think they’re writing a "web-based app" when all that’s needed is a page. Commenting works fine without JS on Techdirt (hitting "preview" loads a new page—so what?), but there are many websites where it’s not true. There’s no good reason that ordering a product or viewing a mailing list archive should need that complexity either. They can benefit from it where available.
For some things, like the Internet Arcade, it will of course be unavoidable and that’s fine.
Re: Re: Re: Javascript sealed away in a tomb
I agree with that.
UI. Built-in HTML5 audio/video players have limited functionality (at least, last I checked; I admit that’s not the focus of my day job lately). I suppose "absolutely necessary" was probably an exaggeration; it probably would have been better to say that JS is extremely useful for audio and video players, and absolutely necessary for apps (Google Docs etc.).
On that part, I totally agree.
True, but the main page sticks JS on every article (the "Expand" button). Which is extremely useful for browsing on a phone. But to your larger point, yes, that’s an optional feature, you can still use the site fine with JS turned off, and that’s as it should be.
Re: Re: Re:2 Javascript sealed away in a tomb
Does this need to be site-specific? Put play/pause/stop buttons in the browser, a seekbar and a volume control, and it would be pretty usable (more usable in some cases—like by hooking up to physical hardware buttons or allowing an exact position to be bookmarked). Is anything important missing? If so, it suggests that video container standards could benefit from new features—which could make downloaded files much more useful.
I could see a few extra features that might be nice and wouldn’t fit into a file container, like highlighting areas of a video for comment; or cut/paste video editing. Nothing critical for most uses.
Yeah, that can be useful but the site can easy fall back to a page-reload. Collapsable sections would be a useful semantic/accessibility feature to standardize, so browsers could have uniform handling across sites.
Re: Re: Re:3 Javascript sealed away in a tomb
Collapsable sections would be a useful semantic/accessibility feature to standardize, so browsers could have uniform handling across sites.
This soooooort of exists now in the form of the HTML5 "summary" and "details" tags, though implementation is iffy and it’s a long way from being usable for even slightly-complex functionality like our post expanders, sadly. Really that’s because "collapsable" isn’t especially semantic – many things that are very different in meaning might need to be collapsed in a user interface, and thus there is a "details" tag that does not really apply to "the body of a post".
Re: Re: Re:2 Javascript sealed away in a tomb
Some more details for those interested re: the Expand function.
When we built it we considered it very important to make sure it wouldn’t just “degrade” but would not be required at all. The native page loads with static “Read More” links that point to the article page as normal; the JS, if executed, replaces those links with “Expand” buttons.
Of course, one of the flaws in the expanders (especially for those loading without JS) is that the full text of all the articles is loaded with the page right now, which is pretty inefficient for the majority of people who don’t expand all of them (and completely useless for non-JS users). So we’re strongly considering changing it in the future to only load snippets with the page, and request the rest of the post content dynamically on expanding.
Re: Re: Re:3 Javascript expanders
I read Techdirt with Javascript suppressed. I ran into this quirk, and very shortly adjusted my effective stylesheet rules to compensate. I like that the entire article text is in the page, because with the rules I use, I can read all the text of every story from the main page. I only need to load other pages if I want to view comments or read stories that have fallen off the main page. To achieve this, I blocked all stylesheets from ii.techdirt.com, which makes the page very drab, but still surprisingly useful (due in large part to Techdirt’s well-chosen use of basic tags, e.g. using p, blockquote, etc. rather than inventing their own work-alikes via CSS).
I recognize that this is wasteful for most people, and would be disappointed but unsurprised if this is removed when the expanders are rewritten.
With regard to the expanders, if you do not mind still having the text in the page even when hidden, you can play interesting games with hidden form buttons and labels to create a JS-free way of showing/hiding content.
Re: Re: Re:4 Javascript expanders
Good to know – I’ll definitely keep it in mind that some people may make use of that. More likely though, what we’ll offer is a user/cookie-level setting that lets you request all full posts on the blog, with no hiding/expanding (maybe we can make this accessible via URLstring as well, for those who want no form of preference tracking whatsoever).
When we next update the site (which we are working on) I’ll be doubling down on the use of proper semantic tags so that everything works well in default formatting. Though, if you WOULD like to get the bulk of our CSS back without ditching the entire stylesheet, you should be able to achieve that using just a couple overrides:
div.storyblock.collapsed { height: auto; }
div.expandermask { display: none; }
As for the last bit, yeah, I figure there’s a way to probably make it work entirely via CSS with some creative use of :focus and :target — I used some much simpler versions of those tricks on the Survival Fund site — so I’m definitely keeping that in mind.
Re: Re: Re: Javascript sealed away in a tomb
You should appreciate the site I built for the Techdirt Survival Fund then 🙂 Aaaaalmost no JS at all, and no reliance on what tiny amount there is (though one small feature doesn’t degrade quite as gracefully as it technically could).
That said, I really really really like JS as a language. But I agree that treating simple websites as full-fledged apps running on massive frameworks is stupid and infuriating.
Re: Re: Re:2 Javascript sealed away in a tomb
Thanks for thinking about this stuff. But I guess you’re talking about the "small feature" of the "donate" button, which is the entire point of that site, right? I just see a blank page. Maybe that’s a Tor Browser bug, because I do see a "noscript" section in the HTML. Not that seeing "Our checkout process requires javascript." would help much.
(I doubt Foxycart would allow an anonymous donation even if it did load. We’re all well aware that various agencies are watching this stuff, and it’s had a chilling effect for me at least. Even when sites support Bitcoin, it’s always been unclear how to get that anonymously. Localbitcoins.com blocks Tor, as do certain popular Bitcoin payment gateways, and most Bitcoin exchanges make vague mentions of ID checks without saying when exactly they’re required. Too bad I didn’t start mining when I first heard of it, in the CPU-mining days.)
Re: Re: Re:3 Javascript sealed away in a tomb
Sadly yeah, we have no control over Foxycart and currently no better option for payment processing. I had hoped it would offer a non-JS flow (and I think it might? check to make sure it’s not that Tor browser issue) but yeah, some limitations there I acknowledge.
But I did the best I could. I didn’t bring the Foxycart javascript into our page, which is the “recommended” method and would have loaded up their entire API just for one product link (and would have turned the shopping cart into a JS-driven sidebar thing on the page, rather than a new URL).
As for what I had direct control over – the site itself – there are only two tiny bits of Javascript. One is for the quick 20/50/100/etc. links to choose donation amounts. The popup interface itself is all controlled via CSS, but there’s no way at all to change the value of a form field based on a link click without JS, so it uses a quick two-line function to do that.
Even smaller is a bit of JS for the dialogue you get when returning to the page after donating (which you can see by adding #thanks to the url). Again the whole thing is CSS-driven (opening & closing done using the :target pseudoclass rather than any JS) but, because I personally hate when modal dialogues are only closeable by their “X” button but not by clicking somewhere outside the dialogue, I added one line of JS to close the modal on background click too (which couldn’t, in any way I could figure out, be accomplished with pure CSS except perhaps by some very ugly and markup-heavy trickery).
Re: Re: Re:3 Javascript sealed away in a tomb
(I realize minimizing Javascript on the site itself could be called pointless when the checkout requires it — but, for me, the sole purpose isn’t just making it possible to use the web without JS at all. It’s also just making it so using the web doesn’t suck — because I freaking hate when simple websites are loading up entire application frameworks and being massive CPU hogs and so on.)
Lee sold his sould to Google years ago
Opinion
Mr lee sold out years ago.
Nothing he says should be held as sacred.
It is possible that you will still be able to block the execution of EME elements or limit them to trusted domains. Still, go without is probably the best option and from personal experience it’s quite easy. Or pirate if you must.
There’s also the unavoidable fact that somebody will break it at some point so we could just get some popcorn and wait for the “told you” moment when it falls to pieces.
Re: Re:
The problem is that when it becomes an official part of a standard, it will be difficult to avoid, as it will be built into almost all web browsers. Those people able to modify and compile their own browsers might be able to avoid enabling DRM, but this wll mean that they have to keep up with security advisories for the browsers that they use.
Gentoo, or Sabayon are becoming more attractive by the minute.
Re: Re: Re:
It already is built into almost all web browsers, Anon. It’s not even optional in Chrome anymore — hell, it’s not even optional in Chromium anymore.
Re: Re: Re: Re:
You can still use a build from a free-software distribution like Debian or Fedora. The DRM is of course non-free software, so by policy those distributions will not ship it.
Re: Re: Re:2 Re:
Which of course leaves you open to any vulnerabilities in using older code that hasn’t been updated to address any security problems discovered and patched since that version.
‘Mandatory DRM: Making people less safe by requiring them to use older, less secure browsers in order to avoid it.’
Re: Re: Re:3 Re:
What do you mean by "older code"? The distributions have security updates. It would be mostly the same code, just with the DRM removed. You’re not vulnerable to DRM bugs then, and it’s unlikely that removing DRM would introduce new exploitable bugs.
Re: Re: Re:4 Re:
Ah, misread/misunderstanding on my part then. I read the comment as ‘build prior to when they implemented the DRM’, which would mean old build, rather than the current build just with the malware stripped out.
Re: Re: Re:5 Re:
We do still have to watch out for automatic malware downloaders, which have occasionally shown up (example: the binary blob that listens on your microphone for "OK Google"). The Debian maintainers have been good about patching that out once informed, at least. The Tor Browser developers are looking more closely at this that most, so consider using that where possible.
Re: Re:
The problem with that approach is that once it becomes part of the HTML standard, its use will spread across the net like a plague. You don’t think YouTube, DailyMotion and all the other videos sites won’t fall all over themselves rushing to lock down every video on the site? Every news site, every adult site, every network site will lock down every single piece of video that they put online.
It will be like the mandatory arbitration clause in service contacts. Once the supreme court ruled that it was legal for companies to block people from using the normal court system in any disputes they might have, every company in the U.S. rushed to add that language to their contracts. Just try to find an ISP, cable company, or really any kind of service that doesn’t include that clause.
Re: Re: Re:
That is the other problem with DRM, it hands publication control to corporations, as the tools needed to apply it to content will not be available to individuals.
Re: Re: Re:
Yes, because if there’s one thing that stops web developers from implementing a browser feature, it’s the question of whether or not it’s been passed as a W3C standard. [/s]
YouTube already supports EME. So does Netflix. Most adult sites, as far as I know, don’t use HTML5 video at all; they still use Flash.
Re: Re: Re: Re:
Odd, then, that corporations have been pushing so hard to get them to approve the DRM.
The same thing goes for Berners-Lee’s comment. He says "we… understand our power is limited", as if it’s not within the group’s power to say "no" or to say nothing at all. Putting it into a W3C standard requires the W3C’s assent, and they should not give it. Were they truly powerless they’d never have been asked.
Re: Re: Re:2 Re:
It’s not really a mystery, Anon; browsers adopt proposed standards well before they’re finalized, and when a feature is available across widely-used browsers, it’s adopted by web developers whether it’s been finalized or not.
Ever seen a -webkit, -moz, -ms, etc. prefix? If you haven’t, then you don’t look at a lot of website source code.
It’s not that becoming a standard isn’t an important part of the process, it’s just that it tends to come after the part where a feature is actually adopted.
Don’t get me wrong, I’m strongly opposed to EME as a standard. But it’s already being used, standard or no.
Re: Re: Re:
if they try to lock down every video on there sites it will lead to user backlash
Re: Re: Re: Re:
How do you figure? Most video sites already implement some sort of method of making it difficult for users to download videos. Doesn’t seem to have hurt them so far.
another lying wanker! i wonder who paid him what to get him to go down this road!
no way
no way in H3LL will i allow a drm “blob” on any of my systems.
it is unlikely that the FOSS community will go along with building their DRM programming into the FOSS browsers
( Linux/Mint user )
Re: no way
Linux Mint includes nonfree binary blobs in drivers packaged with the kernel.
You may want to consider a different distro.
https://www.gnu.org/distros/free-distros.en.html
Re: Re: no way
thanks for the info
question though– are you referencing the Ubuntu versions — or also the Debian based Mint?
I only run the Debian base ( LMDE/2 )
Re: Re: Re: no way
I don’t know this for certain, but a little research indicates that LMDE, with only the default repos enabled, is all free software, meaning no binary blobs.
http://unix.stackexchange.com/questions/207462/is-linux-mint-debian-edition-free-software
Someone can feel free to correct me if I’m wrong.
(There are, of course, optional non-free Debian repos, which is why the FSF doesn’t endorse Debian; see https://www.gnu.org/distros/common-distros.en.html#Debian ).
Re: Re: Re:2 no way
With Debian, binary blobs and other non-free licensed software is available in the non-free sections of their repositories. These have to be enabled by the use to access that software, but it is available,
Re: Re: no way
Those blobs are tested by the Kernel people, who keep an eye on those blobs, while a DRM blob will not be tested outside of the DRM providers facilities. Therefore there are orders of magnitude of risk between the two.
Of more concern on modern machines, is the below the operating system code provided by the processor manufacturers, where once again there is no real independent checking of the code.
Re: Re: Re: no way
“no independent checking”
true
still it is possible to route the internet connection through an analyzer and that would reveal at least a traffic analysis
the extra traffic — if any — would certainly be encrypted and there would certainly be serious resistance to full disclosure.
interesting topic
Re: Re: Re:2 no way
Re: Re: Re:3 analyzer
makes me kinda think maybe i should not have taken that old 386 ‘puter my daughter gave me to the recycle place
we still have a couple boxes with older AMD Phenom II’s in ’em
Re: Re: Re:2 no way
Most people don’t know that analyzers exist, let alone how to use them. Besides, what does the typical user want to do. View their websites, or analyze the traffic that goes through their connection.
There needs to be some trust, something the malware people take advantage of all the time. Nut, it shouldn’t be so.
Re: Re: Re:2 no way
The difference between binary blobs in the Kernel is that they are usually provided via the distribution, and only updated reasonably infrequently. A DRM blob on the other hand is load on demand, and has the potential for being different for different people, and also only testable by independent people after it is in use by many people.
MPAA
Just a reminder that the MPAA joined as a paying member of the W3C a few years ago: https://www.techdirt.com/articles/20140107/11263425789/not-cool-mpaa-joins-w3c.shtml
I’m sure that’s totally unrelated to all of this…
Re: MPAA
of course it isn’t!!
plot twist, he wants to hand over the old web so he can release the new web. free the web sir lee!! free it
If no browser supported EME, then it would be DOA. That won’t happen though. Microsoft (IE/Edge), Apple (Safari) and Google (Chrome) are too heavily invested in user experience to not implement it. People who find they can’t watch a video because their browser doesn’t support EME will find a new browser, and none of them want that.
Maybe Firefox and other smaller browsers would/could resist. But as soon as one browser supports it, they’ll all have to. Else, they’ll lose their usage share very quickly.
Re: Re:
It’s not user experience, it’s that they’re all trying to sell people access to videos—the iTunes store, the Youtube TV-subscription thing that was just announced, and apparently MS has some store that’s less widely known. Firefox is the only major browser not associated with a video-seller, and therefore the only ones reluctant to implement this (but they still threw us under the bus eventually).
Re: Re:
Firefox added support for this a year or three back, in a “sandboxed” form in partnership with an EME blob provider whom Mozilla considers reasonably trustworthy (Adobe), for exactly the reasons you cite.
There was considerable pushback/backlash at the time (and at least one article here on Techdirt about it) – but as with most unpopular decisions by Mozilla in the last decade, by the time it became publicly known that the decision was being considered it had already become final and no reversal was made.
Re: Re: Re:
Seriously, Adobe is trustworthy?
Re: Re: Re:
A company known for producing products with top 10 security vulnerabilities. A company found spying on its customers by including spyware in it’s products and then quietly sending user data to 3rd parties. Adobe used to even have a prolific corporate troll in these very forums until it made the mistake of posting from Adobe corporate IP addresses once too often and was outed.
Yeah, real "trustworthy".
Like the US Civil War could have been avoided...
if the North had embraced slavery. That would have been the kind of practical, logical decision Tim Berners-Lee could have embraced. Principles be damned.
Re: Like the US Civil War could have been avoided...
On the one hand, just a wee bit hyperbolic.
On the other hand… that does seem to be his logic, ‘Well, they’re going to keep pushing for us do it anyway, so we might as well just give in now and let them have what they want.’
Re: Re: Like the US Civil War could have been avoided...
“On the one hand, just a wee bit hyperbolic.”
Just the kind of thing you’d expect to find on a lefty socialist site infested with a bunch of stealing pirates.
Who needs Trans Pacific Partnerships with friends like this?
Re: Re:
This has nothing to do with the TPP
Re: Re: Re:
Not as such, but the power of FTAs to change domestic law before they’ve even been debated by our representatives has been well noted here on TD. One of these changes is the 20 year expansion of copyright terms many of our nations have experienced in the last couple of years.
Re: Re: Re:
Clearly, the direct connection to TPP is not spelled out anywhere, but the W3C is partly doing for the MPAA what the TPP was designed to do for private sector interests against tax cattle governments that are not responsible for legislating to promote, fulfill, preserve, or expand the totality of private sector interests. Since the private sector couldn’t accomplish outright regional or global totalitarian fascism through illegal treaties (other than the banksters’ UN, OECD, and WTO), they’ll coordinate corporate sovereignty by a thousand cuts partly through standards bodies like the W3C which is revealing itself to have been a willing cog in the duplicitous "backstop apparatus" of private interests’ surreptitious agendas when attempts to either replace or override governments fail. The W3C (and other standards bodies) is becoming just like those fake minority advocacy organizations that are endorsing policy that manifest in worsening the plight of minorities those organizations aver to serve. We need a new decentralized telecommunications apparatus.
What's the problem?
If a site chooses to use this, you can choose not to use the site.
Having the option available built into standards beats the living hell out of all of the patchwork badly coded attempts to hide and protect stuff. Having it work well and not be an issue will make it transparent for most users and way safer than random coding.
You aren’t forced to use it.
Re: What's the problem?
I think that problem is what happens if big sites start using it?
Re: What's the problem?
What if government sites require it use, and the DRM is provided by the NSA?
Re: What's the problem?
"If ____ behaves unethically, just don’t use it" is a pretty garbage response to unethical behavior.
This is not what "transparent" means.
True. I don’t have to use YouTube; I could quit my job, instead.
Re: Re: What's the problem?
“True. I don’t have to use YouTube; I could quit my job, instead.”
Well then, there you go.
Pissed? Do something about it.
Free Software Foundation said something similar in response, and they’ve also got a link to sign a petition and send messages to the W3C.
Re: Pissed? Do something about it.
link please
Re: Re: Pissed? Do something about it.
https://www.defectivebydesign.org/selfie-against-drm-in-web-standards
How surprising it seems to me that a guy who was smart enough to mould HTML into the World Wide Web in 1994 should have a non-neurological learning disorder of such severity that he believes Digital Restrictions Malware to be a good thing. (-_Q)
but privacy!