Re: EME: Rendering behavior undefined

Thanks for the reply roc.

I actually agree with you on almost every single point. I'm not very happy
about EME either... but since it probably will happen, I at least want to
make sure it's stable, delivering predictable results without requiring
web-developers to test against every single UA individually. Right now, EME
as a standard pretty much says: Take a stream, hand it somehow to something
which will do something with it, which is not exactly what I'd expect of a
W3C standard.

If Microsoft and Google are already shipping implementations, while the
standard is not even nearly finalized, then I would honestly say that
that's their problem. Google's Chrome at least has the capabilities to
adapt, with their background-update system. In case of Microsoft... well,
maybe that'll get them thinking. Web developers will probably take a while
to use EME, so I don't think any changes right now are a major issue for
them.

About the security implications. Your concerns are very, VERY valid. But
the spec right now doesn't protect against any of this and saying "you can
make it secure if you like" to UA and CDM vendors is probably the worst
thing to do. This way, people embedding EME-protected content may think
that it's secure, because it is in their browser, while it's insecure in
another one.

The only solution I see is to again include a mandatory behavior for CDMs
in the spec... one different from the one I proposed earlier, which
addresses these issues, by making it mandatory for CDMs that render their
content directy to obey a a series of clipping rects or a mask from the UA.
It's bad. I know it's bad. But at least it would be consistent.

--hans


On Sun, Jan 12, 2014 at 10:32 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> 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
>