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 [video companies] 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+
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: drm, eme, html, html5, tim berners-lee
Companies: w3c
Reader Comments
The First Word
“As Cory Doctorow has repeatedly pointed out, effective DRM means somebody else controls your machine, and you do not.
Subscribe: RSS
View by: Time | Thread
I hope he at least had the decency to not give this quote whilst cashing his check.
[ link to this | view in chronology ]
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).
[ link to this | view in chronology ]
Re:
there's plenty of services that will reverse that pretty that js up for you to reverse engineer on your own time.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: 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.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re:
What do you mean, we?
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Tim Berners-Lee Took MPAA In On W3C
[ link to this | view in chronology ]
As Cory Doctorow has repeatedly pointed out, effective DRM means somebody else controls your machine, and you do not.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
If people have the choice to turn it off, why is everyone still complaining?
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re: Re: Re:
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.
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
I just realized this, so I simply went to the install directory. (C:\Program Files (x86)\Google\Chrome\Application\56.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.
[ link to this | view in chronology ]
Re: Re: Re: Re:
You, unfortunately, don't know what you're talking about.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
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?
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: 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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: 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".
[ link to this | view in chronology ]
Re: Re: Re: Re: Javascript sealed away in a tomb
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.
[ link to this | view in chronology ]
Re: 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.
[ link to this | view in chronology ]
Re: Re: 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.
[ link to this | view in chronology ]
Re: Re: Re: Javascript sealed away in a tomb
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: 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.)
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Javascript sealed away in a tomb
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).
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Javascript sealed away in a tomb
[ link to this | view in chronology ]
Lee sold his sould to Google years ago
Mr lee sold out years ago.
Nothing he says should be held as sacred.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re:
Gentoo, or Sabayon are becoming more attractive by the minute.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re: Re: Re: Re:
'Mandatory DRM: Making people less safe by requiring them to use older, less secure browsers in order to avoid it.'
[ link to this | view in chronology ]
Re: Re: Re: Re: 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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: 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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: 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.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re: Re: Re: 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.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
no way
it is unlikely that the FOSS community will go along with building their DRM programming into the FOSS browsers
( Linux/Mint user )
[ link to this | view in chronology ]
Re: no way
You may want to consider a different distro.
https://www.gnu.org/distros/free-distros.en.html
[ link to this | view in chronology ]
Re: Re: no way
question though-- are you referencing the Ubuntu versions -- or also the Debian based Mint?
I only run the Debian base ( LMDE/2 )
[ link to this | view in chronology ]
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
Som eone 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 ).
[ link to this | view in chronology ]
Re: Re: Re: Re: no way
[ link to this | view in chronology ]
Re: Re: no way
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.
[ link to this | view in chronology ]
Re: Re: Re: no way
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
[ link to this | view in chronology ]
Re: Re: Re: Re: no way
It's a horrifying rabbit hole which ends with waking up in a cold sweat from a dream about printing your own circuit boards.
[ link to this | view in chronology ]
analyzer
we still have a couple boxes with older AMD Phenom II's in 'em
[ link to this | view in chronology ]
Re: Re: Re: Re: no way
There needs to be some trust, something the malware people take advantage of all the time. Nut, it shouldn't be so.
[ link to this | view in chronology ]
Re: Re: Re: Re: no way
[ link to this | view in chronology ]
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...
[ link to this | view in chronology ]
Re: MPAA
[ link to this | view in chronology ]
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
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).
[ link to this | view in chronology ]
Re:
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.
[ link to this | view in chronology ]
Re: Re:
Seriously, Adobe is trustworthy?
[ link to this | view in chronology ]
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".
[ link to this | view in chronology ]
Like the US Civil War could have been avoided...
[ link to this | view in chronology ]
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.'
[ link to this | view in chronology ]
Re: Re: Like the US Civil War could have been avoided...
Just the kind of thing you'd expect to find on a lefty socialist site infested with a bunch of stealing pirates.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
What's the problem?
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.
[ link to this | view in chronology ]
Re: What's the problem?
[ link to this | view in chronology ]
Re: What's the problem?
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re: Re: What's the problem?
Well then, there you go.
[ link to this | view in chronology ]
Pissed? Do something about it.
[ link to this | view in chronology ]
Re: Pissed? Do something about it.
[ link to this | view in chronology ]
Re: Re: Pissed? Do something about it.
https://www.defectivebydesign.org/selfie-against-drm-in-web-standards
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]