W3C home > Mailing lists > Public > site-comments@w3.org > April 2017

[DRM] On a reasonable implementation

From: Joshua Hudson <joshudson@gmail.com>
Date: Mon, 03 Apr 2017 08:03:52 +0000
Message-Id: <CA+jjjYQBcrPfdAJNviK16QG6yA2s5tjSsnm88rLsDj_O8yptDw@mail.gmail.com>
To: site-comments@w3.org
I saw the news on the call for mass phone calls to oppose DRM. I
decided it wise to offer a completely different stance.

What has really enraged people is not the inability to copy media; but
rather the inability to provide decent cross-platform support. I am on
a rather strange platform myself due to limiting ADA bugs (in fact
your regional contact map is not usable here for reasons I don't

I propose the following: define a P-Code VM with a very well-defined
set of specifications, that leaks only limited information about its
host platform.

The VM should have access to the following channels:
* Video Output
* Audio Output
* Video Input
* Audio Input
* Web Sockets (there's a javascript standard for this; might as well use it)
* (if UDP multicast is still a thing might as well find a way to allow it)

Security: If Video/Audio input is disabled by the host (and this
should always be possible) present the logical equivalent to unplugged

The VM should not have access to most of the local filesystem, but
making HTML local storage work is reasonable. The VM should receive an
implementation designation string; this does not identify the browser
but rather the VM library component implementation and version. [This
makes it possible to work around bugs in a specific version]. Version
should be a single int64 number where X.Y.Z.P is packed as 4 int16
numbers to limit the amount of code required to get version range
checks correct.

Making CPU speed and presence of certain well-known hardware decoders
is also reasonable. The hardware list should be kept short but here is
a reasonable list
* MP3
* MP4
* H.264
* Theora/Vorbis

(notice this list is drawn from the HTML5 list but MP3/4 is added as
hardware decoders are already common form these).
Received on Monday, 3 April 2017 08:05:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 3 April 2017 08:05:51 UTC