See also: IRC log
<bhill2> aha.. so in the "status" window, "/invite zakim #webappsec"
<bhill2> ekr sends his regrets
<wseltzer> [Next call August 13]
<bhill2> http://www.w3.org/2013/06/04-webappsec-minutes.html
<wseltzer> [for future ref: scribe instructions https://www.w3.org/2008/xmlsec/Group/Scribe-Instructions.html ]
<bhill2> scribenick: mkwst
bhill2: objections to minutes?
everyone: ...
bhill2: agenda bashing!
... new topics?
<bhill2> http://www.w3.org/2011/webappsec/track/actions/open?sort=owner
bhill2: adam and dan aren't on the call. skipping.
<tanvi1> dan may be running late
bhill2: action-127
mkwst: will address both issues this week.
deveitz: hi.
bhill2: dan, how about those open actions?
dveditz: nothing to add since last time.
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0003.html
bhill2: responded to that with
some items still outstanding.
... moved from 'script-nonce' to nonces as a source
expression.
... worth trying the same for 'script-hash'
several folks: yup. makes sense for me too.
bhill2: ni: scheme?
... semicolons are banned, and would need to be encoded (and
ugly)
... but it exists, and its something we should look at as they
might have already worked out some of the corner cases.
mkwst: verbose and ugly, but worth looking at.
dveditz: aren't hashes verbose and ugly?
bhill2: we could propose an alternate delimiter.
mkwst: where would we propose that?
bhill2: "use the rfc??? syntax with the following modification"
mkwst: seems like a reasonable solution.
dveditz: 'ni' is more like other url schemes, which is good.
bhill2: reusing common
conventions.
... sounds like a reasonable place to start exploring.
dveditz: concern about proposal
to convert to utf-8 and hash that.
... script is delivered to the browser in some way, can't we
just hash what we get?
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0004.html
bhill2: i had the same concern in
my reply.
... ^^
... utf-8 is nonpreferred for some languages.
dveditz: lots of text content, but lots of script?
bhill2: inline script === text.
dveditz: hash only for content of script tag, right?
bhill2: what that turns into
depends on the document's encoding.
... differences between utf-8 and other encodings.
dveditz: server sends script and encoding, we should trust it.
bhill2: force a document to
declare an explicit encoding.
... resolves the problem of potentially rehashing/comparing
content.
dveditz: may be difficult for
Firefox to get access to the raw bytes.
... we may have to bite it off anyway.
... having bytes come out with different hash because of
charset seems wrong. bytes are bytes.
yoav: not reencoding to utf-8 on
the browser sounds like the right thing to do.
... error prone.
bhill2: encoding = open question.
needs more exploration.
... moving on...
... which algorithms should we support?
<dveditz> yoav was in particular thinking of the problems the server would have trying to hash it according to what it thought a browser would encode it as
bhill2: rfc5920: agreement in
code points with webcrypto?
... allow truncation of the hash?
... xml digital signatures did.
<tlr> after a decade
bhill2: don't want to repeat the
one-character-truncation problem.
... canonicalization? no?
... might not be in control of the developer. perf.
optimizations/transformations.
mkwst: bytes is bytes sounds good.
dveditz: optimizing proxies?
mkwst: mobile operators that optimize whitespace?
<dveditz> transport compression ought to do that well enough, right?
yoav: not predictable. optimizing proxies would need to avoid those transformations.
mkwst: i don't think we should try to support the pagespeed case. code is different when it comes out the other end.
bhill2: next. scripts can have
different content-types. vbscript!
... inert inline script with nonexecutable content-type.
... should we include that?
mkwst: what's the threat?
bhill2: valid code in two languages? perhaps far-fetched.
<tlr> comment formats
dveditz: hashes have to be the
same. seems unlikely.
... would the text of the script tag remain in the dom?
... just execution, i suppose.
bhill2: yeah.
dveditz: we don't load non-matching scripts for the src case.
bhill2: twitter uses inline
JSON.
... still in the spirit of things.
... algorithm agility.
... sha-4? if the browser doesn't understand the hash type, how
does it fail?
... what's the failure mode?
dveditz: can't compute a matching hash, will block the ununderstood code.
bhill2: specify sha-1 and sha-3
hashes for script. what should the UA do?
... perhaps only accept the strongest hashing algo. it knows
about?
dveditz: what does "strongest" mean.
bhill2: ordering should be left
to the UA.
... specify multiple algorithms, but include a hash in each
algorithm for each resource?
dveditz: not always the case that multiple hash types means multiple listings for each resource.
bhill2: composing policies might also be difficult.
dveditz: only inline
content?
... ni: can include a domain; if we hash loaded content, it
would be nice to force usage for performance reasons.
... if you see two hash types, you have to hash all content
twice.
... performance issues.
bhill2: if sha-1 is broken, what's the migration strategy?
mkwst: UA sniffing?
<inserted> scribenick: dveditz
<mkwst> <sorry, baby. back in a sec. can someone take over scribing?>
yoav: what's the problemw ith accepting only the strongest hash? wouldn't that avoid the perf penalties
dveditz: the different hashes
might be from different sources and cover different chunks of
content
... also, which is "strongest"? we'd have to define
yoav: would the policy refer to content ids?
bhill2: I think writing this out
and sending it to the list would be the right thing to do
here
... any volunteers to improve this proposal?
... neil, can you advocate for this proposal?
neilm: sure
<bhill2> list from: http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0004.html
<bhill2> ACTION neilm to propose updated hash source text to list addressing http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0004.html
<trackbot> Created ACTION-147 - Propose updated hash source text to list addressing http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0004.html [on Neil Matatall - due 2013-07-23].
<mkwst> bhill2: thanks neilm!
mkwst: I don't think the scribe will get my stuff automatically... you may want to cut and paste it back
unless there's some magic commands
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0006.html
<mkwst> bhill2: post from ian: ^^.
retroactively?
:-)
<bhill2> https://bugzilla.mozilla.org/show_bug.cgi?id=873302
<mkwst> dveditz: we don't block innerHTML, which can be eval-like.
<inserted> scribenick: mkwst
<wseltzer> i|bhill2: thanks neilm!
dveditz: is that a bug?
bhill2: there's a request to do
something about that. script-src, innerhtml directive,
etc.
... my understanding of cssom is incomplete.
... sounds reasonable on its face.
dveditz: does anyone know of
problems that people have had with cssom injection
problems?
... if scripts are approved, that might be good enough.
bhill2: no strong opinions on
today's call.
... table this, poke the list.
<bhill2> http://webappsec-test.info/~bhill2/pub/CORS/index.html
bhill2: anne won't be editing the spec, licensing.
<bhill2> diffmarked verison at: http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FCR-cors-20130129%2F&doc2=http%3A%2F%2Fwebappsec-test.info%2F~bhill2%2Fpub%2FCORS%2Findex.html
<bhill2> (all in email of : http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0009.html )
bhill2: only ~2 substantive
changes.
... change reference to the Fetch spec.
... whatwg spec, not stable, not likely to become stable in the
timeline we're looking at.
... CORS shouldn't rely on it. should instead use fetching
resources from html5.
tlr: html5 is in cr.
... support changing the reference. will need to talk to them
to see if fetching there is stable.
... it's the right step, but talk with HTML after making the
change.
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0078.html
<bhill2> add 204 as valid OK status code
bhill2: other change: add 204 as
valid status code.
... will need some test code.
... mozilla implemented that, not sure about webkit.
... you get 7 minutes of your life back! enjoy!
... next call in one month, aug 13.