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

[Jonas Sicking]

On Sun, Nov 9, 2008 at 9:31 PM, Conrad Parker <conrad at metadecks.org> wrote:
> Hi,
>
> thanks Gregory for the heads-up, and to Robert for the explanation.
>
> One issue that I'm not clear on is: at what point does served content
> contain such information that it introduces vulnerabilities? Is it
> when it contains personalized content/markup, or javascript? Or is a
> static video file somehow susceptible to attack?

One way potential vulnerabilities can be introduced is if at any point
a browser can be used to learn information that otherwise couldn't be
learned.

The most obvious information that needs to be protected is the
contents of files. If I put a file on a server but use some type of
protection (such as a firewall or password protection) to only allow
alice to read that file, I wouldn't expect other sites that alice
visits to be able to read the contents of that file. Do note that this
is the case even if the file is static. I.e. the file that I'm only
making available to alice might be static but private, such as a
company private financial presentation, or it can be dynamic and
personalized, such as the contents of my stock portfolio.

However more than the exact contents of a file can be sensitive. For
example we are considering adding a feature (pointer-events) to
firefox that allows you to say that only non-transparent parts of an
image should respond to events. This would allow things like precise
grabbing of the start and end mark in google maps. This would allow
testing which pixels in an image are transparent, and which are not.
This could be sensitive as well. For example the financial
presentation could include graphs. If a third party site can see which
pixels are transparent, I can not only see how high the various graphs
are, but also see what text is written under each graph.

And there is more, being able to read the size of a file can reveal
sensitive information. For example checking the size of the file
creditreport.com/mine/outstandingpayments.php can show if the user of
the browser is in financial trouble or not. If I know that the normal
size of that file for someone that doesn't have outstanding payments
is X bytes, I know that if the size is larger than that he/she
probably has outstanding payments.

Even the mere fact that a file exists is something we don't want other
sites to find out. In the previous example, creditreport.com might
have set up their system such that outstandingpayments.php returns a
404 if there are no outstanding payments, but a proper result if there
are.

There is more, but this covers the things that I think apply the most
to <video>.

> So ... is my understanding of the problem correct? The existing uses
> of web video are much like <img>, but in future we'd like to see more
> complex applications where the <video> is a customized part of the
> interaction.

It is already the case that <video> is richer than <img>. We fire
ProgressEvents while loading the video, these events contain the total
size of the file that we're trying to download, and the first of these
events are fired before we've had a chance to look at the contents of
the file to determine that it really is a video.

There are also discussions about APIs for captions. These would send
the contents of the captions to the web page to be displayed by the
page outside of the video.


What makes browser security sensitive is that when the browser
accesses content it generally does so with the credentials of the
user. At the very least it does so from the physical location of the
user which means that it is inside the same firewalls as the user. But
we don't want to expose that contents, or knowledge of that contents
to other sites.


Hope that makes sense.

/ Jonas