[Bug 20965] EME results in a loss of control over security and privacy.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965

--- Comment #30 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > (In reply to comment #23)
> > > > (In reply to comment #21)
> > > > > 
> > > > > Can we reach a consensus that a UA controlled CDM can not support DRM and
> > > > > that DRM demands that the OS vendor conspire with the CDM author to limit
> > > > > the control the user has over their computer?
> > > > > 
> > > > > Can we reach a consensus that DRM is not applicable to open source stacks
> > > > > because it is not possible to limit the control the user has over their
> > > > > computer?
> > > > 
> > > > No, I don't believe either of the above are obvious. We may have different
> > > > definitions of DRM.
> > > 
> > > Could you please provide you definition of DRM?
> > > 
> > > It may be possible to avoid defining 'DRM' for the purpose of discussions
> > > but we would need some other agreed definitions.
> > > 
> > > For example: distinguish between platforms for which the user is able to
> > > implement their own web browser or OS that can store the decrypted output,
> > > versus systems for which they can not. Perhaps call these 'open' and
> > > 'proprietary'?
> > > 
> > > I believe the ball is in your court. If you do not agree with the proposed
> > > definitions then please make a proposal?
> > 
> > What proposed definitions ?
> 
> "For example: distinguish between platforms for which the user is able to
> implement their own web browser or OS that can store the decrypted output,
> versus systems for which they can not. Perhaps call these 'open' and
> 'proprietary'?"

I don't think that distinction is useful here, at least not the way you think
it is (see below).

> 
> ...
> > > 
> > > > > Can we reach consensus that DRM requires the user to trust a proprietary
> > > > > operating system or CDM hardware module?
> > > > 
> > > > No, there are also software solutions which are not part of the operating
> > > > system.
> > > 
> > > Yes, it could be in proprietary hardware.  If we expand this can we reach
> > > consensus?
> > 
> > Let me phrase it another way and see if you agree. It's certainly the
> > intention of the EME proposal that there will be CDMs that are difficult for
> > users to modify. There could be obfuscated software and/or there could be
> > hardware mechanisms that make modification of certain software or firmware
> > difficult.
> 
> I agree in part.  But a CDM running within a context controlled by a
> user controlled UA or a user controlled OS can offer no real protection
> against the decrypted output being recorded hence the 'DRM' qualification
> above.  I suggest that DRM can only be implemented in proprietary modules
> running on proprietary stacks, hence the 'proprietary' qualification
> above.  We need a definition of 'DRM' or some other term that allows
> the distinct cases so be discussed.  Could you please take a look at
> bug 21104 and see if a consensus can reached.

The things that people consider 'DRM' - or more specifically the things that
are considered useful for content protection - are more subtle than you imply.

I get the impression that you consider any solution where the UA has access to
decrypted decoded media as equivalent to a solution with a 'Save As...' option
that saves a compressed version of the media file. But these things are not the
same. 'Possible to save the content' is not the same as 'Probable that many
people will save the content'. If the standard build of the browser does not
contain the 'Save As...' functionality (including the re-encoding that this
entails) then most users will not in practice create or obtain such a build.

I'm not commenting here on the type of content for which such solutions would
be appropriate, except to say that since content requiring no protection exists
it's reasonable that there also exists content at various points on the 'level
of protection' scale in between none and full hardware protection.

My point above is just that its not correct to assume that because the UA has
access to the decrypted media in some form that this is equivalent - in terms
of use-cases - to having no protection.

Whether you call this 'DRM' or not, I don't really care - some people do - but
it's in scope of EME.

> 
>  
> > And yes, these techniques probably make it difficult for the user to
> > determine exactly what that software does. So there would be a certain
> > amount of trust required, where the user has to trust that the software in
> > question does only what is claimed by its implementor. (All assuming the
> > user wants to access the service at all).
> 
> This is part of the issue.
> 
> The other is the ability to enforce any security and privacy and this
> depends on the context in which the CDM runs so can we please try to
> define that first.

I'm missing why you expect this to be defined in the specification and not just
by UA implementors ? I don't think this is useful to describe in the
specification.

> 
> > The EME architecture places the onus on UA implementors to exercise due
> > diligence in the manner in which they integrate with CDMs. This offers an
> > opportunity for solutions where the UA implementor vouches for the safety of
> > the CDM based on their relationship with the CDM implementor. This is an
> > improvement on the situation today where the user has to trust some
> > arbitrary plugin with no guarantees from the UA.
> 
> I don't think this model is practical for the open web standards because
> the UA implementer may well be the user or an agent for the user and
> their security and privacy can not depend on a relationship with the
> CDM authors.

Why not ? You have to obtain the CDM somehow and so whatever means you use to
obtain it implies some kind of relationship - even if that is only receiving
representations from the CDM author in the documentation. If those aren't
sufficient, don't use that CDM. 

> 
> It may well be the only option for proprietary CDMs running on proprietary
> stacks, and in this case the OS vendor and CDM author would be expected
> to have a close relationship and probably restrictive licensing terms.
> 
> Thus I would like to see a separation between these distinct cases.
> 
> Henri has suggested focusing on only the DRM use cases, and this would
> simplify the discussions.

I don't really understand why such a constraint would be useful. Also, you have
to define DRM, which is obviously tricky.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 26 February 2013 16:30:42 UTC