WebAppSec WG 2-Feb-2012 Teleconference -- 12 Feb 2013

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

WebAppSec WG 2-Feb-2012 Teleconference

12 Feb 2013

Attendees

Contents

Summary of Action Items