See also: IRC log
<scribe> Scribe: Brad Hill
<scribe> Scribenick: bhill
bhill2: Minutes up since yesterday
Objections to approving minutes?
<erlend> anyone else having poor audio reception?
ekr: actually link to Dec 18 minutes is broken
... any additions to agenda? http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0053.html
<jeffh> CORS is now at CR <applause>
bhill2: need to add test cases for 308 status
code, currently only implemented in FF
... before we go to PR
ekr: next: tracker
<trackbot> Notes added to ISSUE-15 How to handle srcdoc, blob:, di: and ways of directly creating content.
<jeffh> http://www.w3.org/2011/webappsec/minutes/webappsec-minutes-18-Dec-2012.html 404's for me (?)
ACTION abarth to raise ISSUE-15 on the mailing list
<trackbot> Created ACTION-115 - Raise ISSUE-15 on the mailing list [on Adam Barth - due 2013-02-05].
Associate ACTION-115 with ISSUE-15
<trackbot> ACTION-115 (Raise ISSUE-15 on the mailing list) associated with ISSUE-15.
bhill2: action 91 proposed as part of joint F2F at PayPal week of April 24-27, will resolve with email to list
action 94 - mkwest just proposed something to the list, will keep open until replies there
<trackbot> Error finding '94'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
dveditz: is anyone actually still interested in policy-uri?
mkwest: should probably ask on the list
re: 101, part of blob of updates to do to test environment
mkwest: 102 not done yet, hope to have done soon
re: 105, bhill to move due-date out, not needed until new WD of UI Security
mkwst: re 106, text just sent out to the list
re: 107, relevant to testing of UI Security, not done yet by bhill
re: 109, may need to be raised to list
mkwst: yes, META in general needs work
<gmaone> Sent http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0045.html to the list
mkwest: issue 33, vaguely remember doing something like that
remaining issues are depenent on bhill to assign appropriate actions to abarth to raise on list
neil: in violation reports, we could not tell what the violation was because it was triggered under default-src
mkwest: that makes sense, we should give you the granularity, default-src is same as creating multiple directives, I will update the spec if nobody objects
ACTION mkwst to update CSP 1.1 spec to indicate violation type for default-src violations
<trackbot> Error finding 'mkwst'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
ACTION mwest2 to update CSP 1.1 spec to indicate violation type for default-src violations
<trackbot> Created ACTION-116 - Update CSP 1.1 spec to indicate violation type for default-src violations [on Mike West - due 2013-02-05].
imelvin: just an issue to be aware of, HSTS
creates implicit redirects
... proposal at Mozilla that http sources implicitly also include same source as https
... if a site turns on HSTS, your resource using http sources in CSP will stop working
bhill: previously leaving out the scheme implied
automatic upgrades possible
... but now that we support paths, we may want to re-visit auto-upgrade policy since src URIs now require a scheme to be well-formed
dveditz: if there are redirects, you want the failure, HSTS is an implicit redirect without the initial request
(was that Jim?)
<imelven> (i think)
<jimio> yeah, 'twas me
jimio: we use both CSP and HSTS at Twitter, we never want to allow overrides of HSTS, we want CSP to break
jeffh: yes, that is my concern as well
... probably worth mentioning this scenario in the CSP spec
ACTION mwest2 to mention HSTS in implementation note as a reason things might stop working
<trackbot> Created ACTION-117 - Mention HSTS in implementation note as a reason things might stop working [on Mike West - due 2013-02-05].
dveditz: there are other reasons for the same
dveditz: cannot comment before trying to implement, will take Giorgio's experience since he has
bhill: defaults seem sane for what we (PayPal) would want to set, can refine as we have more impls and test cases
ekr: any objections to this? does it seem reasonable?
dveditz: seems reasonable, can't commit until we try it
ekr: any schedule for implementations?
dveditz: no idea when we will get to this, will require arguing with lots of people
ekr: issue 2 asks whether we should be allowed to have multiple values in Frame-Options directive?
dveditz: when we had original frame-ancestors, we allowed multiple values from the beginning
bhill: concern was about large lists of sites
(from Tobias and David Ross)
... but CSP already has parsers to handle multiple values
dveditz: multiple values also allows nested
iframes in a more comprehensive value
... not enough list discussion, this call should be to ratify discussions that take place in a less time-constrained fashion
ACTION bhill2 to email list on UISecurity issue 2 - multiple values for Frame-Options ALLOW FROM
<trackbot> Created ACTION-118 - Email list on UISecurity issue 2 - multiple values for Frame-Options ALLOW FROM [on Brad Hill - due 2013-02-05].
<neil> I stepped out for a second, did I miss 22:37 - 22:40 Line #s in CSP reports only for same-origin, CORS?
any other topics?
imelvin: what about line numbers in CSP violations?
<imelven> that wasn't me actually :)
mkwst: in WebKit we are currently stripping out GET parameters
dveditz: concerned about sending content/context,
that's a cross-origin data leak
... but line numbers should be ok
who was just speaking?
<jimio> that's neil
neil: original concern was line numbers for in-line scripts to get some context where it is happening
ACTION mwest2 to update CSP 1.1 to indicate line number reports for in-line scripts
<trackbot> Created ACTION-119 - Update CSP 1.1 to indicate line number reports for in-line scripts [on Mike West - due 2013-02-05].