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

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

--- Comment #22 from Fred Andrews <fredandw@live.com> ---
(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.

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

Received on Monday, 25 February 2013 23:33:33 UTC