W3C

WebAppSec Teleconference, January 29, 2013

29 Jan 2013

Agenda

See also: IRC log

Attendees

Present
abresee, +1.650.488.aaaa, ekr_, bhill2, +358.718.00aabb, mkwst, gmaone, +1.866.317.aacc, jeffh, +1.260.226.aadd, neil, +1.503.712.aaee, rrware, erlend, +1.415.426.aaff, jimio, dveditz, tanvi_and_imelven, +1.415.832.aagg
Regrets
Chair
ekr, bhill2
Scribe
Brad Hill

Contents


<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

http://www.w3.org/2011/webappsec/track/

ISSUE-15: http://www.w3.org/2011/webappsec/track/issues/15

<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

violation types for default-src

http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0036.html

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>.

<ekr> http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0034.html

<mkwst_> mwest2

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].

CSP and HSTS breaking http src URIs

http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0034.html

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> yes

<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

<ekr> http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0045.html

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> http://www.w3.org/TR/UISafety/

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

<ekr> http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0044.html

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?

<ekr> http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0004.html

<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].

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-02-26 20:27:13 $