Re: EME: Rendering behavior undefined

One more possibility comes to mind:

Define different levels of integration and let developers check the
integration level provided by the current CDM. Of course, due to the issues
you raised, INTEGRATION_OPAQUE would still need to be defined so that it
doesn't spill into other content.

getIntegrationLevel()
returns either of
INTEGRATION_FULL : The video element can be treated like any other,
including drawImage support (with the same same-domain restriction)
INTEGRATION_PROTECTED : The video element can be overlayed, have filters
applied and so on, but can NEVER be used as a source for drawImage or as a
texture
INTEGRATION_OPAQUE: The video element is treated like a fully transparent
image by the UA (which will be the result of any drawImage call or filter),
and the coords will be filled by the CDM outside of the UA with the content
visible to the user.




On Sun, Jan 12, 2014 at 10:52 PM, Hans Schmucker <hansschmucker@gmail.com>wrote:

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