W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Open Source implementations Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

From: Charles Pritchard <chuck@jumis.com>
Date: Sat, 25 Feb 2012 22:13:48 -0800
Message-Id: <393D5B4D-1AA6-4D7B-B699-CE99338F0C39@jumis.com>
Cc: "public-html@w3.org" <public-html@w3.org>
To: Kornel Lesiński <kornel@geekhood.net>
On Feb 25, 2012, at 7:59 PM, Kornel Lesiński <kornel@geekhood.net> wrote:

> On Sun, 26 Feb 2012 01:34:43 -0000, Charles Pritchard <chuck@jumis.com> wrote:
> 
>> It is the scripting environment and related sandbox that is treated as an adversary.
> 
> The scripting environment on a page is controlled by: publisher (page source), user (bookmarklets, extensions), browser vendor and possibly others via page's vulnerabilities (XSS).
> 
> Are all of them considered adversaries then?

Extensions are controlled by authors. Few users have the time or ability to analyze the source code of extensions.

Yes, in the scheme of high security content protection, extensions are adversaries.


> Can you clarify what do you mean by "related sandbox"?

You covered it.


> 
>> The user may have a separate security system in place, in hardware, on the OS or otherwise separate.
> 
> How does this security system establish chain of trust? Where does the chain end (Content Decryption Module, browser, OS, display)?

It's undefined. For the purposes of a UA, it ends with the OS, and that's what the proposal ends with as well.

The same applies to accessibility. The UA does not know what or why it is sending content from the DOM and scripting environment out to the OS.

The user defines the experience at that point. They may have a unique display device; a Braille display, a speech synth, a touch and speak system.

The same applies for this chain of trust. The user may have hardware, software or a combination.

And just as with AT, it may be implemented entirely in the UA-- such as with ChromeVox and Chrome OS.


> 
>> That said, sure, it is obvious that the intentions of many parties here are not cleanly nor clearly related to user privacy.
> 
> Sorry, I don't understand how this relates to whether user is an adversary for the scheme or not.

Prohibiting fair and legitimate use of content is adversarial. Thus the cat and mouse game of DVD and Blu-ray obfuscation.

At the same time, enforcing content security, on behalf of the user, so their content consumption is not intercepted, or on behalf of the user's obligations to keep content secure and private, those are cooperative measures.

There are many instances of data leaks from govt and corporate machines that fall into that latter category; there are many instances of unwelcome hacking and wiretapping as well.

Technology is neutral -- it can be used and abused-- I'd like the group to give this proposal a full analysis to ensure it can be used for the benefit of privacy. I know it will be analyzed for the benefit of general consumer content publishers and distributors.

Accessibility has popped up a few times in this thread; I hope my examples help to demonstrate why.

I've seen a developer claim that restricting authors from developing accessible applications (with the Canvas 2d API) is a good thing. I disagree with those developers, though I do not doubt their good intentions.

In this case, a similar group of developers is looking to restrict message passing-- just as they want to restrict passing messages from the scripting environment to the OS accessibility API, they want to restrict passing messages from the scripting environment to the OS key management API.



-Charles
Received on Sunday, 26 February 2012 06:14:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:30 UTC