[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 #19 from Joe Steele <steele@adobe.com> ---
(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.

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

Received on Monday, 25 February 2013 17:42:35 UTC