[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 #26 from Mark Watson <watsonm@netflix.com> ---
(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 ?

I don't think we need a definition of DRM to progress this specification. The
specification doesn't propose a specific DRM system and this is deliberate.
Different people have different requirements and requirements change over time.

I'm completely happy with the idea of non-normative text which describes the
expected functionality of CDMs and the privacy and security issues associated
with different CDM capabilities and behaviours. This material would inform UAs
making decisions on whether and how to integrate with CDMs.

>  
> > > Can we reach a consensus that DRM could be supported in an open source
> > > web browser that uses EME to interface to a proprietary CDM that runs
> > > in a context that limits the control the user has over their computer?
> > 
> > We obviously can't limit what a user can do with their machine. DRM relies
> > on providing software or hardware components which are hard to modify whilst
> > retaining their intended functionality. That's a different thing.
> > 
> > Given that difference, then yes DRM could be supported in an open source web
> > browser that integrated with components of that kind.
> 
> Please define 'integrated with'?

http://en.wikipedia.org/wiki/Software_integration

> 
> I object to any definition of DRM that constrains a user implementation
> of a web browser or a user implementation or an operating system.
> 
> > > 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.

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).

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.

>  
> > > 
> > > Can we reach consensus that the UA has no ability to control security
> > > or privacy when using DRM?
> > 
> > No, this depends on the interface between the UA and the CDM and the
> > security and privacy properties of the CDM.
> 
> The term 'control security' may have been poorly chosen, and from
> above is seems we firstly need a definition of 'DRM' or similar
> to even discuss this further.
> 
> Can we reach consensus that the UA has no ability to enforce security
> or privacy when using DRM?

No, I don't see how changing 'control' to 'enforce' changes the situation.

> 
> This would exclude a cooperative API between the UA and CDM for
> controlling security and privacy.

Control of security and privacy are important factors in the design of the API
between UA and CDM and are things that UA implementors should explicitly
*include* in their design, IMO.

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

Received on Tuesday, 26 February 2013 00:58:04 UTC