See also: IRC log
<trackbot> Date: 09 February 2015
<jww> zakim: jww is aaff
<jww> darn, I always forget the syntax.
ckersch and tanvi send regrets
<jww> bhill2: thanks :-)
<bhill2> scribenick: dveditz
<mkwst> jww, bhill2: http://www.w3.org/2015/07/zakim.html <-- the countdown
<bhill2> http://www.w3.org/2015/01/12-webappsec-minutes.html
bhill2: any objections to the minutes from last month?
bhill2: hearing none minutes are approved by unanimous consent
<francois> can we add a quick topic to "go around the table" and check whether or not anybody wants to keep NI URIs in the SRI spec?
dwalp: can we swap CSP and MIX?
bhill2: any objections?..... ok, we can do that
<francois> ah, sorry, missed it
bhill2: the ni:// topic is
already on the agenda
... we've been working on rechartering for a while. at 11th
hour we got an objection from Mozilla
... others have chimed in to support those concerns
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0066.html
bhill2: I have posted a diff
<bhill2> <- Moz's objections
<bhill2> https://w3c.github.io/webappsec/admin/webappsec-charter-2015.html
<bhill2> https://github.com/w3c/webappsec/commit/433dcc996c092309b88c4e1ecad425ea80a49aed
bhill2: we have room to figure
out what those specs are going to look like
... [reads the diff of clarification around COWL spec]
... objection from mozilla was that they couldn't support it
without further clarity.
deian: I made a comment on the change... looking for link
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0114.html
deian: dev brought up the thought we coiuld say @@ labels rather than origin labels but I don't know if he still thinks that
<deian> https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0114.html
bhill2: here's a note from anne,
not sure if it's an official mozilla response
... next objection was about EPR spec, breaking the ability of
the web to link.
... [reads clarification diff for charter]
... one response on the list saying that may not be strong
enough
<mkwst> dveditz: Sounds good to me, personally. EPR isn't terrible, real security benefits.
<mkwst> dveditz: similar to x-frame-options, who gets to control framing, etc.
<mkwst> dveditz: hope we can make a spec that satisfies folks in Mozilla.
<mkwst> dveditz: working on behalf of user to protect user.
thx mkwst
<mkwst> bhill2: Can you round-trip that back to Mozilla?
bhill2: next objection... unclear
what the high-level wording about powerful features meant.
removed from the summary but added the Powerful Features spec
as an explicit deliverable
... the updated charter description says "The recommendation
will include non-normative advice on when a feature might
designate itself as requiring a secure context and provide a
normative algorithm for determining if a given context is
sufficiently secure"
... Mike, does that wording work?
mkwst: I believe there's a W3 group making a recommendation this week, it's important that someone has oversight on this area if not the WebAppSec WG
<deian> +1 I agree with mkwst
bhill2: I tend to agree with you, Mike, that rather than taking this out or moving it to the TAG calling it non-normative may allow us to make a strong recommendation that can be used by other WGs without dictating to them
mkwst: my concern is groups who don't consider security until it's too late. I hope we can stop that from happening
bhill2: if you can live with this language, Mike, and if Mozilla can live with it then I hope we can move forward with something the TAG can reference
mkwst: [didn't catch]
bhill2: so noted. we are presenting the technical recommendation we are just not making it mandatory
<bhill2> mkwst: notes that the recent TAG finding on securing the web explicitly delegated the technical bits to this group
bhill2: the last section was about asynchronous decision making, explicitly referencing the WebApps charter
<mkwst> bhill2: perhaps we can skip to MS's concerns around MIX? I think Dave(?) has ~5m left before his next call.
bhill2: that group doesn't have
regular meetings so what we've been doing works well for us in
ways that wouldn't for them
... [reads updated wording in charter]
... are there any further comments on the charter update or on
the formal objection?
... I like to ask you, Dan, to take this back to the Mozilla
folks and round trip this ASAP. the sooner we can have this
resolved the sooner we can get on to the rest of the stuff we
have to do
dveditz: I will do that
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0148.html
bhill2: we have agreement from Tanvi from the Mozilla side to the late breaking changes, we were waiting for input from Microsoft
dwalp: no objections from MS
tanvi: none from Mozilla
mkwst: the only concern I'm aware of is from TBL posted to the list a few weeks back
bhill2: I asked him explicitly about that and have not received a response. Think we should call for consensus and take it to CR
<bhill2> ACTION bhill2 to issue CfC to take Mixed Content to CR
<trackbot> Created ACTION-212 - Issue cfc to take mixed content to cr [on Brad Hill - due 2015-02-16].
bhill2: congratulations Mike
bhill2: jumping back to CSP
... URI/IRI normalization threads, can we come to an agreement
on how we support these sources?
mkwst: also wrt normalization bsmith raised whether we should support unicode in the context of the <meta> tags
<bhill2> raise ISSUE should CSP support unicode, at least within the context of meta tags
tanvi: wrt IP addresses have you, Mike, found out whether there are addresses used in practice?
mkwst: takes time to get data back, I've put in the request
tanvi: would be good to restrict to localhost only (for compat reasons) and not add others
bhill2: I think the proposal on the table is to remove IP address support from CSP spec but not necessarily rip it out immediately from implementations
terri: is there a way to make it an option for later? I'm afraid we'll hit IoT situations later where devices can't use CSP because they only have addresses
mkwst: moving from not supporting to adding it back in later is easier than vice versa
terri: agreed, but I don't want the language to imply "this is a terrible ideal that no one should use ever"
bhill2: I'm sure we'll want to
allow 'self' to refer to the device even if it only has an
address
... is there someone else they'd want to refer to?
terri: there may be associated
devices that talk to each other, it's not unreasonable that one
device would include data/graphs from another
... I don't know if any of them will ever use CSP, but we do
have people working on things like that
... I don't know what the reason not to support IPv6 other than
convenience
jww: I think it was more that we couldn't come up with a good syntax to support it yet, rather than the concept
bhill2: we don't want to hold up CSP2 while we try to come up with normalization rules for it
terri: that's fine, especially if we add a note that we're working on it for CSP 3
bhill2: do we want to commit now to a feature in a future spec?
terri: we don't have to commit, can we just say we think it's possible in the future?
bhill2: that's sort of committing. we're close to CR I'd like to avoid changes to the text
terri: I'm fine with it not being in CSP2 explicitly as long as we know it's in our heads
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0084.html
jww: I'll file an issue on it
bhill2: concern was that in some
cases sandboxed iframes CSPs with 'self' don't refer to
anything reasonable
... diff of opinion about whether 'self' refers to the
"effective script origin" or whether self should disappear if
the document goes into the sandbox
jww: sandbox already breaks stuff if the content isn't aware of it
mkwst: sandbox breaks things like local storage, if the content isn't aware it's being sandboxed then it won't work
@@: that means you can only use CSP if you specify full origins, not 'self'
bhill2: also depends on when the sandbox is applied wrt CSP
mkwst: a good counter example
from my point is frame-ancestor. it needs to know what the
origin is before the sandbox is applied in order to specify
it
... I would be hard pressed to write an exception to make this
case easier to understand
jww: is it an intended consequence of a sanbox? we agree that scripts may not run, fine, that's why you sandbox. is this like that or is it surprising?
mkwst: I can see both sides. I
can see it would be useful to be able to grab a real resource
origin in some cases. what do we do with paths especially if
they're set by pushstate?
... do those match a source expression? seems problematic
... I think there are more impt topics to attend to
jww: I think anne was on oyour side, too. I'm not sure we should be adding a 3rd origin type
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0266.html
bhill2: I was on the side of not breaking but have been won over, Dan how about you?
dveditz: I will answer on the
list, unable to scribe and think here. I may be won over
... is the unicode issue the only remaining issue?
deian: I think brian's point about nonces are too
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0116.html
mkwst: brian had a couple of concerns. referrer directives, unicode, ..... [?] those are the 5 issues
bhill2: you already moved the referrer directive into the referrer spec right?
mkwst: yes
bhill2: the xss filter directive was moved to CSP3?
mkwst: I wasn't against it,
haven't yet
... dev's suggestions for nonces ....
<mkwst> dev's suggestions are at https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0076.html
deian: maybe we could just note the potential for problematic uses of nonces
bhill2: nonces were never
intended to be super secure, they were inteded to be more
secure than not using CSP or using 'unsafe-inline'
... given we have two implementations already we would require
a strong evidence of potential misuse to make a change at this
point
... if brian is the only one with a strong objection to how
nonces work and there are no formal objections, and strong
support for moving CSP2 ahead I would like to make a call for
consensus that nonces will work the way they work in the
current implementations.
<bhill2> ACTION bhill2 to reply to brian smith re: CSP2 to CR
<trackbot> Created ACTION-213 - Reply to brian smith re: csp2 to cr [on Brad Hill - due 2015-02-16].
bhill2: I appreciate brian's
attention to the spec and smart comments, but we'll have to
leave some of this for the next version of CSP
... I apologize to the SRI folks we didn't get to their
issues
... thanks everyone, talk in 2 weeks
have to run
<bhill2> I'll do the wrap up, thanks Dan
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found ScribeNick: dveditz Inferring Scribes: dveditz Default Present: [Microsoft], +1.206.348.aaaa, bhill, +1.418.907.aabb, +1.646.821.aacc, gmaone, +49.162.102.aadd, deian, francois, mkwst, +1.503.712.aaee, terri, +1.415.736.aaff, dveditz, jww, +1.415.596.aagg, puhley, +1.310.597.aahh, tanvi, WSeltzer Present: [Microsoft] +1.206.348.aaaa bhill +1.418.907.aabb +1.646.821.aacc gmaone +49.162.102.aadd deian francois mkwst +1.503.712.aaee terri +1.415.736.aaff dveditz jww +1.415.596.aagg puhley +1.310.597.aahh tanvi WSeltzer Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0129.html Found Date: 09 Feb 2015 Guessing minutes URL: http://www.w3.org/2015/02/09-webappsec-minutes.html People with action items:[End of scribe.perl diagnostic output]