Re: EME: Rendering behavior undefined

On Sat, Jan 11, 2014 at 3:18 AM, Hans Schmucker <hansschmucker@gmail.com>wrote:

> I suggest that we define a rendering behavior and do make it normative.
> Some ideas:
>
> 1. EME-protected content rendering happens in a separate frame, which
> overlays any HTML, SVG or other content that the user-agent may be able to
> process. However, a user-agent may display its own controls above the
> EME-protected content.
>
> 2. EME-protected content is not clipped, except against the primary
> viewport (not, for example, that of an iframe). The area of the
> EME-protected element is defined as the rectangle (as the defined by the
> HTML box model) occupied by the element.
>
> 3. The Coordinates that define the EME-protected rendering area are
> derived from the VIDEO element. However the transformation is not applied
> on a visual basis, meaning that for example an SVG offset filter would not
> play into the calculation. The result is identical to the result of
> getBoundingClientRect.
>
> 4. EME-protected content is not transparent. The user-agent must fill the
> area with solid black first.
>
> 5. Rendering happens in content-order. Where two EME-protected elements
> overlap, the last element will be shown.
>
> 6. It is inaccessible to any other web apis. No CSS filters, SVG Filters,
> transformations, zoom controls and so on affect it
>
> 7. Even if the user-agent is tasked with rendering the image, the behavior
> remains unchanged.
>

These restrictions drastically limit the utility of EME-protected content.
Imposing these lowest-common-denominator requirements on all UAs, even
those which can do much better, won't be good for EME. I'm actually fine
with that, since I want EME usage to be minimized, but I suspect it won't
fly.

Another issue is that many of these suggestions, especially #2, create
security problems. It's highly unsafe to allow content from an IFRAME in
one domain to escape clipping and occlusion imposed by a parent document in
another domain. If a UA can't clip the EME content properly, then I'd
recommend disallowing usage of EME in cross-domain IFRAMEs ... but that
would preclude EME in the common case of "embedded Youtube IFRAME".

Yet another issue is that Google, Apple and Microsoft are already shipping
EME, presumably without these restrictions, so you now have a compatibility
problem where imposing these restrictions on them could break existing
sites.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w