- From: Charles Pritchard <chuck@jumis.com>
- Date: Sat, 25 Feb 2012 17:34:43 -0800
- To: Kornel Lesiński <kornel@geekhood.net>
- Cc: Henri Sivonen <hsivonen@iki.fi>, Glenn Adams <glenn@skynav.com>, MarkWatson <watsonm@netflix.com>, "public-html@w3.org" <public-html@w3.org>
On Feb 25, 2012, at 4:22 PM, Kornel Lesiński <kornel@geekhood.net> wrote:
> On Sat, 25 Feb 2012 19:20:53 -0000, Glenn Adams <glenn@skynav.com> wrote:
>
>>> > You over-generalize when you imply that one such restrictive license effectively prohibits a
>>>> meaningful use of a mechanism with a non-restrictive policy.
>>>
>>> What would be a meaningful use of the proposed mechanism with a
>>> non-restrictive policy? (HTML5 video already supports cases where the
>>> user is not treated as an adversary.)
>>
>> adversary? customers aren't usually viewed as adversaries... let's tone
>> done the hyperbole please
>
> I think in the context of the technical specification involving cryptography, Henri used the word in a technical sense:
>
> http://en.wikipedia.org/wiki/Adversary_(cryptography)
>
> From perspective of a content protection scheme that is meant to impose a policy on users watching a video, users need to be considered "adversaries", since they may try to break the protection to do something that the policy does not allow.
>
> Of course not every customer is going to try to break ("attack") the scheme, but any customer that may try to do it is _technically_ scheme's "adversary".
It is the scripting environment and related sandbox that is treated as an adversary.
The user may have a separate security system in place, in hardware, on the OS or otherwise separate.
That said, sure, it is obvious that the intentions of many parties here are not cleanly nor clearly related to user privacy.
-Charles
Received on Sunday, 26 February 2012 01:35:11 UTC