This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The videos will not be viewable once the server have been decommissioned. There is not provision for a sunset on the restrictions.
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 ***
This has nothing to do with bug 19208.
(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?
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.
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.
(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.
(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.
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.
(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.
(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.
(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.
(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.
(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.
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.
(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.
(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.
(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?
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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 ?
(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.
(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 ?
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.
(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.