See also: IRC log
<trackbot> Date: 27 August 2014
<bhill2> Meeting: WebAppSec Teleconference 27-August-2014
<freddyb> Zakim: ??P6 is freddyb
<freddyb> one of these days...
is anyone talking? very silent, no background hiss
ah, noise. guess it's working :-)
<freddyb> :)
<scribe> scribenick: dveditz
<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2014-08-13-webappsec-minutes.html
<scribe> scribe: Dan Veditz
bhill2: any objections to the minutes from last time (link posted in channel)
<bhill2> RESOLVED: prior minutes approved
<bhill2> Agenda Bashing
wseltzer: two notes -- WASWG charter set to expire at the end of September, and we also have a workshop coming up on WebCrypto which might have impact on this group
<wseltzer> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/#schedule
wseltzer: we thought we would extend the charter for 3 months to see if there is before officially rechartering
bhill2: will that be problematic?
wseltzer: no, it's pretty easy to do a charter with no change for a short extension
bhill2: I also noticed a community group on credentials was just formed, will be interesting to see what they do
wseltzer: we also have a group forming on web payments that will clearly have some security implications
bhill2: see I have one in the list, I will send a comment on frame-ancestors
<bhill2> https://github.com/w3c/webappsec/issues
bhill2: other items related to
SRI but I don't see devd on the call
... moving on to issues
... on github
<wseltzer> +1 to waiting to add new issues until there's been group discussion
bhill2: we should try to keep specific issues in the w3c tracker rather than github, and reserve github for editorial specification changes
dveditz: the only CSP2 issue on github is the CH-CSP header issue raised by mnot
bhill2: should we add that to the agenda today
<bhill2> ISSUE: disposition of CH-CSP client hint
<trackbot> Created ISSUE-63 - Disposition of ch-csp client hint. Please complete additional details at <http://www.w3.org/2011/webappsec/track/issues/63/edit>.
dveditz: I'd love to but without mkwst here I'm not sure we can have a productive conversation
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0021.html
bhill2: removing something after
last call is less problematic than adding it
... Dynamic CSP would obviously be a future (not CSP2) feature,
but do people think this is worth discussing or is it
completely crazy
dveditz: I am sympathetic to the use case, maybe we can come up with something?
<bhill2> ISSUE: CSP3 How to deal with large policies needed by single-page webapps (http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0021.html)
<trackbot> Created ISSUE-64 - Csp3 how to deal with large policies needed by single-page webapps (http://lists.w3.org/archives/public/public-webappsec/2014aug/0021.html). Please complete additional details at <http://www.w3.org/2011/webappsec/track/issues/64/edit>.
bhill2: sounds like worth talking in CSP.next
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0085.html
bhill2: do we want to specify a
limit on the number of report-uris? is there a practical limit
in the browser implementations?
... could be a DOS amplifier, but a web application could do
that anyway
terri: there might be an issue depending on how you cut it off so it might be worth adding to the spec
dveditz: if you have multiple CSP headers, each with only 1 report-uri you could get around the limit
bhill2: you wouldn't want to
allow injected headers or <meta> to be able to push the
legit report-uris off a stack or anything like that
... we currently don't have limits in the spec, doesn't sound
like there's a strong need for that
... sounds like not important enough to add at this time
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0054.html
terri: agreed, we could discuss this in csp.next
bhill2: sounds like we have
clarity on the image loading but I wanted to check with the
Microsoft folks that they are happy with the resolution
... and got the answers they needed
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0016.html
DavidWalp: yes, I am
bhill2: anyone interested in tackling this in csp.next?
<bhill2> ACTION: bhill2 to do more research on preventing 401 attach http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0016.html [recorded in http://www.w3.org/2014/08/27-webappsec-minutes.html#action01]
<trackbot> Created ACTION-186 - Do more research on preventing 401 attach http://lists.w3.org/archives/public/public-webappsec/2014aug/0016.html [on Brad Hill - due 2014-09-03].
bhill2: paypal had problems with this, and chrome tried to fix it by suppressing the dialogs, and later jeremiahg and rsnack found a way to use that suppression to test usernames on intr-A-net sites.
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0109.html
bhill2: I'll take an action item to investigate options here.
dveditz: I think Mike clarified the difference in the spec but it's unclear from the thread whether Kevin [from MS] is happy with the answer
DavidWalp: I don't know where kevin is on this
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0072.html
bhill2: looks like it has already been changed to update the name used int he Referrer spec (from 'none' to 'no-referrer')
dveditz: maybe inconsistencies over whether it's "no referrer" or "no-referrer" in the two specs
<bhill2> ISSUE: does "no referrer" specify a state or is it a token? Is a token with a space problematic?
<trackbot> Created ISSUE-65 - Does "no referrer" specify a state or is it a token? is a token with a space problematic?. Please complete additional details at <http://www.w3.org/2011/webappsec/track/issues/65/edit>.
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0053.html
bhill2: revisit as a potential CSP.next feature
<bhill2> ISSUE: no-external-navigation as potential CSP3 feature http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0053.html
<trackbot> Created ISSUE-66 - No-external-navigation as potential csp3 feature http://lists.w3.org/archives/public/public-webappsec/2014aug/0053.html. Please complete additional details at <http://www.w3.org/2011/webappsec/track/issues/66/edit>.
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0048.html
dveditz: the specific suggestion
from Antonio (no cross-origin report-uri) won't solve the
data-leak issue
... the problem is the fact that resources are blocked, and
that can be detected in multiple ways
... using report-uri was just a simple way to do it in the
initial POC
bhill2: do we need to resolve this or can we move into last call?
dveditz: I don't think Antonio raises anything new that wasn't considered in the current design. we can address it later if he can come up with a better description of his proposal
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0027.html
DavidWalp: I need to talk to Kevin, he's doing the CSP side. my interest is more in the referrer spec
<bhill2> features to mark as AT RISK: client hint, child-src
dveditz: Mozilla is unconvinced
of the need for child-src if it no longer covers workers
... and a client hint could be useful but we're not convinced
the CH-CSP/unsafe-redirect proposal has gotten enough
discussion
bhill2: raised ABNF issue about
frame-ancestors on the list
... apart from those issues are we ready to call for the end of
Last Call
dveditz: I propose a motion for the end of last call
<wseltzer> PROPOSED: End the last-call comment period
<wseltzer> ... for CSP2
wseltzer: clarification... end the comment period for last call?
dveditz: yes, end the last call comment period for CSP2
<freddyb> uh, my mic seems to have an issue
<freddyb> I second that
bhill2: two mozilla folks... do we need folks from other orgs to make this official?
<glenn_> no objection
wseltzer: more typically people request +1/-1 responses
<wseltzer> +1
bhill2: any objections to ending
the comment period for last call on CSP2?
... I would say we have a "soft consensus" and we're out of
time. will send to mail to the list requesting feedback
<wseltzer> RESOLVED: Chair will send one last email to the list re LC Comment Period
bhill2: by the end of the day