Content Security Policy and iframe@sandbox

Hi!

In the OWASP Summit 2011, there were 3 sessions regarding in some way
iframe@sandbox, which where:
* HTML 5 Security
* Site Security Policies
* DOM Sandboxing

And one idea came up in one of the panels (with representatives of
M$/Mozilla/Chrome) in where at some point it was being proposed to use CSP
to complement iframe@sandbox.

After thinking more about it.. I reached the conclusion that in most cases,
iframe@sandbox flags are a subset of CSP + text/html-sandboxed.

So, this is how I see it:
0. no flags = text/html-sandboxed + allow nothing.
1. allow-scripts = script-src *;options inline-script eval-script;
2. allow-forms = forms-src *;
3. allow-same-origin = lack of text/html-sandboxed

The only case I can't emulate is allow-top-navigation.. and I assume there
may be more cases where CSP doesn't make sense since it depends on the
relation between frame and framer so I wont propose replacing iframe@sandbox,
since I still think it's useful, but to either:

1. Expand it to include CSP rules
2. Complement it with a new attribute

Now, I see several limitations in iframe@sandbox that are not present in
CSP, which would also help.. However, I understand that CSP is way to
complicated for random web authors to get it correctly, and the simplicity
of iframe@sandbox has this as a huge advantage, so I would like to keep it
that simple.

Said that, I can imagine something like:

<iframe sandbox="allow-same-origin use-policy" policy="<CSP here>">

in which case allow-same-origin/lack of allow-same-origin would treat the
content as if it had text/html-sandboxed or not (which would be a non-op if
the CT is text/html-sandboxed).

If you ask, how to mix an allow-scripts with use-policy, it's simple.. The
second you get use-policy, all other flags (except allow-same-origin and
allow-top-navigation) are ignored.

I am still not sure about this, so any feedback is welcome, but I think that
a unified sandboxing/content policy syntax would be beneficial.
Any thoughts?

Now, the use cases:
1. Parse HTML safely using the browser without JS execution. Any alternative
that creates DOM could be dangerous if lives in the same window.
2. Be more granular in what is and what is not allowed. Such as, disallowing
frames, or allowing only some forms, or even allowing some scripts! (for eye
candy or etc..).
3. Provide a safe DOM that you can provide to scripts (javascript) executing
sandboxed.

Greetings!

-- Eduardo