[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 #27 from Fred Andrews <fredandw@live.com> ---
(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'?"

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


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

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

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.

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

Received on Tuesday, 26 February 2013 02:56:29 UTC