See also: IRC log
<bhill> Any volunteers to scribe if jrossi can't attend?
next on the list is tanvi.
<bhill> ...don't see her in chat yet, either
<jeffh> ah, zakim "knows" me........
<scribe> scribenick: ekr
<jeffh> moz was muddy for me too
<bhill> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0015.html
<bhill> csp and the threats from inline styles
<imelven> thanks brad
<bhill> Joint F2F April 25-26
bhill: proposed agenda, one test day
… perhaps friday, focus on CSP testing
<bhill> https://www.w3.org/2011/webappsec/track/actions/open
Action 92/Issue 32
<trackbot> Error finding '92/Issue'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
<imelven> hopefully we will have our unprefixed CSP stuff at least in nightly before the CSP testing day :)
<bhill> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0019.html
<bhill> that mail is about subject of how to identify non-hierarchial URIs
bhill: still working on 101
skipping 102 (no mike)
http://www.w3.org/2011/webappsec/track/actions/104
<imelven> dveditz cannot make the call today, fyi
http://www.w3.org/2011/webappsec/track/actions/105
bhill: not done yet
http://www.w3.org/2011/webappsec/track/actions/106: mike not on the call
http://www.w3.org/2011/webappsec/track/actions/107 http://www.w3.org/2011/webappsec/track/actions/108 not done
http://www.w3.org/2011/webappsec/track/actions/109 dveditz not on the call
https://www.w3.org/2011/webappsec/track/actions/111: complete
https://www.w3.org/2011/webappsec/track/actions/113
abarth: this is a standards political football.
my opinion is that we should reference the URL spec from whatwg
IETF wanted folks to reference their spec.
some people will be sad about that and complain
ekr: I don't think it's good to be abandoning the IETF spec.
abarth: we should leave this open, but there may
not be a good spec to reference
... propose we close the action and leave the issue
http://www.w3.org/2011/webappsec/track/actions/114: not done
http://www.w3.org/2011/webappsec/track/actions/115: adam will d o it eventually
http://www.w3.org/2011/webappsec/track/actions/116: mike was amenable to doing this
http://www.w3.org/2011/webappsec/track/actions/118: let the list hash it out
http://www.w3.org/2011/webappsec/track/actions/119: not done yet
<bhill> https://www.w3.org/2011/webappsec/track/issues/raised
bhill: two issues raised in the last two weeks
https://www.w3.org/2011/webappsec/track/issues/42
https://www.w3.org/2011/webappsec/track/issues/43
bhill: does this require any specific language int he CSP spec?
abarth: might be worth adding a note
bhill: abarth, can you volunteer to do this
<scribe> ACTION: abarth to propose language to spec to explain how custom elements are handled (see issue 43) [recorded in http://www.w3.org/2013/02/12-webappsec-minutes.html#action01]
<trackbot> Created ACTION-120 - Propose language to spec to explain how custom elements are handled (see issue 43) [on Adam Barth - due 2013-02-19].
bhill: blank blocked URIs...
abarth: this is the same issue as before with URIs.
bjoern is in one camp and people who implement browsers are in a different camp
bhill: since this is in a browser.
<bhill> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0017.html
<jeffh> as I see the two camps: the on-the-wire protocol camp; and the we-gotta-parse-whatever-is-handed-to-us (aka browser impls) camp;
<bhill> https://dvcs.w3.org/hg/content-security-policy/rev/001dc8e8bcc3
jeffh: well, I actually think that the argument is partly about whether these things are *called* URIs
<jeffh> that's another facet to the problem space, yes :)
abarth: the same issue came up when we did the origin draft.
we cited 3.2 of RFC 3986.
this section talksa bout a hierarchical element for a naming authroity
bhill: sounds good
adam, can you bring this to the list as a suggestion
<bhill> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0016.html
do any folks on the call have comments on this text?
will take silence as this being good to go.
http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0013.html
<bhill> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0013.html
we discussed this some at TPAC
is this too late and most UAs are already doing this?
<bhill> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0038.html
dveditz said this was ugly cruft
<scribe> <unknown>: apply the scheme on the page?
tanvi: if it's an HTTP page, allow HTTP or HTTPS. If it's an HTTPS page, allow HTTPS only
ekr: what about pages which assume they are fetched over HTTPS
bhill: my reading of dan's suggestion is that this should be an implicit property.
that CSP in HTTPS should mean no mixed content
<jeffh> ....and that having been fetched over https gives them certain sec props (and that's not necessarily correct)
jeffh: right.
bhill: is that in the current spec?
abarth: no real connection between mixed content blocking and a CSP header?
bhill: what if I specify a source without a scheme
abarth: if you don't provide a scheme, you inherit the scheme.
neil: I just tested this in chrome and that doesn't seem to be true
adam: can you provide the test case?
<jeffh> w3c@adambarth.com
<jeffh> yeah, send to list please :)
<imelven> just slightly active on the mailing list, adam :P
<imelven> this came up with hsts also, i brought it up last month or so i think
bhill: sounds like no objections to making "secure" behavior the default
abarth: what if you just supply a CSP policy that restricts video, you could still have mixed content images
<tanvi> http://www.w3.org/Security/wiki/Content_Security_Policy
bhill: what dan was proposing was that if you opt into CSP that mixed content should be blocked by default?
neil: idea was to allow HTTPS-only if you are on an HTTPS page but HTTP would imply both
tanvi: proposal is now that all CSP pages don't allow mixed content unless someone explicitly allows it
abarth: this seems like a model change
neil: yes.
<imelven> ekr: that was me, not neil
<imelven> both times
<imelven> sorry
No worries, I just can't pick up people's names well
<abarth> what about sites that host assists but set HSTS
<jimio> ^^ not sure how I'm making noise, not dialed in.
hah
<abarth> they'll redirect to HTTPS, which breaks the "inherit the scheme for HTTP pages" behavior
bhill: this seems to need some list discussion.
<abarth> that issue occurs without HSTS as well if there's a normal HTTP redirect to HTTPS
bhill: ian's agenda request
<bhill> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0015.html
imelven: spec currently says blocking inline styles shoudl block style elements and attributs
css object model should not be blocked
what is the difference between the style attribute and the CSSOM.
what's the threat?
<jeffh> CSSOM == css object model
best threat is using CSS selectors to steal passwords, but this seems to be only inline styles
a lot of pushback about what's in the spec and if it's usable in the real world
bhill: abarth, any comments?
<jeffh> apparently there's also this msg/thread: http://lists.w3.org/Archives/Public/public-webappsec/2012Dec/0047.html
abarth: I feel like your current feelings are different.
imelven: yeah, this is based on pushback from CSS people.
abarth: maybe we should reevaluate
imelven: one approach would be to make it more granular.
concern about decisions now being overtaken by new behaviors
abarth: proposed new token to allow attributes but not elements
imelven: please feel fre eto reply to my post
<imelven> it should totally be called unsafe-taco tho
<scribe> ACTION: imelven to propose some specification text to deal with allowing attributes but not elements [recorded in http://www.w3.org/2013/02/12-webappsec-minutes.html#action02]
<trackbot> Error finding 'imelven'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
<bhill> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0001.html
consensus is that yes, we should have inline CSS nonce if we have inline script nonce
abarth: if we think about the syntax, we may be able to have the nonce go in the src, we wouldn't need to make foo-nonce and bar-nonce
bhill: abarth, can you make this proposal
<scribe> ACTION: abarth to email the list with the generic src-nonce proposal (i.e., not specifically for each thing that could be srced) [recorded in http://www.w3.org/2013/02/12-webappsec-minutes.html#action03]
<trackbot> Created ACTION-121 - Email the list with the generic src-nonce proposal (i.e., not specifically for each thing that could be srced) [on Adam Barth - due 2013-02-19].
bhill: script hash
does anyone think this is a terrible idea
we are having a great discussion on the list. I would like to see someone volunteer to put together a proposal
<scribe> ACTION: nick to put together a proposed script-hash proposal [recorded in http://www.w3.org/2013/02/12-webappsec-minutes.html#action04]
<trackbot> Error finding 'nick'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
<imelven> got a link to the online form to register as a w3c user ?
<imelven> (http://www.w3.org/Help/Account/)