Bug 20964 - EME supports content that depends on servers with a finite life.
EME supports content that depends on servers with a finite life.
Status: RESOLVED WORKSFORME
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
PC Windows NT
: P2 normal
: ---
Assigned To: Adrian Bateman [MSFT]
HTML WG Bugzilla archive list
:
Depends on: 21104
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-12 02:29 UTC by Fred Andrews
Modified: 2013-02-26 23:39 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fred Andrews 2013-02-12 02:29:45 UTC
The videos will not be viewable once the server have been decommissioned.  There is not provision for a sunset on the restrictions.
Comment 1 Adrian Bateman [MSFT] 2013-02-12 13:44:15 UTC
I think this is a duplicate of bug 19208. This will resolve the situation when the system already has a key and can play content without needing to contact the server.

*** This bug has been marked as a duplicate of bug 19208 ***
Comment 2 Fred Andrews 2013-02-12 20:22:45 UTC
This has nothing to do with bug 19208.
Comment 3 Henri Sivonen 2013-02-18 06:50:04 UTC
(In reply to comment #0)
> The videos will not be viewable once the server have been decommissioned. 
> There is not provision for a sunset on the restrictions.

How is this relevant for a specification that addresses streaming use cases similar to Netflix's? The streams themselves will be unavailable if the streaming service is decommissioned.

Is EME meant to address cases where the media files don't come immediately from an online service such as Netflix but have been "bought" by the user and stored on the user's system ahead of time?
Comment 4 Mark Watson 2013-02-19 16:14:27 UTC
In answer to Henri's question, we have focussed exclusively on the streaming use-case.

However, there is nothing in the EME specification which prevents a server granting a license with no expiration date or preventing a CDM or a client application from storing that license and using it at some later data, potentially after the server which issued it has been decommissioned.

As a result if a service wishes its content to remain available after the server has been decommissioned, this is possible.

I suggest we close this as a non-issue.
Comment 5 Fred Andrews 2013-02-19 20:53:54 UTC
Firstly, the notion of 'streaming' is an artificial construct of the DRM industry that has no technical foundation and is foreign to the working of the web browser.  Web browsers are free to store content to their capacity for presentation at the will of the user.  If videos content authors wish to present content on the web browser then they need to respect the operation of the platform rather than attempting to re-purpose it for their own market segmentation goals.

Secondly, the possible existence of one 'unrestricted' CDM model does not discount the fact that the EME interface frustrates the viewing of content without a live server.  Further, we need to keep in mind the legal constraint that in some jurisdictions normal web browser storage and presentation operations that works around such 'frustrations' may well be illegal and we have a duty of care to web users not to expose them to such threats.

In summary, the technical existence of any mode of operation that frustrates the viewing of content after server has been decommissioned is a problem.
Comment 6 Joe Steele 2013-02-21 22:56:45 UTC
(In reply to comment #5)
> Firstly, the notion of 'streaming' is an artificial construct of the DRM
> industry that has no technical foundation and is foreign to the working of
> the web browser.  Web browsers are free to store content to their capacity
> for presentation at the will of the user.  If videos content authors wish to
> present content on the web browser then they need to respect the operation
> of the platform rather than attempting to re-purpose it for their own market
> segmentation goals.

You may be thinking only of streaming video in the VOD (video on demand) model. There are other use cases for streaming video, e.g. low latency live/near-live events, variable bitrate, large scale viewing, etc. This method for delivering content is useful entirely independent of whether or not DRM is in use.

> 
> Secondly, the possible existence of one 'unrestricted' CDM model does not
> discount the fact that the EME interface frustrates the viewing of content
> without a live server.  Further, we need to keep in mind the legal
> constraint that in some jurisdictions normal web browser storage and
> presentation operations that works around such 'frustrations' may well be
> illegal and we have a duty of care to web users not to expose them to such
> threats.
> 
> In summary, the technical existence of any mode of operation that frustrates
> the viewing of content after server has been decommissioned is a problem.
Comment 7 Fred Andrews 2013-02-21 23:44:21 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Firstly, the notion of 'streaming' is an artificial construct of the DRM
> > industry that has no technical foundation and is foreign to the working of
> > the web browser.  Web browsers are free to store content to their capacity
> > for presentation at the will of the user.  If videos content authors wish to
> > present content on the web browser then they need to respect the operation
> > of the platform rather than attempting to re-purpose it for their own market
> > segmentation goals.
> 
> You may be thinking only of streaming video in the VOD (video on demand)
> model. There are other use cases for streaming video, e.g. low latency
> live/near-live events, variable bitrate, large scale viewing, etc. This
> method for delivering content is useful entirely independent of whether or
> not DRM is in use.

I agree, 'streaming could be defined in many of these ways independently of DRM, but these definitions would not be the artificially restrictive definitions used in conjunction with DRM.

For example, in all the examples you give above the UA is able to store the content and to control the presentation to be best of its ability, and this gives the user a choice to view the content even after the server is decommissioned.  

Granted, that if the user chose to only download a low bit rate version of the content and this was stored, and the server was subsequently decommissioned, then the user would not have access to the high bit rate version from the server.  But this is the case even for access to HTML content requiring authorization.

The artificial 'streaming' restriction supported by the EME model does not give the user the choice to view content already received after the server is decommissioned.  Granted, a particular CDM may not place this restriction on content, but this is not the point - the EME standard should not ALLOW such restrictions.

If the back channel was removed from the EME, or if it was a defined and transparent channel for content selection then many of the issue would be resolved and EME would be a better prospect for fitting within the web architecture.  For example, a back channel that allows a request for a change in the bit rate to be sent to the server would likely be consistent with the web architecture, and so would a back channel that was used to request the next segment of a video.  The UA would be able to store the received content and replay it even after the server was decommissioned.
Comment 8 Mark Watson 2013-02-22 03:50:43 UTC
A 'streaming' service such as ours does not allow the storage of the content for later viewing, even though the platform may be capable of this. It's just not part of the service we offer - the user hasn't paid for that, has agreed in the terms of conditions that they won't do that and we haven't bought the license for that.

There's no technical or political issue here - it's just the business decision we've made and the service we offer. We could spend money on licenses that allow storage and offline viewing, but we feel that money is better spend on offering more variety of content. A competitor could take a different view and the customers would decide what they preferred.

There's no 'artificial' construct here that you can expect to change just due to technical capabilities.

Returning to the subject of the bug, as I mentioned before it's not true that *EME* requires that license servers be available to view the content. A *service* such as ours may require that - for the reasons above - but another service may not. In our case, with respect to this issue, EME is doing nothing more than making it difficult for users to do something they've already agreed not to by signing up to the service.
Comment 9 Henri Sivonen 2013-02-22 08:27:17 UTC
(In reply to comment #8)
> Returning to the subject of the bug, as I mentioned before it's not true
> that *EME* requires that license servers be available to view the content.

Do you mean persistently storing data once received through createSession() or update()? Persistently storing that data comes with another set of problems. See bug 20965 comment 9.
Comment 10 Fred Andrews 2013-02-22 13:06:33 UTC
(In reply to comment #8)
> A 'streaming' service such as ours does not allow the storage of the content
> for later viewing, even though the platform may be capable of this. It's
> just not part of the service we offer - the user hasn't paid for that, has
> agreed in the terms of conditions that they won't do that and we haven't
> bought the license for that.
> 
> There's no technical or political issue here - it's just the business
> decision we've made and the service we offer. We could spend money on
> licenses that allow storage and offline viewing, but we feel that money is
> better spend on offering more variety of content. A competitor could take a
> different view and the customers would decide what they preferred.
> 
> There's no 'artificial' construct here that you can expect to change just
> due to technical capabilities.

If the back channel is removed then you no longer have a capacity to
verify or enforce such licensing terms and then what the user does
in their own privacy with the bits of data you send to them becomes a
private matter for the user.
 
> Returning to the subject of the bug, as I mentioned before it's not true
> that *EME* requires that license servers be available to view the content. A
> *service* such as ours may require that - for the reasons above - but
> another service may not. In our case, with respect to this issue, EME is
> doing nothing more than making it difficult for users to do something
> they've already agreed not to by signing up to the service.

I agree that some CDM instances need not depend on license servers for viewing.  However the EME interface is designed to support this, and it
is clear that this is the expected use case.

You appear to be acknowledging this bug is a real issue, but that
you would not want it fixed because it is inherent in your business
model terms.

I presume it is inherent in your technical model that the CDM
dictates if the output can be stored irrespective of the UA or EME?
It may help people understand the scope of EME if such constraints
were articulated in the EME specification. For example: 'Many use
cases require that the CDM have privileged control over the
storage of the CDM output, in particular usage terms that do
not allow the storage of video output for replay at a future
time.'  This would then relate to bug 20961 as many platforms
would not support this requirement.
Comment 11 Mark Watson 2013-02-22 15:39:21 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Returning to the subject of the bug, as I mentioned before it's not true
> > that *EME* requires that license servers be available to view the content.
> 
> Do you mean persistently storing data once received through createSession()
> or update()? Persistently storing that data comes with another set of
> problems. See bug 20965 comment 9.

CDMs persistently storing data is something we have not ruled out and indeed the privacy aspects need to be understood. I'll follow up on this under 20965.

Another possibility is that the web application itself persistently stores the license message. If the license does not expire it could be reused. This is just to say that services which enable access to content without license server interaction every time can be designed with EME.
Comment 12 Mark Watson 2013-02-22 15:51:15 UTC
(In reply to comment #10)
> (In reply to comment #8)
> > A 'streaming' service such as ours does not allow the storage of the content
> > for later viewing, even though the platform may be capable of this. It's
> > just not part of the service we offer - the user hasn't paid for that, has
> > agreed in the terms of conditions that they won't do that and we haven't
> > bought the license for that.
> > 
> > There's no technical or political issue here - it's just the business
> > decision we've made and the service we offer. We could spend money on
> > licenses that allow storage and offline viewing, but we feel that money is
> > better spend on offering more variety of content. A competitor could take a
> > different view and the customers would decide what they preferred.
> > 
> > There's no 'artificial' construct here that you can expect to change just
> > due to technical capabilities.
> 
> If the back channel is removed then you no longer have a capacity to
> verify or enforce such licensing terms and then what the user does
> in their own privacy with the bits of data you send to them becomes a
> private matter for the user.

Right, and that would be a different service from the one we offer today. Probably with a different price and much more limited set of content.

Because we want to support our service as it is today, we need the license server interaction for every streaming session. Hence the proposal is the way it is.

>  
> > Returning to the subject of the bug, as I mentioned before it's not true
> > that *EME* requires that license servers be available to view the content. A
> > *service* such as ours may require that - for the reasons above - but
> > another service may not. In our case, with respect to this issue, EME is
> > doing nothing more than making it difficult for users to do something
> > they've already agreed not to by signing up to the service.
> 
> I agree that some CDM instances need not depend on license servers for
> viewing. 

Ok, so we can close this bug then. Or at least you need to change the subject.

 However the EME interface is designed to support this, and it
> is clear that this is the expected use case.
> 

Sure.

> You appear to be acknowledging this bug is a real issue, but that
> you would not want it fixed because it is inherent in your business
> model terms.

I agree that EME can support services that depend on license servers. I don't agree that is an 'issue'.

> 
> I presume it is inherent in your technical model that the CDM
> dictates if the output can be stored irrespective of the UA or EME?

In our systems today, the equivalent of the CDM outputs the media directly to the rendering devices. I believe it's part of our terms and conditions that the users does not modify these devices to record the content.

> It may help people understand the scope of EME if such constraints
> were articulated in the EME specification. For example: 'Many use
> cases require that the CDM have privileged control over the
> storage of the CDM output, in particular usage terms that do
> not allow the storage of video output for replay at a future
> time.'  This would then relate to bug 20961 as many platforms
> would not support this requirement.

Obviously, at some point the media exits the CDM in some form and *technically* the only control the CDM has over what happens to it then is what the receiver of the media offers to the CDM, up to the point that the CDM trusts that part of the system to do what it says.

There are scenarios in which there are no *technical* protections on the media after it exits the CDM. The protections are in the terms of service the user has agreed to and the fact that it is technically difficult to do other things with the media at that point. Thus EME does not *require* technical protections on the media after it exits the CDM.

Of course there are platforms which do offer such protections - the easiest example being completely closed platforms such as most TVs - and on these platforms the range and quality of content available might be different.
Comment 13 Fred Andrews 2013-02-22 22:29:47 UTC
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #8)
> > I agree that some CDM instances need not depend on license servers for
> > viewing. 
> 
> Ok, so we can close this bug then. Or at least you need to change the
> subject.

It is the proponents who are conflating the non-DRM case with DRM case
and making this review so difficult.  If you split out the non-DRM
case from the DRM case, then it might well be possible to close some
of these issues against the non-DRM case, but these issues may
still stand against the DRM case.

The subject has been trivially modified to be more specific.

This bug could clearly only be closed if *no* CDMs required
the licensing server to be live for viewing content.
 
>  However the EME interface is designed to support this, and it
> > is clear that this is the expected use case.
> > 
> 
> Sure.

So you agree that this bug is not resolved.
 
> > You appear to be acknowledging this bug is a real issue, but that
> > you would not want it fixed because it is inherent in your business
> > model terms.
> 
> I agree that EME can support services that depend on license servers. I
> don't agree that is an 'issue'.
> 
> > 
> > I presume it is inherent in your technical model that the CDM
> > dictates if the output can be stored irrespective of the UA or EME?
> 
> In our systems today, the equivalent of the CDM outputs the media directly
> to the rendering devices. I believe it's part of our terms and conditions
> that the users does not modify these devices to record the content.

So 
 
> > It may help people understand the scope of EME if such constraints
> > were articulated in the EME specification. For example: 'Many use
> > cases require that the CDM have privileged control over the
> > storage of the CDM output, in particular usage terms that do
> > not allow the storage of video output for replay at a future
> > time.'  This would then relate to bug 20961 as many platforms
> > would not support this requirement.
> 
> Obviously, at some point the media exits the CDM in some form and
> *technically* the only control the CDM has over what happens to it then is
> what the receiver of the media offers to the CDM, up to the point that the
> CDM trusts that part of the system to do what it says.
> 
> There are scenarios in which there are no *technical* protections on the
> media after it exits the CDM. The protections are in the terms of service
> the user has agreed to and the fact that it is technically difficult to do
> other things with the media at that point. Thus EME does not *require*
> technical protections on the media after it exits the CDM.

Well then lets specify that the CDM does run in a sandbox.  Further
in the interests of catering for a wide range of business cases,
lets extend EME to support the capture of the CDM output - some
business terms may want to sell such extra-high value licenses to
users.   Oops now there is not DRM, and we can forget about EME.

You need to clarify the scope of the CDM and the architecture you
propose so that it can be reviewed.  I do not believe any progress
can be made resolving these bugs without such clarification.
Comment 14 Joe Steele 2013-02-23 01:22:06 UTC
It is reasonable to stipulate that the EME supports content that depends on servers with a finite life. However since it also supports content that does *not* rely on servers with a finite life, there is a clear provision for a sunset on the restrictions. This does not seem to be a bug. 

If this were a bug, I think you would agree it would make sense to prevent this in other aspects of the Web Platform. However I could generate dynamic content using the existing Web Platform that would have this restriction, i.e. when the server goes away the content will not be viewable any more without further user circumvention. It would not meet our requirements in other respects (performance, compatibility with existing technology, difficulty of circumvention, etc.) but it would exhibit the behavior you are describing.
Comment 15 Fred Andrews 2013-02-23 02:07:00 UTC
(In reply to comment #14)
> It is reasonable to stipulate that the EME supports content that depends on
> servers with a finite life. However since it also supports content that does
> *not* rely on servers with a finite life, there is a clear provision for a
> sunset on the restrictions. This does not seem to be a bug. 
> 
> If this were a bug, I think you would agree it would make sense to prevent
> this in other aspects of the Web Platform. However I could generate dynamic
> content using the existing Web Platform that would have this restriction,
> i.e. when the server goes away the content will not be viewable any more
> without further user circumvention. It would not meet our requirements in
> other respects (performance, compatibility with existing technology,
> difficulty of circumvention, etc.) but it would exhibit the behavior you are
> describing.

I challenge you to think of an example that shows that 'generate dynamic content using the existing Web Platform that would have this restriction'?

I do not believe it is possible.  The UA can store the computed DOM, the rendered pixels, etc and replay it in future without the server being live.

Being able to 'use' a dynamic web page may require access to a server, but this is different matter.  Obviously a cloud web service is no longer usable after the server is decommissioned, but content obtained from such as service is.

For example, a web server offering videos is not accessible after the server is decommissioned, but the downloaded videos are still viewable if not for DRM limitations.

The working group may wish to close this as 'won't fix', but that is a decision for them, and I would like it to be presented accurately to the working group and for their decision to be recorded.
Comment 16 Mark Watson 2013-02-23 02:15:05 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #10)
> > > (In reply to comment #8)
> > > I agree that some CDM instances need not depend on license servers for
> > > viewing. 
> > 
> > Ok, so we can close this bug then. Or at least you need to change the
> > subject.
> 
> It is the proponents who are conflating the non-DRM case with DRM case
> and making this review so difficult.  If you split out the non-DRM
> case from the DRM case, then it might well be possible to close some
> of these issues against the non-DRM case, but these issues may
> still stand against the DRM case.
> 
> The subject has been trivially modified to be more specific.

The subject now reflects a fact on which we seem to agree.

My view is that this is not a bug, but a feature. And so we should close this bug. As Joe points out it's also true of the web platform as a whole.

> 
> This bug could clearly only be closed if *no* CDMs required
> the licensing server to be live for viewing content.
>  
> >  However the EME interface is designed to support this, and it
> > > is clear that this is the expected use case.
> > > 
> > 
> > Sure.
> 
> So you agree that this bug is not resolved.

No, see above.

> 
> You need to clarify the scope of the CDM and the architecture you
> propose so that it can be reviewed.  I do not believe any progress
> can be made resolving these bugs without such clarification.

It's not the object this specification to define precisely what CDMs can and cannot do or precisely what the interface between CDM and UA should be. You seem to think that this is something we should define. I'd suggest opening another bug "EME should define precisely the functions performed by CDMs" and explain why you think that.

The kind of review you seem to wish to perform here should be done by UA implementors when they consider whether to integrate a given CDM. I have no problem including text that highlights things that they should consider but ultimately it is up to them.
Comment 17 Fred Andrews 2013-02-23 12:34:07 UTC
(In reply to comment #16)
...
> My view is that this is not a bug, but a feature. And so we should close
> this bug. As Joe points out it's also true of the web platform as a whole.

Joe has been challenged to prove this claim and has not done so. You
are welcome to addess this challenge?  Please demonstrate how the
web platform can currently prevent the user storing content received
and presenting it in the future when the server from which the content
was received is no longer accessible?
Comment 18 Fred Andrews 2013-02-23 13:04:34 UTC
(In reply to comment #16)
> (In reply to comment #13)
> > (In reply to comment #12)
...
> > You need to clarify the scope of the CDM and the architecture you
> > propose so that it can be reviewed.  I do not believe any progress
> > can be made resolving these bugs without such clarification.
> 
> It's not the object this specification to define precisely what CDMs can and
> cannot do or precisely what the interface between CDM and UA should be. You
> seem to think that this is something we should define. I'd suggest opening
> another bug "EME should define precisely the functions performed by CDMs"
> and explain why you think that.
> 
> The kind of review you seem to wish to perform here should be done by UA
> implementors when they consider whether to integrate a given CDM. I have no
> problem including text that highlights things that they should consider but
> ultimately it is up to them.

There are already a range of open bugs that require clarification
to be able to make progress.  For example, enough detail to be able
to assess the security and privacy implications, and enough detail
to be able to decide if 'strong DRM' is possible on open source
stacks.

The community also needs enough information to decide if this
specification should even advance.  Detailing the scope in more
detail would help.   For example, noting that 'strong DRM' will
not be possible on open source stacks, etc would help in
deciding if EME is an appropriate 'open' standard.
Comment 19 Joe Steele 2013-02-25 17:42:34 UTC
(In reply to comment #17)
> (In reply to comment #16)
> ...
> > My view is that this is not a bug, but a feature. And so we should close
> > this bug. As Joe points out it's also true of the web platform as a whole.
> 
> Joe has been challenged to prove this claim and has not done so. You
> are welcome to addess this challenge?  Please demonstrate how the
> web platform can currently prevent the user storing content received
> and presenting it in the future when the server from which the content
> was received is no longer accessible?

My response to your challenge is not going to be very satisfying I am afraid. I don't have any magic secret bullet. However I intentionally did not set a very high bar. See my text "without further user circumvention".

Since UA's by default (at least none I know of) do not store a continuous capture of Canvas or DOM information, someone would have to create a circumvention tool. In this case it would be fairly straightforward, they could simply rebuild a UA they had source for to include this functionality. They could also inject script into the page and alter the user agent to defeat whatever UA detection mechanism the application writer has put into place. 

The end user does not have to create this tool, merely use it. But this puts them on the same footing as someone trying to defeat a more obfuscated version of DRM relying on an obfuscated binary or hardware. It is only a difference in degree of difficulty for the initial circumvention and the acquisition of the circumvention tool, between a solution based entirely on the Web Platform as-is and the mechanism proposed by EME. However this degree of difficulty is the critical concern for content providers wishing to protect their content. 

A trivial example of what I mean is the practice of denying "View Source" on a web page. Easy to circumvent for anyone at all experienced, but not automatic.
Comment 20 Fred Andrews 2013-02-25 22:33:06 UTC
(In reply to comment #19)
> (In reply to comment #17)
> > (In reply to comment #16)
> > ...
> > > My view is that this is not a bug, but a feature. And so we should close
> > > this bug. As Joe points out it's also true of the web platform as a whole.
> > 
> > Joe has been challenged to prove this claim and has not done so. You
> > are welcome to addess this challenge?  Please demonstrate how the
> > web platform can currently prevent the user storing content received
> > and presenting it in the future when the server from which the content
> > was received is no longer accessible?
> 
> My response to your challenge is not going to be very satisfying I am
> afraid. I don't have any magic secret bullet. However I intentionally did
> not set a very high bar. See my text "without further user circumvention".

In other words your definition of 'circumvention' is so broad that
you are really not saying anything.  However I would not that you
used you statement of 'nothing' to back 
 
> Since UA's by default (at least none I know of) do not store a continuous
> capture of Canvas or DOM information, someone would have to create a
> circumvention tool. In this case it would be fairly straightforward, they
> could simply rebuild a UA they had source for to include this functionality.
> They could also inject script into the page and alter the user agent to
> defeat whatever UA detection mechanism the application writer has put into
> place. 

The intention of the open web platform is that anyone can build their
own UA, so the above argument is not constructive.
 
> The end user does not have to create this tool, merely use it. But this puts
> them on the same footing as someone trying to defeat a more obfuscated
> version of DRM relying on an obfuscated binary or hardware.

It is completely ridiculous to suggest that a requirement that
open web standards can be independently implemented amounts to
circumvention of DRM.   This is just not constructive.

> It is only a
> difference in degree of difficulty for the initial circumvention and the
> acquisition of the circumvention tool, between a solution based entirely on
> the Web Platform as-is and the mechanism proposed by EME. However this
> degree of difficulty is the critical concern for content providers wishing
> to protect their content. 

It is not just a 'difference in degree of difficulty' - a web browser
is specified without restrictions on storing the content.
 
> A trivial example of what I mean is the practice of denying "View Source" on
> a web page. Easy to circumvent for anyone at all experienced, but not
> automatic.

Calling normal use of a web browser 'circumvention' is ridiculous and
not constructive.
Comment 21 Mark Watson 2013-02-25 22:49:26 UTC
(In reply to comment #17)
> (In reply to comment #16)
> ...
> > My view is that this is not a bug, but a feature. And so we should close
> > this bug. As Joe points out it's also true of the web platform as a whole.
> 
> Joe has been challenged to prove this claim and has not done so. You
> are welcome to addess this challenge?  Please demonstrate how the
> web platform can currently prevent the user storing content received
> and presenting it in the future when the server from which the content
> was received is no longer accessible?

You have a rather narrow definition of 'content'.

A user who plays a Facebook game whilst browsing facebook.com, for example, likely considers the game part of the 'content' of the page. That user would be totally unsurprised at the idea that the game is only available for as long as Facebook servers are available. The mooted ability to make a recording of the gameplay for later enjoyment might be rather underwhealming.

The point is that the creator of a game or anything else on the web decides the functional split between client and server. Only services with no real-time server component - and there are plenty of games and other things like this - remain available to the user when the servers are no longer available.

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.
Comment 22 Fred Andrews 2013-02-25 23:33:32 UTC
(In reply to comment #21)
> (In reply to comment #17)
> > (In reply to comment #16)
> > ...
> > > My view is that this is not a bug, but a feature. And so we should close
> > > this bug. As Joe points out it's also true of the web platform as a whole.
> > 
> > Joe has been challenged to prove this claim and has not done so. You
> > are welcome to addess this challenge?  Please demonstrate how the
> > web platform can currently prevent the user storing content received
> > and presenting it in the future when the server from which the content
> > was received is no longer accessible?
> 
> You have a rather narrow definition of 'content'.

We are talking about video here, so it seems quite appropriate to
note a difference related to video content.
 
> A user who plays a Facebook game whilst browsing facebook.com, for example,
> likely considers the game part of the 'content' of the page. That user would
> be totally unsurprised at the idea that the game is only available for as
> long as Facebook servers are available. The mooted ability to make a
> recording of the gameplay for later enjoyment might be rather underwhealming.
> 
> The point is that the creator of a game or anything else on the web decides
> the functional split between client and server. Only services with no
> real-time server component - and there are plenty of games and other things
> like this - remain available to the user when the servers are no longer
> available.

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

Further a SCDM is technically incapable of delivering the restrictions
that the Netflix service demands.  We need to clarify definitions etc
and re-spin.
Comment 23 Mark Watson 2013-02-26 00:39:26 UTC
(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #17)
> > > (In reply to comment #16)
> > > ...
> > > > My view is that this is not a bug, but a feature. And so we should close
> > > > this bug. As Joe points out it's also true of the web platform as a whole.
> > > 
> > > Joe has been challenged to prove this claim and has not done so. You
> > > are welcome to addess this challenge?  Please demonstrate how the
> > > web platform can currently prevent the user storing content received
> > > and presenting it in the future when the server from which the content
> > > was received is no longer accessible?
> > 
> > You have a rather narrow definition of 'content'.
> 
> We are talking about video here, so it seems quite appropriate to
> note a difference related to video content.
>  
> > A user who plays a Facebook game whilst browsing facebook.com, for example,
> > likely considers the game part of the 'content' of the page. That user would
> > be totally unsurprised at the idea that the game is only available for as
> > long as Facebook servers are available. The mooted ability to make a
> > recording of the gameplay for later enjoyment might be rather underwhealming.
> > 
> > The point is that the creator of a game or anything else on the web decides
> > the functional split between client and server. Only services with no
> > real-time server component - and there are plenty of games and other things
> > like this - remain available to the user when the servers are no longer
> > available.
> 
> 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.

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. 

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

> 
> 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.
Comment 24 Fred Andrews 2013-02-26 01:17:31 UTC
(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.

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

Proprietary plugins are not part of the open web standard, so any change
to bring their functionality within is very significant.

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

I repeat my suggestion to try and reach consensus on some definitions
otherwise we are just talking past each other.
Comment 25 Mark Watson 2013-02-26 03:10:59 UTC
(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.

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.

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

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

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

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

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

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.

> 
> I repeat my suggestion to try and reach consensus on some definitions
> otherwise we are just talking past each other.

Aside from the proposals in 21104 - which did not attract much support - what terms do you propose we need to define ?
Comment 26 Fred Andrews 2013-02-26 04:18:35 UTC
(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.

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

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

> > I repeat my suggestion to try and reach consensus on some definitions
> > otherwise we are just talking past each other.
> 
> Aside from the proposals in 21104 - which did not attract much support -
> what terms do you propose we need to define ?

We seem to be talking past each other a lot so more would probably help.
Bug 21104 seems to be a core one and we may need it resolved first.
Comment 27 Mark Watson 2013-02-26 06:07:19 UTC
(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 ?
Comment 28 Adrian Bateman [MSFT] 2013-02-26 16:37:37 UTC
Discussed in the telcon.
http://www.w3.org/2013/02/26-html-media-minutes.html

Agreed it is a feature of EME that "EME supports content that depends on servers with a finite life." Resolved, by design.
Comment 29 Fred Andrews 2013-02-26 23:39:11 UTC
(In reply to comment #28)
> Discussed in the telcon.
> http://www.w3.org/2013/02/26-html-media-minutes.html
> 
> Agreed it is a feature of EME that "EME supports content that depends on
> servers with a finite life." Resolved, by design.

There was never any dispute that the EME specification is designed to support such use, the issue was that this 'feature' is not currently supported by the web platform and thus may be inappropriate as part of the open web standards or at the least needs to be noted as an significant impact.

I would note that Joe and Mark both appeared to have recognized this
as they supported the position that the current web platform does support
this use case.  They were both challenged to prove the technical merits of
their position and failed to do so.

I made a good faith effort to try and reach some consensus
on technical definitions, see bug 21104, to help clear the
frustrated discussions and note that the 'task force' has
closed bug 21104 refusing to engage in this process.

The failure of the 'task force' to understand or recognize
this issue raises a concern about the competence of the
'task force' or that they are acting in good faith.