See also: IRC log
<neilm> sorry, i'll be a little late
<klee> hi, i'm the 866 number
<bhill2> scribenick: dveditz
bhill2: approval of the minutes? any objections?
... consider the minutes approved
... additional business to add?
... none, ok.... open issues review
bhill2: UI security is still backburnered
<neilm> Zakin, aadd is neilm
bhill2: dveditz is the only other one with an item
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)
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
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].
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
dveditz: probably don't need both the SOS and cookie scope feature
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
tanvi: thanks for scribing while I was talking
bhill2: is there a retroactive way to include those bits?
<tanvi> dveditz: no problem