ACTION-149, srcdoc, blob, data, etc.

<hat = individual>

This is a proposal to resolve ACTION-149 about how to handle special URI
types indicating content created as part of another HTTP request.

I think, roughly, the following algorithm should apply:


For directives that do not utilize the 'unsafe-inline' or 'unsafe-eval'
keyword sources, URI schemes that create content inline or dynamically,
such as "data:", "blob:' and "filesystem:" only match a source expression
equivalent to the keyword 'self'.

When evaluating if a URI matches a source expression for a directive that
utilizes the 'unsafe-inline' or 'unsafe-eval' keyword sources:

 1. If the scheme portion of the URI is "data:",  "javascript:" or another
construct that allows direct encoding of content, return DOES NOT MATCH
unless the 'unsafe-inline' keyword source is present.

 2. If the scheme portion of the URI is "filesystem://", "blob://" or
another scheme referencing content may have been dynamically created by
same-origin script in the current or a previous execution context, return
DOES NOT MATCH unless the 'unsafe-eval' keyword source is present.


When evaluating policy for an iframe generated from the srcdoc attribute
instead of a URI, return DOES NOT MATCH unless a source expression
equivalent to the  'self' keyword is present.



For purposes of discussion on tomorrow's call, Dan Veditz had an alternate
proposal that i believe is equivalent to:


URI schemes that create content inline or dynamically, such as "data:",
"blob:" or  "filesystem:" must always return DOES NOT MATCH if the source
expression contains only a '*'.  URIs with these schemes must be explicitly
declared as scheme expressions.  Policy authors should be aware that
allowing these schemes has security properties equivalent to allowing the
'unsafe-inline' or 'unsafe-eval' keyword source where applicable.



-Brad