See also: IRC log
<ccarson> zakin, aacc is ccarson
<bhill2> neilm, are you OK to scribe - or did you already do it last time?
<neilm> did it last time, glad to do it again (unless someone wants to do it)
<bhill2> next on list is jimio
I'm here too
<bhill2> mind scribing?
no prob — I've probably forgotten some of my zakim shorthand
<bhill2> Scribe: Jim O'Leary
<bhill2> Scribenick: jimio
here, on mute (I'm Gvoice)
<bhill2> http://www.w3.org/2013/06/04-webappsec-minutes.html
<bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner
<wseltzer> ACTION-104?
<trackbot> ACTION-104 -- Adam Barth to follow up with Goog A11Y and UI teams on disabling browser features (UISafety obstruction check) for A11Y compatibility -- due 2013-01-29 -- OPEN
<trackbot> http://www.w3.org/2011/webappsec/track/actions/104
Adam: planning to give up on that action, to be marked as abandoned
<bhill2> https://www.w3.org/2011/webappsec/track/actions/104
<wseltzer> ACTION-141?
<trackbot> ACTION-141 -- Adam Barth to update CSP 1.1 default-scr language to be more general, including coverage of areas not specified by other directives -- due 2013-06-11 -- OPEN
<trackbot> http://www.w3.org/2011/webappsec/track/actions/141
adam: holding off on action-141 until type-fetching spec plays out
<bhill2> https://www.w3.org/2011/webappsec/track/issues/pendingreview
<bhill2> actually: https://www.w3.org/2011/webappsec/track/actions/pendingreview
115: old, 138: made a change, update the item (if people are happy we can close).
138/139/140, if people are happy, let's close these out
bhill2: LGTM, any other comments? (no comments - fine to mark complete)
... mark 101 closed as well, we have our own test server that we can use
... 124 still open (thank you globalsign for the free cert), the other 2 are UISecurity that haven't been addressed yet
<wseltzer> trackbot, close ACTION-142
<trackbot> Closed ACTION-142 Email bhill, ekr, and tobie re github setup.
dveditz: haven't heard any objections, can check these in and call the actions closed
<ekr> trackbot, close action-109
<trackbot> Closed ACTION-109 Add spec language to CSP 1.1 regarding certain directives not honored in META.
<ekr> trackbot, close action 97
<trackbot> Sorry, ekr, I don't understand 'trackbot, close action 97'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
<ekr> trackbot, close action-97
<trackbot> Closed ACTION-97 Propose spec language for policy-uri directive.
<trackbot> Sorry, wseltzer, I don't understand 'trackbot is particular about its -s'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
issue on URL vs URI terminology. do we talk about this now, or raise it as a separate issue? (to be logged, we're not going to resolve it on this call)
can accept report-uri and make report-url a synonym in the spec
no strong opinions in the room right now on uri vs url
wseltzer: guidance on "url vs uri" objection, TAG can make objections around architectural issues (if this 'broke the web', this would be a reason not to approve the spec)
consensus: we should do the right thing, and hopefully that is inline with what the TAG wants (let's discuss and have a response).
<tanvi> policy-href, policy-location ?
abarth: what about 'href' instead of url/uri? but.. it doesn't really matter too much personally
bhill2: should focus more on substance over style - what really matters is how clients treat the responses
... would prefer 'href' to 'location' if we did decide to change this, given precedence
(to be reviewed and brought back up with the list)
abarth: we'll have mike back for the next call (most likely)
<ekr> trackbot, close issue-49
<trackbot> Closed ISSUE-49 add http response code to report?.
<ekr> trackbot: close issue-50
<trackbot> Closed ISSUE-50 plugin-type directive and media source list for IE CLSID guids.
<ekr> trackbot, close issue-51
<trackbot> Closed ISSUE-51 How to handle externally defined <element> with <link rel=import>.
<bhill2> https://www.w3.org/2011/webappsec/track/issues/47
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/att-0057/meta.txt
<ekr> trackbot, close issue-51
<trackbot> Closed ISSUE-51 How to handle externally defined <element> with <link rel=import>.
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0102.html
bhill2: when originally raised, there were no objections other than a possible network retry on failure
no objections in the room to making this change
<bhill2> ACTION abarth to update CSP1.1 to change error handling behavior for loading blocked resources
<trackbot> Created ACTION-143 - Update CSP1.1 to change error handling behavior for loading blocked resources [on Adam Barth - due 2013-07-09].
bhill2: can we do this in a way that doesn't create dependencies between CSP and fetch spec?
abarth: don't want to get our spec blocked by an unstable reference that'll keep it from advancing
<bhill2> ACTION abarth to propose text on layering of fetch context types with CSP directives
<trackbot> Created ACTION-144 - Propose text on layering of fetch context types with CSP directives [on Adam Barth - due 2013-07-09].
bhill2: does anybody have a strong feeling that we should have one or the other, not both?
seems messy to have both (~75% overlap), though distinct
abarth: feels like these are redundant, we should pick one first
... if after implementing one, we hear from implementors about implementing the other, we revisit
mozilla: hash is superior (hash is good for static/caching, less easy to do poorly, code that uses async inline JS would be easier to implement)
<grobinson> https://developers.google.com/analytics/devguides/collection/gajs/asyncTracking
abarth: on the downside, if you have more than one script, it bloats your policy
neilm: has concerns about caching (@twitter)
... we probably wouldn't use nonce, due to potential caching issues
if the nonce is reused because of cache, you could maybe introduce predictable nonce that could be known to attacker (via DOM injection?)
abarth: cached page could include non-cached content that's different the next time it's loaded
bhill2: seems like we have strong usecases for both, that's why we want to see if there are strong objections to both
(not too many people arguing for nonce on the call, but could be due to attendance)
script-hash might also be helpful in content-integrity spec
bhill2: people are still experimenting with both. hear that google has invested in script-nonce, but google understands that it's something that might change
... still need solid spec-text on handling script-hash, should also add a note that both nonce&hash are being investigated and one will likely become deprecated
<bhill2> proposal: if we get a solid hash source proposal, we can include it in the 1.1 draft with a warning note that it is likely only one of either nonce or hash will advance to Rec
<bhill2> dveditz: minimum of 1
minimum nonce length of 1. should accept b64 chars as some people are sending down b64 encoded nonces
<bhill2> ACTION abarth to update nonce-value directive to allow b64, b64url chars, specify minimum length of 1
<trackbot> Created ACTION-145 - Update nonce-value directive to allow b64, b64url chars, specify minimum length of 1 [on Adam Barth - due 2013-07-09].
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013May/0054.html
q: is this a new question? we've talked about this in the past
<bhill2> old thread: http://lists.w3.org/Archives/Public/public-webappsec/2013May/thread.html#msg12
<bhill2> ignore old thread, link, wrong...
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013May/0060.html
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013May/0059.html
options: forbid connections from workers when policies aren't exactly equal. could we create copies of workers that aren't shared?
bhill2: could workers be used to bypass restrictions: run eval, etc?
abarth: could do something similar with iframe today (load a new one with no CSP policy)
<bhill2> dveditz: perhaps best option is to supply policy with the worker?
should we issue a warning when creating a same-domain iframe with a different CSP header?
<bhill2> dveditz: should we issue a warning when loading a same-origin iframe with no or a different CSP policy?
<bhill2> ACTION dveditz to respond to list, propose setting worker policy from header rather than inheriting it
<trackbot> Created ACTION-146 - Respond to list, propose setting worker policy from header rather than inheriting it [on Daniel Veditz - due 2013-07-09].
neilm: brought a nickgreen thread back to life on the list re: hashing
bhill2: proposal needs some brushing up
thanks: )