Re: WebVR and DRM

You must have missed the part where Oculus/Facebook found that the
restrictions DRM imparts on their VR Netflix app that they decided to
degrade to 720p because that they could get into their player without DRM
and do the things they needed to do. You must also have missed the part
where there was a lot of explanation about why a WebGL context needs to
access the video texture for good UX and a pleasant experience. It's a
recurring topic that DRM advocates downplay the detrimental impact DRM has
on the user experience and ignore all sound technical arguments against it.

On Tue, Jul 11, 2017 at 4:53 PM, John Foliot <john.foliot@deque.com> wrote:

> > DRM is particularly problematic as it is built on a poor engineering
> foundation and has an outsized negative effect on those who are already
> marginalized by the way it blocks accessibility tools and other measures
> that are otherwise legally protected under fair use.
>
> I really do have to speak up here.
>
I really wish there was less DRM advocates invading technical threads
outside their area of expertise lobbying for big company interests, but I
digress.


> As someone who has dedicated close to 20 years advocating for, and working
> towards digital inclusion and an accessible web, I really must protest how
> anti-DRM advocates at the W3C keep playing the "accessibility fear" card.
> Lets clear up some facts (please).
>
Ahyes, that trope. Whatever you say is facts. Whatever arguments others
make is fiction.

First, yes, older forms of DRM did have impacts on some users of assistive
> technology, due in part to earlier blunt-force attempts at restricting data
> usage. Those impediments were usually part of the delivery system however
> (remember the infamous Sony root-kit affair as one example), and that is a
> far cry from what we are seeing here.
>
It's actually not a far cry at all. And the sony rootkit has no relation to
what's actually happening, and that is that todays DRM is not at all any
less restrictive than those of old. If anything it has become a lot more
restrictive as every android device now sells with a "trusted hardware
environment" that has the mandate to "keep the content safe" (nevermind
somebody discovering the masterkey rendering the whole obfuscation
bleedingly obsolete) by not letting userspace code have the data (that
means the browser).


> However, EME, the real thing that the W3C is working on (and not DRM -
> stop bending the truth), is simply the API that allows for decryption of
> video streams in the browser.
>
That's incorrect. EME is an API to interact with a proprietary plugin blob
(that's riddled with memory leaks, bugs and probably a pleathora of
security issues. That plugin has the mandate to overlay that video onto
whatever the browser wants to display. This does not (yet) work on all
platforms as well as it does on those that have the necessary
hardware/drivers to do it, but the days that the browser actually gets
access to the raw video frames are already over on iOS/Android.


> But here is the really important part: once the stream is legally
> decrypted, ALL OF THE ACCESSIBILITY BENEFITS OF MAKING THE BROWSER THE
> VIDEO PLAYER ARE PRESENT.
>
Only if the DRM implements them. Of if the DRM technically violates its
mandate and allows the browser to do things it shouldn't be allowed to as
per contract. But nobody seems to read and follow those contracts anyway.

Still... it's a consideration, and as the W3C is the global standards group
> responsible for web technologies, with both a declared mandate of inclusion
> and active working groups working towards that, we needed to be sure there
> were no actual issues.
>
Of course if actual dissent is suppressed, ignored and overruled, there are
no "actual issues".


> (Regarding "Daltonization" - having done some preliminary
> research personally in this matter, using a common tool that most
> browser-users with color issues would use - ZoomText - I was able to
> "color-shift" a video stream from Netflix in my browser, addressing the
> needs of a person with atypical color perception. More research is needed,
> but early indications are that this is not an issue either - unless you
> seek to do physical color modification to the source file, which I was able
> to conclude is not necessary. That said, additional tools are still
> required today to meet this need on multiple platforms and devices, but the
> encryption/decryption of the video stream does not appear to be a barrier
> in addressing the use-case today.)
>
The ability to adjust colors will go away, as it is an aberration of a
purely software-implemented DRM stack. "Proper" DRM stacks are in hardware
these days, and that's where the industry wants to go. And if those stacks
don't include color adjustment APIs, then there just isn't going to be any.

It's heartening to see the 'mainstream' now embrace and advocate for the
> digital rights of Persons With Disabilities, but when doing so, please be
> sure to base your arguments on specifics and facts, and not boogie-monster
> fear-mongering. It is dishonest, insulting, and makes PWD merely pawns in a
> power-struggle between legitimate business use-cases and those who
> seemingly cannot discern the difference between knowledge data and
> streaming entertainment.
>

Legitimate business use-cases is it now when a group of 4-5 execs (who
pride themselves on their technical ignorance) form a syndicate to dictate
to the entire business all the technical breakage, kludges and inadequacies
that are created for the sole purpose of degrading the user-experience and
making it hard for developers to write good and innovative things. Somehow
I don't feel that's the case. And I hope in time the law will come to
recognize that.