RE: Title and description of this group may mislead.

> Date: Thu, 14 Mar 2013 15:38:59 +0000
> From: gerv@mozilla.org
> To: fredandw@live.com
> CC: public-restrictedmedia@w3.org
> Subject: Re: Title and description of this group may mislead.
> 
> On 14/03/13 01:02, Fred Andrews wrote:
> > There is no dispute that sever owners have a right to limit access
> > to served content and there are non-DRM, unencumbered, open
> > web technologies, already available to meet these needs. 
> 
> Perhaps you could enumerate them, to illuminate the discussion?
> 
> Do you mean "usernames and passwords"?

Yes, usernames and passwords are one approach.

There would appear to be no need to 'enumerate' them as
the existence of just one unencumbered solution is adequate
to be able to prove that access control can be solved with
unencumbered solutions.

The proponents of DRM may well want to use privileged storage
on the users computer to store an ID or key that is unique to
the device or user for use in access control to the server, but
this is a distinct use case from seeking to control the use of
data once downloaded.
 
> > I suggest that the only disputed technology is 'strong DRM' and that
> > the title and purpose of this group should reflect this.
> 
> How would you distinguish "strong DRM" from "weak DRM", and determine
> what sort falls into what category?

I did not mention the term 'weak DRM', but it might be useful to
define it as ineffective DRM.  For example a web browser that
tries to stop users saving a video stream at the user process
level when the stream can be trivially saved at the OS level
unknown to the web browser.  For example, content use
restrictions built into a default build of an open source web
browser that can be trivially avoided by installing a third party
build of the same web browser without the restrictions.

Strong DRM uses encumbered components in the data path
to restrict the ability of the user to control their own computer.
For video content this requires that the user can not access
the decoded video path through the platform.

Bug 21104 tried to build consensus on such a definition
but the task force responsible for the EME refused to
cooperate, see:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21104

Bug 21231 seeks to make a distinction between EME use
cases that do not depended on strong DRM and suggests
much simpler and unencumbered solutions to these, see:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21231

Another useful definition might be that if a user is free to
take an open web standard and write their own implementation
with the expectation that it will work and be interoperable
and without depending on encumbered technology then
they would also be able to add a capability to save the
decoded content and thus content use restrictions would
not be effective for such standards.  In other words a
complete open standard does not support strong DRM.

cheers
Fred