[theora] <video/> and cross site scripting policy.

[Silvia Pfeiffer]

Hi Robert,

From: Robert O'Callahan <robert at ocallahan.org>
Date: Thu, Nov 6, 2008 at 5:12 PM
> On Thu, Nov 6, 2008 at 4:12 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> On Wed, Nov 5, 2008 Robert O'Callahan <robert at ocallahan.org> wrote:
>> [snip]
>> > The main reason is that it gives servers control over who uses their
>> > resources. Checking 'Referrer' headers doesn't work well since it
>> > denies access to anyone behind a firewall that strips Referrer for
>> > good privacy reasons (or similarly, disables Referrer in the browser
>> > for the same reasons).
>>
>> I think most people who have done serious web work are aware of the
>> significant shortcomings of referrer (unreliability, inability to
>> distinguish reference from embedding, etc).  I'm very glad to see the
>> new control tools.

What makes us think that a new HTTP header will be used more
consistently than referrer?


>> But what would be lost for this purpose by having a fail-working
>> situation:  Client sends "Origin:"  and the client displays the result
>> unless the server response indicates otherwise?
>
> Good question. The main reasons:
> 1) It's generally a good idea to make the secure option the default.
> 2) Access Controls is used in situations (such as cross-site
> XMLHttpRequest) where the default is (and must remain) restriction to
> same-origin. Varying the default based on the kind of load would be
> confusing, and probably dangerous.

So does this mean that in the current situation, where no servers
support the header, the <video/> element will be useless because it
will not allow any video to be played?


[snip]
>> Is there any reason to expect that <video/> would present a different
>> security profile from images? (barring implimentation bugs, of course)
>
> For <img> we have a bunch of problems with cross-origin information
> leakage. We try very hard to avoid leaking any more information than
> the image's existence and size. For example, if a page draws a
> non-same-origin image into a <canvas>, we "taint" the canvas so that
> the canvas toDataURL method no longer works. (Of course we have to
> propagate taint if a tainted canvas is rendered into another
> canvas...) We now face subtler methods of pixel extraction, such as
> using SVG filters to move data from color channels to alpha channels
> and then using SVG pointer-events and the DOM elementFromPoint method
> to extract information from alpha channels via hit-testing. (See
> http://markmail.org/message/w3fz4qxycfa2tbic )
>
> <video> has all that of course, but also more because the <video>
> element's interface is much wider than the <img> element, and it's
> likely to get wider with time. For example, it would be great if
> scripts could access read closed-caption data in the stream, but
> obviously we don't want to leak that data cross-origin. Should a
> scriptable API to test the video format be accessible cross-origin?
> Etc

If search engines cannot access captions and subtitles and any other
annotations, that will be really useless.


> Serving media streams that can be "hotlinked" by anyone in the world
> doesn't seem like something that everyone is going to want to do. If
> you want to do it, you need a reasonably large operation capable of
> handling a lot of traffic. Already today most people who want to serve
> video just upload it to some site that does all the hard work for
> them.

To me this sounds backwards. People complained about the bandwidth use
of images when the Web began. I think that bandwidth is not an issue
any longer, or at least increasingly less important. I know from my
own experience with customers that people are currently outsourcing
their video operations because it is too complex to set up video for
their sites, and because there is a lot of technology involved (flash
players, thumbnailing, transcoding, embedding, cross-site domain
managment). I thought the creation of the <video/> tag was about
making this easier, not more complicated.


Regards,
Silvia.