[Bug 20964] EME supports content that depends on servers with a finite life.

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

--- Comment #27 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > (In reply to comment #23)
> > > > (In reply to comment #22)
> > > ...
> > > > > I agree, but we are talking about video here, and I think many users
> > > > > would be quite happy to have a stored video to play back in future.
> > > > 
> > > > Not if it's going to cost them a lot more, they won't!
> > > > 
> > > > Many users are very happy with rental and subscriptions services which are
> > > > much cheaper than 'owning' content - precisely because users are not offered
> > > > the opportunity to store the video. I think they would be pretty upset at
> > > > the idea of technologists dictating to them that they can't have this
> > > > cheaper service just because the device they own is technically capable of
> > > > storage.
> > > 
> > > This is just not relevant to the matter at hand.  The technical fact is
> > > that the open web platform does not prevent the user storing the received
> > > video.  It is not the case that the users has to choose between a
> > > less restricted versus a more restricted UA implementation in return
> > > to more favorable terms on web services.  This may be the case with
> > > proprietary plugins or proprietary DRM-CDMs, but neither are currently
> > > part of the open web.
> > 
> > EME and CDMs are proposed to have the same role with respect to web
> > standards as <object> and plugins respectively already have.
> > 
> > My point is relevant, because the web as it exists today does - on some
> > platforms - support services where it is made difficult for users to store
> > the received video. This is an advantage because it enables business models
> > which otherwise would not be achievable on the web.
> > 
> > You seem to be mis-understanding the proposal as being one to standardize a
> > specific CDM. We're no more proposing this than to standardize a specific
> > plugin.
> 
> No, I am not under that misconception.  It is clear that the CDM is
> so poorly defined that it could be almost anything.
> 
> You seem to want the CDM defined so vaguely that the security and privacy
> implications, among other matters, can not be reviewed.

Being clear about what is and is not in scope of the specification is different
from being vague. The details of what CDMs might do are proposed to be outside
the scope of the specification, so indeed you can't draw much in the way of
specific privacy and security review that would apply to all CDMs. Just as you
cannot do much of a specific privacy and security review for all plugins.

As I have said, the job of reviewing the security a privacy implications for a
given CDM is one for UAs that choose to support it.

We can certainly provide guidance in the specification.

> 
> > I agree that if that were the proposal, then a lot more detail would be
> > needed to evaluate it, but that's not the proposal.
> 
> A lot more detail is needed anyway.
> 
> For example does the 'clear key' CDM run in the context of the UA or
> is it a 'protected' DRM OS module.  If it runs in the UA context then
> the output can be saved, so it is not DRM.  If it runs in a proprietary
> UA on an open source stack then the output can still be recorded at
> the OS level and it is not DRM.  If it needs proprietary OS support
> and is a proprietary CDM then how is it going to be implemented as
> required by all web browsers.   EME is hopelessly undefined - we do
> not know what we are talking about.

I don't understand why you need answers to these questions - these are issues
for UA implementors.

> 
> > You're welcome to make the argument that <object> and video codecs and other
> > extensibility points were a terrible mistake that should not be repeated -
> > others have also made this argument - but there does not seem to be
> > consensus on this. In fact our proposal should be seen as a step on the path
> > to removing <object> by providing a more constrained alternative to one of
> > the main use-cases for <object>.
> 
> I dispute this analogy of yours, it is not mine.  The reality is that EME
> has strong content protection as a use case, and the design and implications
> need to be addressed.  I also suggest that the only possible solutions will
> be proprietary CDMs on proprietary stacks.
> 
> > > > The way we decide which services should be available and which should not -
> > > > especially for something as discretionary as video entertainment - is by
> > > > inventing technology to support the widest range of services and letting
> > > > these compete for users. 
> > > 
> > > The open web allows users to implement their own browser.  There is no
> > > distinction between the 'technology' and the 'user', the technology serves
> > > the user.
> > > 
> > > You are conflating Netflix terms of use, or copyright restrictions, with
> > > the open web standard.
> > 
> > No, I think you are trying to assert a definition of the web that excludes
> > certain popular use-cases. As I said, the web today supports <object>, so
> > what is new ?
> 
> How are you going to implement your Netflix use-cases on open source
> stacks?
> 
> I am just suggesting the obvious: that it is not possible to implement
> the Netflix use cases on open source stacks, and trying to refocus
> on the obvious path of using proprietary CDMs on proprietary stacks,
> and to get this documented so that the implications can be explored.

Netflix runs in Firefox today. I believe it's achievable that open source
browsers could integrate with closed CDMs, either when they are part of the OS
platform or as stand-alone software components, and that this could meet our
requirements. 

>   
> > > > > > Some video services also do not require a real-time server component, but
> > > > > > others - including that of my employer, Netflix - do. Again, users of a
> > > > > > service like Netflix would be totally unsurprised at the idea that if their
> > > > > > subscription or Netflix itself expires, they can no longer enjoy the
> > > > > > content. You seem to be assuming that because a service is related to video
> > > > > > it's reasonably to expect the company offering that service to conform to
> > > > > > your preferred technical architecture - with no real-time server component.
> > > > > > It's not. We choose a different design for well-founded business reasons and
> > > > > > in alignment with common-sense user expectations. The ability to do so with
> > > > > > EME is therefore a feature and this bug should be close.
> > > > > 
> > > > > My understanding is that Netflix does not delivery protected content over
> > > > > the open web architecture, but rather requires DRM plugins, or separate
> > > > > DRM applications?  Thus there is a real difference between the current
> > > > > open web architecture and the architecture that Netflix demands in the
> > > > > EME, and this should be noted so that the working group and the wider
> > > > > community can take this into account in deciding if they want to advance
> > > > > EME.
> > > > 
> > > > Henri described quite well what's proposed, which is a change in
> > > > architecture, but not a fundamental one. Moving from plugins to CDMs has
> > > > pros and cons, yes, and I completely agree that these should be well
> > > > understood.
> > > 
> > > Henri has add a lot to discussions, and if there is something in particular
> > > that you support then please bring this forward for review?
> > 
> > http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0079.html
> 
> Thank you for the link.  I concur with Henri's comments, but note he
> mentions a 'smaller non-user-modifiable black box whose licensing
> characteristics are unknown with a narrower yet-to-be-defined API
> that integrates into <video>'  which is more specific than the EME
> specification!  He is talking about the DRM use case, yet EME does
> not even qualify its scope to DRM.  Henri says more in a few sentences
> than the whole EME specification does.
>  
> > > Proprietary plugins are not part of the open web standard, so any change
> > > to bring their functionality within is very significant.
> > 
> > Specific proprietary plugins themselves of course are not. But <object> is
> > very much part of HTML as is the concept of a plugin: 
> > 
> > http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#plugin
> > 
> > Following the same model as this - as we propose - is not a big
> > architectural departure.
> 
> Agreed, if you compare proprietary plugins to proprietary CDMs, but this
> is not the comparison being made.

Hmm, well, it's the comparison I'm making. What other kind of CDMs were you
thinking of ? Certainly Open Source DRMs have been discussed, but CDMs built
with these still require some technique to be applied to make them
difficult-to-modify.

>  
> > > > > Further a SCDM is technically incapable of delivering the restrictions
> > > > > that the Netflix service demands.  We need to clarify definitions etc
> > > > > and re-spin.
> > > > 
> > > > By SCDM do you mean 'Software' CDM ? If so, this statement is untrue. We
> > > > have several different software solutions in the market today.
> > > 
> > > Please see bug 21104 for the definition of SCDM, and no this does not
> > > mean 'software CDM' which would be too broad to be meaningful.
> > 
> > Ok. I tend to agree with the comments in that bug that the SCDM term is not
> > terribly useful.
> 
> Then would you agree to limiting EME to the DRM use cases?

I'm not sure that's necessary, useful or easy to define. Certainly, our
interest is in cases that most people would call DRM, though.

>  
> > Regarding your statement on the 'restrictions that the Netflix service
> > demands', unsurprisingly, these vary from case to case and over time, so I
> > couldn't sign up to any statement of the kind you make above.
> 
> So you reserve all privileges for the CDM making it impossible to
> defined any 'sandbox' restrictions on the CDM.

No, not at all. I don't think we should define sandbox restrictions in the
specification, but I think it likely UAs will want to define sandbox
restrictions and that UAs will approach CDMs differently depending on the
restrictions the CDM can live within.

Anyway, this is all a long way from the subject of the bug. I think we agree
that the title of the bug is a true statement. I don't think you've explained
at all why this is a problem, and indeed I see it as a feature. So, can we
close the bug ?

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

Received on Tuesday, 26 February 2013 06:07:21 UTC