See also: IRC log
<bhill2> hmm, looks like we may not have a reservation anyway
<gioma1> bhill2: does it mean the bridge is not available?
<bhill2> let me try again
<bhill2> zakim this is 92794
<bhill2> sorry folks, looks like the staff didn't get the reservation set up in time
<bhill2> bridge is unavailable
<bhill2> getting a slow start today, waiting for folks to arrive in person
<bhill2> I have put in a request for the phone bridge for tomorrow, Philippe is following up. Possibility of getting it enabled later today.
<bhill2> phone bridge should be available within the 1/2 hour
<scribe> scribenick: ekr
bhill2: start installing your vms
<bhill2> bridge is up
<bhill2> zakim aaaa is bhill2
<bhill2> who just joined?
<bhill2> sorry to yank the rug, but we are headed next door to webapps to discuss last call comments for CORS
<bhill2> will be back at 10:15, and I will leave the bridge open
jeffh: the current spec is
baffling if you're not a browser implementor
... I told Anne that already
<plh> oops
[discussion about how to pass this information back.]
Scribing will be happening in webapps for now
<gopal> which room are you meeting in
<dveditz> gopal: the one with all the people in it
<dveditz> (didn't catch the name on the way in)
<gopal> what happened to saturn
<dveditz> --not-- the one with the sign outside saying webapp security
<gopal> ok
<dveditz> talking about CORS
<dveditz> joint with webapps, guess we're in their room for that
<gopal> will be there
<bhill2> ACTION to bhill2 to integrate jeffh comments into sec considerations in CORS
<trackbot> Sorry, couldn't find user - to
<bhill2> ACTIN bhill2 to integrate jeffh comments int sec considerations in CORS
<bhill2> ACTION bhill2 to integrate jeffh comments int sec considerations in CORS
<trackbot> Created ACTION-58 - Integrate jeffh comments int sec considerations in CORS [on Brad Hill - due 2012-05-09].
<jrossi> It seems the conference bridge's audio has stopped.
<abarth> jrossi: we had problems with feedback
<jrossi> Ah, I see. I'm fine with just watching the IRC if you guys take good notes. :-)
<dveditz> can you hear now?
we can hear you
<dveditz> I think we hear you
next agenda item: CSP 1.0 outstanding issues
<bhill2> can you still hear us?
<jrossi> cuts out most of the time, just bits and pieces
<dveditz> we all came to microsoft's campus, where are you? ;-)
<jrossi> haha, wrong campus!
<abarth> http://www.w3.org/2011/webappsec/track/issues/open
<dveditz> jrossi: most of us are far from the mic, we'll try to get closer when we say something substantive
<dveditz> right now there's lots of mumbling
<jrossi> that's probably it, I think noise cancellation is just kicking in since you're far away
abarth: I thought we resolved issue 8 a while ago
<dveditz> if *you* have noise cancellation you might try turning it off if you have a headset
issue 35:
<dveditz> that way your own noise won't cut our softer sounds off
<jrossi> i'm muted
dveditz: A lot of proxies will mangle this anyway
bhill2: this came out of IETF
dveditz: mozilla's solution was
to have an intersecting policy
... I don't think we can say don't combine this
abarth: if there is a comma, there is an error processing case.
dveditz: the proxies will just merge them anyway.
abarth: how shall we handle the error of the server sending multiple errors and the proxy combining them.
dveditz: I can see how this happens.
[... discussion...]
Abarth and Dveditz suggest that comma be illegal.
abarth: how shall we handle it?
dveditz: I would prefer an intersecting policy
ekr: why not treat it as an ilelgal policy?
abarth: what should be the behavior if you get a policy without any of the known directives?
dveditz: shouldn't that be default source = none
tanvi/dveditz: why not take the most restrictive?
abarth: it's not clear which one
it is?
... and now you're into intersecting policies
bhill2: this text I sent is designed to cover this.
abarth: turns out that comma is
forbidden but we recover
... I suggest that with comma we set the policy to some invalid
policy.
bhill2: like default src = none
abarth: yeah, and I would probably log in the error console.
ekr: how should we handle other cases where the policy is invalid,
abarth: e.g., directive name ==
backspace or dollar sign
... currently it gets parsed as a directive name. It's illegal
but causes no failure.
ekr: the general philosophy is that if you can make sense of it, do it?
abarth: it's semicolon delimited, so if I don't understand the thing in between the semicolons, then I ignore it.
ekr: Do we want to revisit the design decisions (a) no intersection and (b) non-restrictive default policies.
dveditz: I wasn't paying that much attention before, but I would still prefer intersection
bhill2: the argument last time was that intersection was hard
dveditz: yah, it's not perfect. It does tend towards breaking the page.
bhill2: what about combining only policies of type src list
abarth: most important thing is
for it to be extensible.
... want to have something good I can take back to websec
... can't merge on a directive by directive basis
... I see policy combination as really complicated and benefit
is not that large
dveditz: what is the proposed handling if we get a comma?
abarth: the thought is that since it is syntactically invalid, the policy is now default source none and print something to the debug console.
dveditz: seems like ignoring everything after the comma is consistent with first policy wins, but maybe we don't know which order the proxies assemble the headers in
ekr: right, but this means that a bad policy is ultra-dangerous as opposed to breaking everything
bhill2: philosophy has always been that this is a safety belt
abarth: we find that when people
deploy CSP, they find that there aren't a lot of violations and
so they aren't sure policy is running.
... I would like to have some way to ask it.
bhill2: what if there is some proxy elsewhere.
ekr: what if there are multiple proxies? This makes it very dangerous...
abarth: do proxies like this really exist?
tanvi: so if we have two headers
right now we do nothing?
... the other thing about intersecting policies is if we have
meta tag and policy URI we might have to deal with this.
abarth: meta tag used to be
trumped by header
... something else I want to talk about for 1.1--there is a use
case to modify policy at run time. It's delicate to do that in
a good way
bhill2: how he handle combination
logic, then this impacts how things behave in the future
... in the future, we are going to have proxies which do CSP
injection, then this won't work with any future meta tag
abarth: maybe say you must only send one policy and then if you receive two you fail in some obnoxious way.
and if we add a new way to get policies we specify a combination mechanism then.
bhill2: this still leaves it open how people who do want to do policy injection. We should give them some advice.
abarth: those people are more able to adapt.
bhill2: well, WAFs don't adapt much
ekr: well, the reason we didn't do it was because it was hard. If these guys want to try it, then good for them, but we don't have to
abarth: my current proposal {two policies, comma in header} --> enforce default src=none
bhilll2: so no meta tag?
... it's on the agenda later
bhill2: is now a good time to discuss the meta tag for 1.0?
abarth: I think we should talk
about that in 1.1
... it's related to other things in 1.1
bhill2: the question of meta in 1.0 has to be on our agenda. shall we revisit it now because it may impact the combination logic.
dveditz: how so?
... other headers with meta tags have had the header override
the meta tag
tanvi: what if we forbid duplication now and then specify merging in 1.1?
travis: historically don't meta tags trump headers
dveditz: tuypically the other way around
travis: from a security perspective, that seems ok, but practiclaly don't you want the opposite
abarth: that's just the way the web is even if it's backwards
travis: well, in some cases IE does that
dveditz: it's a matter of who wants what -- web pae authors versus site operators
travis: personally I want to not see meta tags in 1.0 so we finish
<abarth> http://www.w3.org/2011/webappsec/track/issues/open
taking a break till 11:30
<tanvi1> http://www.w3.org/TR/CSP/
we are back
topic is ISSUE #8
balance between the user's preferences and the site authors
dveditz: both user and site operator are concerned about attacks and the user can always override the site's preferences as a technical matter
abarth: my sense is that we agree about principles, and the details are a matter of the implementations which vary anyway
dveditz: if the UA lets the user add extensions, we are still respecting CSP in a reasonable way.
abarth: I view the current text
as sort of aspirational.
... as an example, in Chrome a content script can load images
from its own extension package regardless of CSP
ekr: I propose we mark this closed and move onto meta and sandbox
bhill2: we have requests from a
bunch of people to restore the meta tag
... my summary is that there are a lot of site admins who can't
set headers but would like to use CSP
... so this is worth the risk
abarth: my sense is that this interacts with CSP 1.1 proposed features such as the ability to query policy
dveditz: I'm much more concerned with a DOM API to set policy than I am about a meta tag
abarth: is there anyone who thinks this should be in 1.0?
tanvi: we'll need to discuss anyway
dveditz: one concern about
injectable policy via meta is leak via reporting. maybe add
same origin requirement for reports in meta
... would also like to restrict meta to HEAD
abarth: how would you feel if we restricted meta tag to HEAD. How would you feel if someone injected it later?
dveditz: I think that's cheating
abarth: so only if it's in head
and available at the start.
... example is gmail
dveditz: what if I had a meta tag that said "allow deferred DOM API CSP injection later"
bhill: use cases is restrictive
server environments
... maybe these use cases can't meaningfully consume reports
anyway
dveditz: might be willing to stick to simplest use cases
tanvi: what would requirements be: meta tag == no report, meta tag must be in HEAD, must be no header
abarth: + must be inserted by parser
[discussion about what 'inserted by parser']
[discussion about what we are trying to achieve by restricting this?]
bhill2: if you can inject script
then it's game over
... I'm not sure there is any reason to restrict it from being
added by script
dveditz: the spec should just recommend that it go early.
bhill2: if you screw up before the meta, you're on your own
dveditz: want same origin reports
tanvi: don't want same origin reports--encourage people to use header instead of meta tag
bhill2: if you're only able to
run static comment anyway
... how many scenarios is this relevant for?
tanvi: the only places this is really going to happen are corp environments and those people should go talk to their admins
abarth: my notes say
<abarth> Bringing back the <meta> tag,
<abarth> Must be in the <head>
<abarth> Header trumps <meta> tag
<abarth> First <meta> tags wins
<abarth> report-uri doesn’t work
<abarth> Guidance that delaying the header isn’t wise
dveditz: meta must come through parser.
bhill2: what's the security benefit here? All you can do is inject a new policy?
abarth: my preference is to not
care how the data is inserted.
... suggestion is to use no insertion after ready state.
<gioma1> Zakim: ??P2 is gioma1
ekr: what's the security reason for this?
bhill2: It seems like an implementation simplification
ekr: ok
nobody in room wants it in 1.0. people on list have requested ti
dveditz: we are probably closer to meta than sandboz
bhill2: if all implementors agree
they don't want to do meta in 1.0
... then it doesn't need to be in 1.0 spec. by comparison,
sandbox has some implementation. but no implementations, then
meta loses...
tanvi: just because it's not in 1.0 doesn't mean people don't do it
abarth: my plan is to ahve it with a prefix
resolved: meta will be in 1.1 due to lack of implementor support for having it in 1.0. we will attempt to specify it early in 1.1.
<tanvi> what happened with onload vs inserted by the parser. i believe we decided the policy should be set onload? or did we decide not to specify that
bhill2: anyone want to revisit consensus on sandbox. We had interest from implementors on doing it, and we're going to re-check implementation status at CR...?
<dveditz> abarth was going to use wording along the lines of "before document readystate"
<tanvi> does microsoft have the full csp 1.0 implemented?
abarth: can we have a feature that we may drop if we do not have two implementations?
philippe: you need to mark it as
"at risk"
... if you mark it as at risk, you don't need to recycle to
LCWD if you drop it.
proposed resolution: we mark this at risk and then if we don't have two implementations, it gets dropped.
bhill2: can MS live with having this in 1.1?
travis: main concern is that it not just look like a MS feature
bhill2: jacob is willing to specify this
abarth: we outsource parsing to HTML5
dveditz: what if HTML5 changes?
abarth: they need to retain backcompat
bhill2: propose that we punt this
to 1.1 since MS won't have a complete implementation anyway.
Then we can move to LC soon.
... will raise on list
<scribe> ACTION: abarth to create 1.1 impl by end of week [recorded in http://www.w3.org/2012/05/02-webappsec-minutes.html#action01]
<trackbot> Created ACTION-59 - Create 1.1 impl by end of week [on Adam Barth - due 2012-05-09].
resolved: we will punt Sandbox to 1.1 pending approval on list.
dveditz: what about future
compatibility for more specific policies, e.g., src lists that
specify directories
... if we come up with a compatible syntax now.
abarth: proposal, allow full URLs but truncate to the origin.
<abarth> script-src http://example.com http://foo.com/bar/qux
<bhill2> dveditz: if someone types in https://www.google.com/ that is ignored because of trailing slash
<tanvi> script-src 'self' http://dev1.addons.phx1.mozilla.com https://addons-dev-cdn.allizom.org/
<tanvi> proposal: allow urls, and truncate them to the origin.
<tanvi> this ends up whitelisting an entire origin, when perhaps you just want to whitelist a path.
<tanvi> so perhaps we shoudl version cps?
<tanvi> *csp?
<tanvi> script-src and scipt-src-path
<tanvi> we could add a version to the specified policy. if the version =1.1, then allow paths in sources. if the version is 1.0, then ignore sources with paths.
<dveditz> choices appear to be a) version CSP header, b) duplicate directives in the future, c) degredation of hosts with paths
<dveditz> a) means two headers always. CSP2 clients need to look for both headers, sites may just leave CSP1 clients insecure
<dveditz> b) pretty much the same on a directive level -- either duplicate, or leave CSP1.0 clients as insecure as non-CSP clients
<scribe> ACTION: dveditz to write a message to the mailing list describing his proposal for how to handle URLs with paths (truncate to the origin) [recorded in http://www.w3.org/2012/05/02-webappsec-minutes.html#action02]
<trackbot> Created ACTION-60 - Write a message to the mailing list describing his proposal for how to handle URLs with paths (truncate to the origin) [on Daniel Veditz - due 2012-05-09].
dveditz: people also want to be able to specify plugins by media type. E.g,, flash but no java
<scribe> ACTION: abarth to merge bhill's policy combination text into the CSP document [recorded in http://www.w3.org/2012/05/02-webappsec-minutes.html#action03]
<trackbot> Created ACTION-61 - Merge bhill's policy combination text into the CSP document [on Adam Barth - due 2012-05-09].
<abarth> http://www.w3.org/Security/wiki/Content_Security_Policy
<abarth> https://mikewest.org/2012/05/content-security-policy-feature-detection
<gioma1> are you people talking about clickjacking? I heard "...ckjacking" but it's all silence and some word here and here on the SIP bridge :(
<bhill2> talking about CSP 1.1 propsed features right now
<bhill2> I will try to turn up the microphone
<tanvi> i believe the anti-clickjacking discussion is tomorrow
http://lists.w3.org/Archives/Public/public-webappsec/2011Dec/0016.html
http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version_1.1
peleus: what happens if you try to eval() with SCP
CSP
abarth: throw a security
exception
... why is this useful? Avoid reporting errors for feature
tests
abarth: maybe we can get this back in
jeffh: now is a good time to participate in websec
abarth: maybe it should be possible for IETF documents to specify CSP directives
<tanvi> i have a couple of potential additions i'd like to bring up
bhill2: two ways to look at the world. (1). Anything new is CSP 1.1. (2) anything that changes how things work is CSP 1.1 and anything else is just new directives
tanvi: you have access to the wiki?
I just added some stuff
<tanvi> sure, i'll do that
<tanvi> added
peleus: this seem like it's a maintainability issue
dveditz: this starts to get
pretty long
... what about policy-uri?
<tanvi> this way you could imbed third party script that you trust (ex: facebook like widget) and know that if facebooks servers gets compromised, the hash won't match and your page won't be vulnerable
<tanvi> (regarding script-hash)
<tanvi1> script-src http://google-analytics.com [###]. so only http://www.google-analytics.com/ga.jsworks, and nothing else from google-analytics works.
tanvi: idea to prevent against self-xss.
no longer allow js: in address bar
but you could still get people to do "open"
idea would be to require special to activate the web console in these cases (where policy is provided)
dveditz: not sure how serious this is.... it is for fb and twitter
really only applies to a subset of sites.
ekr: this is a social engineering question
dveditz: interesting idea but not sure I want to jump right in on it.
next topic: restrict script to sources with specific content types
peleus: this causes a lot of problems
tanvi: idea here is to restrict scripts to a specific set of content-types
abarth: historically, this has
been something people have ignored, so there will be a lot of
collateral damage
... having it be opt-in
ekr: you could have the white-list in the directive
abarth: etter to ahve it be binary
bhill2: HTML5 makes form tag injection easier
abarth: this seems like it would help defend agains that and be within the scope of the kind of stuff we have done
dveditz: syntax seems
complicated
... argue about it later
abarth: seamless with
parent
... iframe can resized like a div.
... right now it's single origin
... might be nice to have a directive that allows it even
without same origin
ekr: this seems like it's conceptually new since it's not a restriction
travis: IE already allows iframe resizing
abarth: this is a little
different
... put it here so the group is aware of it. not sure where it
goes
bhill2: a lot of people want to
have safe JSONP
... jsonp-src : a list of domains
... jsonp-sink: a list of safe function names
... idea is that you could apply it to existing legacy
code
... two objections from lcamtuf: (1) this doesn't solve jsonp
being interpreted as scripts (2) it may not actually permit a
lot of valid jsonp
ekr: this seems like a good idea, but not sure it can be made to work
abarth: I had one more... meta-referrer
finally, more granular origin list
tanvi: who has implemented meta tag for referer?
dveditz: should this be a meta tag? separate or in csp?
abarth: this feels like a policy thing
dveditz: I agree with that for things that are specified as headers....
bhill: distinction between
proposals that rev the spec and proposals that add new
directives
... what are examples of reving the spec? policy-uri, more
granular origins
abarth is currently modifying the page to divide between experimental and proposals for 1.1
abarth: excited about form
action
... plugin types might be a good one
bhill2: negative plugin tyes?
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/create/cover/ Succeeded: s/may need to discuss it/it's on the agenda/ Succeeded: s/sue/use/ Found ScribeNick: ekr Inferring Scribes: ekr WARNING: No "Present: ... " found! Possibly Present: FP Microsoft Morton P1 P15 P2 SW_RDB2RDF SW_RDFWG S_Track Style_CSS TR Team_ XML_EXI aaaa aabb aacc abarth active anne bhill bhill2 bhill22 bhilll2 caribou dnt dveditz ekr gioma1 gopal https jeffh jrossi jrossi1 peleus philippe plh proposal puhley scribenick tanvi tanvi1 trackbot travis wf You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 02 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/02-webappsec-minutes.html People with action items: abarth dveditz[End of scribe.perl diagnostic output]