WebAppSec WG teleconference, 3 Dec 2013

<ekr> ekr is at Mozilla

minutes approval

http://www.w3.org/2013/11/19-webappsec-minutes.html

(corrected from agenda)

no objections to unanimous approval of minutes

CORS is approved to be published as a Proposed Rec, just waiting a poll setup to allow AC reps to file comments

tracker

https://www.w3.org/2011/webappsec/track/actions/open?sort=owner

<ekr> I will be aroundish

<dhuang3> bhill: a number open actions to resolve next meeting.. Is 17th good time?

plan on cancelling Dec 31st?

<neilm> no objections on either

<gopal> 17th ok with me

Action bhill2 to cancel Dec 31st call

<trackbot> Created ACTION-157 - Cancel dec 31st call [on Brad Hill - due 2013-12-10].

Return of CSP policy for Workers, SharedWorkers (ISSUE 146)

http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0008.html

<dhuang3> ekr: .. came to consensus that we needed to update the spec..

http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0025.html

<ekr> dhuan3: that wasn't me talking. probably bhill2?

<dhuang3> sorry

<dhuang3> bhill: do we see in future that workers might not be same-origin?

<dhuang3> ... workers not exactly same as iframes, maybe another directive to cover workers

<dhuang3> worker-src? consider issues where workers created from data blobs, etc.. ? should summarize ideas and proposals to list

roughly: dveditz in favor of keeping script-src, brad and garrett in favor of a new directive but not frame-src, abarth neutral

<dhuang3> dan: currently, workers don't get access to dom, cookies, but have access to localstorage, indexdb, or possibly more in future

brad wonders what a non-same origin worker would look like from a security model

<dhuang3> dan: according to ian, ... we should expect cross-origin workers, ... workers more like frame than script so don't like the idea of lumping into frame-src. .... compatibility issues?

CORS and 304

http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/

http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0029.html

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

<dhuang3> adam: CORS is more widely used now so might not want to break things..

<dhuang3> bhill: is this apache bug? the CORS allow header should not be stripped?

thanks wendy

spec says that headers should be stripped unless used for caching.. is Access-Control-Allow-Origin a header influencing caching?

dveditz: likes Firefox's behavior, wants to know what Adam thinks

abarth: understands, but given wide use is a little scared to change the behavior
... and debugging caching issues in the field to understand root causes is difficult
... can do it if important, preference is to be conservative

let's follow up on list

b64 padding in script-hash

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

sounds like garrett's patch has no objections

CfC for UI Security LC WD

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

<dhuang3> adam: will merge garrett's patch

dveditz: we may have issues on name change with IETF WebSec

action bhill2 to raise frame-options vs. frame-ancestors name on IETF WebSec list

<trackbot> Created ACTION-158 - Raise frame-options vs. frame-ancestors name on ietf websec list [on Brad Hill - due 2013-12-10].

<dhuang3> dan: frame-ancestors is more self-documenting, but frame-options would work... wouldn't mind either... But frame-options in UI Security is kind of confusing

Editors for sub-resource integrity

I have received interest from Fredrick Braun of Mozilla, Joel Weinberger of Google and Devdatta Akhawe of UCBerkeley to serve as editors. If you have concerns, please bring them directly to ekr or myself.

Adjourned.