W3C

WebAppSec WG 2-Feb-2012 Teleconference

12 Feb 2013

Agenda

See also: IRC log

Attendees

Present
abarth, ekr_, gmaone, ccarson, neil, bhill2, jimio, gopal, jeffh, tanvi_and_imelven
Regrets
Chair
bhill2, ekr
Scribe
ekr

Contents


<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/)

Summary of Action Items

[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] ACTION: nick to put together a proposed script-hash proposal [recorded in http://www.w3.org/2013/02/12-webappsec-minutes.html#action04]

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-02-26 20:15:08 $