mwest: Some Perl scripts to
verify report was generated.
... They rely on the fact the entire render tree is dumped and
need work to make them JS compatible.
... Volunteers to be test coordinator.
... May be able to attend Silicon Valley meet-up with HTML
WebApp WG if we set one up with advanced notice.
... Erland's test suite focuses on the core functionality
around "-src" policies. No testing around properties like
sandbox.
... WebKit probably has some test cases on sandbox and
report-uri. They don't have a really thorough test suite for
ensuring sandbox works for all possible variants.

bhill: Perhaps we should ask
Microsoft to see if they have test cases they can
donate.

CSP 1.1

mwest: New CSP 1.1 features are
as follows:
... First new item is meta implementation to allow CSPs in Meta
tag.
... Implemented in WebKit and roughly stable.

dveditz: sandbox is about that
resource being used from somewhere else.
... ui-safety is more of an outgoing policy
... sandbox might difficult to support in a meta tag.
... need to know some things before renderring.

mwest: We should describe in the
non-normative section of the spec where there will be variants
in the behavior when the field is supplied in the meta
tag.
... Will bring the options for putting that in the spec to the
mailing list.

dveditz: Does the spec require
meta tags to be in the head of the document?

mwest: It is listed as a to-do in
the spec but it is their.
... Policies are ignored once the document has reached a ready
state.

tanvi: Does it need to be before
head tags such as CSS which include JavaScript.

mwest: OK with making it a
requirement that it needs to be the first entry in the head
tag.

<tanvi> mwest - charset
should go before/after the meta tag?

mwest: Google in process of
trying to get some company properties to use CSP but it is a
difficult transition. Need to support use case where meta tag
can be used after a load event but before asynchronous
interactions.

<mkwst> tanvi: probably
after, since the charset could theoretically impact the way the
policy is interpreted.

bhill: CSP spec should specific
enough that it can be consistent across all browsers.
... (with regards to URI parsing)

mwest: Parsing a URI for CSP is
already different than how normal URLs are parsed in
general.

<dveditz> rfc 3986 defines
paths as part of URLs that have a hier-part

<tanvi> dveditz: if it starts
with two slashes its hierarchical, and if it doesn't than it
isn't. for csp we probably don't deal with exotic types, so
could just reference rfc 3986.

<tanvi> dveditz: we have blob
and other things that are standard but not hierarchical. what
do we do if we want to block those or not block those. 1.0 spec
doesn't really address them, they are just allowed

<tanvi> mwest: webkit taking
position that they are the same as 'self' and allowed when
'self' is allowed. since only created and accessible within
context of an origin

<tanvi> we should address it
in the 1.1 spec, so consistent across implementors

mwest: Currently not saying
anything about queries but we could say that we are explicitly
ignoring queries.
... WebKit is throwing a warning that queries aren't accepted
in source expressions and are being ignored.
... Worth noting in the spec explicitly.

mwest: Next new feature in 1.1
is: script interfaces which allows read of the union of the
content security policies in effect.
... Some discussion about whether there should be write
compatibilities. WebKit has read-only in Canary and Dev version
of Chrome.
... No known use case for allowing the read of the
report-uri

bhill: If unique report-uris are
created for each instance, then an XSS issue could be used to
spam the report-uri to hide attacks.

mwest: Should assume that
report-uri is public. That said, no known value in exposing to
JavaScript.

bhill: Send email to the list to
see if anyone is concerned with dropping it.

<trackbot> Created ACTION-93
- Query list if any use cases for reportURIs script interface
[on Mike West - due 2012-11-09].

puhley: Depends on whether
per-session data in the report-uri to help refine log
correlation on attacks.

dveditz: Would custom extension
changes be reported in the report?

mwest: Yes. WebKit makes sure
reports go to the URI that is associated with the specific
policy that is being violated in the case of multiple
policies.
... Not sure if there is a good way to distinguish policies
from the page and policy changes by extension.
... Use case for script detection of policies is so that a page
can determine whether eval is allowed.

<mkwst> Specifically, the
request came from Angular, which has two implementations of
templates: one without eval, and one with eval (which is more
performant). They'd like to be able to hop between them.

dveditz: There are concerns about
privacy implications regarding detecting the end-user's
environment and extensions.
... Perhaps make it a request method rather than a read
approach where you get the entire string.

mwest: It is currently
request-orientated.
... I am open to further discussion regarding how much
information needs to provided to JavaScript.

<tanvi> mwest - drop uri from
the spec right now. we can discuss whether adding it back is a
good idea later.

<bhill2> ISSUE: discuss use
cases / risks of script access to CSP information, solicit
specific public comment on this feature with FPWD

<trackbot> Created ACTION-94
- Add specificity to CSP 1.1 draft that script access queries
ONLY state of CSP, not general reachability of URLs by
configured browser context [on Mike West - due 2012-11-09].

<trackbot> Created ACTION-96
- Add note clarifying that form-action is not subject to
default-src fallback [on Mike West - due 2012-11-09].

Group questions whether there is value to
restrict the schemes due to the fact that there are specs for
sites to self-register schemes. This may be an issue for 1.2
instead of 1.1 when more information on those specs is
available.

bhill: Next 1.1 feature is that
sandbox is now mandatory for compliance with 1.1 in a user
agent.

mwest: Next 1.1 feature is
script-nonce. Nonce is supplied by the server. Script is only
allowed if the script has the nonce, unsafe-inline is allowed
and/or script-src matches.
... Allows whitelisting of inline scripts while still trying to
protect against injected script when unsafe-inline is
specified.
... Assumes that the attacker can't predict the nonce.

tanvi: XSS in white-listed js
code could bypass the mechanism.

<tanvi> ekr - maybe include
an indicator that determines whether this applies to inline
scripts or included scripts

<tanvi> how solid is the
assertion that the attacker can't figure out the hash. only as
solid as the implementation.

mwest: Nonce randomness
protection is determined by the server implementation.
... Last 1.1. feature is plugin-types which limits the types of
resources which can be embedded. There needs to be more
discussion about how this will work in every browser due to IE
ClassID mechanism vs the mime-type approach.

<tanvi> plugin-types - issue
with mime types and classids. how should this be handled?
question for microsoft. discussed an internal mapping from
mime-type to classid, but this wouldn't work for all mime-types
(ex: custom corporate plugin wouldn't be in the generic
mapping)

puhley: How would an iframe be
handled whose src points directly to plugin content.

<tanvi> tanvi - browser only
block mixed active content. not mixed display content. we
wouldn't be able to distinguish between the two with the
directive (we would just turn all mixed content off) because
the definition of mixed active content differs from browser to
browser.

bhill: Do we need to additional
scope to our charter for CSP 1.1, etc?
... We are chartered to produce something like policy-uri based
on language within the scope Manageability section.

dveditz: May be covered by the
fact that load balancers can manage policies.

bhill: Mashups should still be
the same based on the 1.1 things under discussions.
... We are on track to meet the success criteria of "two
independent implementations" even if some minor details aren't
exact.

tanvi: Happy with the current
success criteria even if we aren't precisely there yet.