> Our proposal does the same thing, except for anti-circumvention rights (rather than patents). Members who participate in the Media Extensions Working Group will have to make a legally binding promise not to use anti-circumvention laws to aggress against security researchers or implementers. All other rights and causes of action -- trade secrecy, copyright, tortious interference, breach of contract -- are intact.
This sounds like a reasonable compromise. Having a W3C standard that can't actually be implemented by anyone except those that are explicitly granted a license is not a standard: it's really just proprietary software, and feels like going back to the days of Flash, Java and Active-X applets, only worse, because it's a legal problem instead of a technical one.
I'm definitely against the idea of DRM in any W3C standards without this type of provision, but I'm not sure if this is enough or not.
If I make a time shifting system, to use the article's example, but the standard says the protocol must be played live, am I an implementor of the standard, or a nefarious hacker?
What if I create software which lets people abroad watch content from PBS Nova (currently blocked by geo-IP)?
I might even screw up and implement something usable for "bad things" by accident. Am I then an infringer, if I neither properly implemented the standard nor conducted research on it?
However, this only protects you from suits over circumvention. You are presumably still eminently liable for your PBS Nova scenario, for instance.
One could also argue that 'fast forwarding' is a form of selective time-shifting for personal use. The analog equivalent to this would be getting up to use the restroom or make a snack during an over the air television broadcast; or even switching to another channel during that set of ads.
Note that this promise only refers to 17 USC 1203, which deals with civil offenses, i.e. a lawsuit.
Circumventing access controls is also a criminal offense under 17 USC 1204 (if done "willfully and for purposes of commercial advantage or private financial gain") and it's not possible for a company to waive the government's ability to prosecute that crime.
(not to say that these kind of domestic abuse policies don't have their own controversy... but nonetheless the situation isn't a cut-and-dry obviously-this-is-better type of thing)
I guess you could imagine having a set of criminal offenses where coercion of victims appears especially unlikely, but I'm not sure of how to identify or define those.
But in some situations it does seem to be what one would want (for example the under age people arrested for sexting pictures of themselves). However, if we could rely on common sense in these situations, the people would never be arrested in the first place.
Re common sense: if it was in the law, prosecutors wouldn't matter.
My main issue is that it leaves open an opportunity to intimidate the victim into waiving the prosecution. Sometimes it is helpful to look at extremes to highlight the point: if a young child was abused by a patent, then was influenced by the parent who didn't abuse them this would be unjust.
In a more everyday case, if a woman is beaten by her partner and it is witnessed, I feel that person should be prosecuted regardless of the feelings of the victim - domestic violence, in my view, is often perpetuated because a spouse or partner will not speak up - normally because they are psychologically dependent on their abuser.
These are obviously crimes of violence. If a crime is committed against a corporation, on the other hand then I think that they should be allowed to waive the prosecution.
EME can be used to communicate with proprietary DRM components, but those DRM components are not part of the standard, and there is nothing that I've seen in EME that makes DRM the only thing it can be used for.
For instance, couldn't EME be used to make a system to protect the privacy of people sharing personal videos? Encrypt the video and upload to a web server that all the parties sharing have access to. Distribute the decryption keys to the people intended to share the video. Use EME to interface the browser to a component that uses that key to decrypt the video on the fly.
From the browser's point of view there is not really any significant difference between a video that is encrypted for DRM and one that is encrypted for privacy. In the former case those who encrypted it want to keep the key secret from the viewer, whereas in the latter case they want to keep the key secret from third parties. To the browser, these look the same: there is encrypted video, and the browser needs something to decrypt that and hand it the decrypted data for it to display.
That, sadly, isn't the case. (It would be much better if it were!) All the existing EME modules are embedded as part of the browser, and there definitely isn't any standardised API to communicate with a module external to the browser.
All EME defines is an API on HTMLMediaElement to communicate with this abstract module, which yes, would allow the case of hiding the key from third parties to be addressed.
The CDMs used by Firefox, Chrome and Opera on Windows and Mac are distinct downloadables although the browsers handle the download automatically.
The CDMs used by Chrome for Android, Edge and Safari are bundled with the underlying platform and aren't embedded in the browser (though these browsers are bundled with their platform).
If you hiding the key from person who is intended recipient you are implementing a DRM, not solution that provides privacy.
The problem that you are mentioning is already solved, and you don't need to hide key from the viewer. It happens as follows:
- content is encrypted using randomly generated symmetric key
- the key is then encrypted using asymmetric public keys of recipients
The recipient has all information necessary to decrypt the information. If your goal is to hide from the recipient the one time key that is only used for the content that the recipient supposed to be able to view, then you're implementing DRM.
Not really. If you want to use the Clear Key key system for privacy, you need to deliver the key over https. (Plain http plus Web Crypto doesn't work against an active adversary.)
To get the key over https, the hosting page needs to be https. Then, due to cross-scheme CORS being prohibited, you also have to fetch the media (MSE segments) over https.
Since https already provides privacy, Clear Key EME doesn't add privacy value beyond protecting against untrusted CDN staff. But if you deliver some JPEGs over the same CDN, you have to trust the CDN staff anyway.
Don't try to post hoc rationalize DRM-motivated constructs as privacy measures.
You simply need client-side decryption for that case, which can be done in a transparent sandbox with audited open source code.
This one still could use a tl;dr summary at the top, but the vast improvement is heartening - without good public messaging, their mission seemed very difficult. Now I feel like there's a chance.
Ultimately the w3c is doing something that is in the best interest of its participants and NOT in the interest of users, or consumers.
In this document ( http://www.w3.org/Consortium/Process/Process-19991111/backgr... ) the w3c claims:
"W3C is a non-profit organization funded partly by commercial members. Its activities remain vendor neutral, however."
Yet I can find no US IRS 990, or foreign equivalent.
Fundamentally this structure doesn't look like a non profit. It also doesn't look like it has the best interests of the community (us) as a whole in mind. IANAL but I have to wonder if it is possible to challenge the w3c on its continued use of "non-profit". I also wonder if there is a way to put pressure on them to allow non profit orgianzations free access to these committees outside of collecting a fee from them, as it strikes me as an un-needed burden.
(emphasis added above)
OK EFF I love you, but when did you start leaving end users off of your list of people you want to protect against litigious aggression?
Regular end users want to do fair-use things like pause and download too, without being sued, right?