<neilm> sorry, i'll be a little late

<klee> hi, i'm the 866 number

<bhill2> scribenick: dveditz

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0020.html

Minutes Approval

<bhill2> http://www.w3.org/2013/08/27-webappsec-minutes.html

bhill2: approval of the minutes? any objections?
... consider the minutes approved
... additional business to add?
... none, ok.... open issues review

Actions Review

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

bhill2: UI security is still backburnered

<neilm> Zakin, aadd is neilm

bhill2: dveditz is the only other one with an item

blob, etc. urls

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0010.html

dveditz: nothing new to report, investigating implementation

<neilm> Zakin, aadd is neilm

bhill2: currently have inconsistent behavior with data: and blob: between Firefox and chrome

bhill: chome always treats as equiv and same as "self" and *
... firefox excludes from * and treats a little differently
... proposal to list was to exclude all schemes for inline content from matching *
... dan proposed broadening, * should only match self's scheme (or allow https "upgrade" for http: self)

<bhill2> http://*

<bhill2> https://*

bhill: reason to exclude inline content because they aren't being retrieved, they are repackages

<bhill2> If you want all schemes - e.g. img-src may not be considered security sensitive, no way to specify that

<bhill2> dveditz: yes, unless we introduce a *://* token... ugly

dveditz: but * meaning all schemes means safe policies must use the verbose http://* https://*

bhill: treating inline schems as 'self' opens up xss-like (or eval-like) problems

<tanvi> bhill2 - proposal - for everything but script-src, we consider data/blob to be equivalent to self. for script-src we consider it equivalent to eval. because you can take string content anywhere in the dom and create a blob uri for it and inject a script element into the dom and set the source to be that blob uri.

<tanvi> dveditz - that is complex. it may be more safe but it seems like we should treat data/blob consistently one way or another.

<tanvi> dveditz - if you allow blob everywhere except in script-src and object-src (probably), then people have to ask a question every time they use as to whether they need to add it to csp

<tanvi> dveditz - maybe more consistent to just say inline data chunks need to be explicitly allowed if you want to use them

<tanvi> dveditz- Neal, does twitter use data/blob and have any thoughts? Neal - only use data urls for images. dont think use any blobs.

<tanvi> Neal - if its a blob, whether or not it should execute, shoudl be dependent on the uri used. if throw in script-src, wont' work unless you whitelist it specifically

bhill: one of the core rules is no code from strings. this is a clear and obvious bypass

dveditz: I agree

<bhill2> action dveditz to document proposal of simply excluding blob:, data:, etc from matching * everywhere, no explicit tie to unsafe-eval

<trackbot> Created ACTION-149 - Document proposal of simply excluding blob:, data:, etc from matching * everywhere, no explicit tie to unsafe-eval [on Daniel Veditz - due 2013-09-17].

Close feature set of CSP 1.1?

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0019.html

bhill: if blob must be specified everywhere then putting it in default-src is the equivalent of unsafe-eval. need to put a warning in the spec at least
... need to specify/adjust our schedule again as part of coming up for consideration by the board group
... so should we declare the feature set closed for 1.1
... I've put a proposal on the mailing list
... not a complete proposal, assuming the more settled new features are part of it
... haven't heard any calls to remove any of those other features
... group 1) resolved/settled and in the spec, group 2) mostly settled, in process, and 3) new proposals
... do people think it's an appropriate time to close the feature set

<neilm> +1 (avoiding muting/unmuting)

dveditz: yes, it's a good time to draw lines

bhill: will move call for consensus for the features on the bubble to the list

<neilm> bye!

dveditz: probably don't need both the SOS and cookie scope feature

<Danesh> thx!

<klee> bye

bhill: the cookie scope proposal was more CSP-like

<bhill2> action bhill2 to post a CfC to the list on closing the CSP 1.1 feature set

<trackbot> Created ACTION-150 - Post a cfc to the list on closing the csp 1.1 feature set [on Brad Hill - due 2013-09-17].

<bhill2> rrsagent make minutes

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
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

WARNING: No "Present: ... " found!
Possibly Present: Google IPcaller Mozilla P2 aaaa aabb aacc aadd bhill bhill2 danesh dveditz gmaone grobinson https klee mkwst_ neilm odinho peleus puhley scribenick tanvi tanvi_grobinson timeless tlr trackbot wseltzer
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Regrets: ekr
Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0020.html
Got date from IRC log name: 10 Sep 2013
Guessing minutes URL: http://www.w3.org/2013/09/10-webappsec-minutes.html
People with action items: