15:22 < bhill2> ... reason for removing was that it was believed that it should be part of a different spec 15:22 < bhill2> ... perhaps things like disabling content sniffing from user agent which is already a different header 15:22 < bhill2> dveditz: is there only room for one option after ? 15:22 < bhill2> francois: we haven't defined exactly what we would put in there, but a rough format for specifying option names and values 15:23 < bhill2> ... and can be more than one, looks a little bit like a query string 15:23 < bhill2> jww: syntax is explicit in allowing multiple name/value option pairs 15:23 < bhill2> dveditz: with ? 15:23 < bhill2> jww: maybe a ; 15:23 < bhill2> dveditz: make sure we test it with bogus options to make sure we ignore them 15:23 < bhill2> ... are unknown options ignored or do they break integrity? 15:23 < bhill2> francois: all will be ignored now 15:24 < bhill2> dveditz: ok, hoping they would be ignored 15:24 < bhill2> jww: chrome ignores for now 15:24 < bhill2> jww: also is separated by multiple question marks 15:25 < bhill2> bhill2: we could make the x509 mistake and a have a critical bit, but let's not make that mistake 15:25 < bhill2> dveditz: we need to be clear they are options, and unknown ones MUST be ignored 15:26 < bhill2> francois: last change is possibly the biggest one 15:26 < bhill2> ... require CORS or same origin for it to be eligible for SRI 15:26 < bhill2> ... used to also include publicly cachable, CORS-eligible 15:27 < bhill2> ... now it has to be loaded via CORS, allowing us to mitigate against brute-forcing resources with few possible contents 15:27 < bhill2> ... downside is this will likely harm adoption as all resources now have to opt into CORS 15:28 < bhill2> ... one of the main reason this spec was started, in the short term not going to work because jQuery doesn't expose the CORS headers 15:28 < bhill2> ... can we evangelize to them and get them to add the headers? I hope we can. 15:28 < tanvi> does jquery plan to change that? 15:28 < bhill2> jww: same-origin resources don't need CORS headers 15:28 < tanvi> nevermind, just answered 15:28 < bhill2> francois: requirement is CORS or same-origin 15:29 < bhill2> freddyb: we did talk to GitHub and they enabled CORS for everything hosted on github pages 15:29 < bhill2> ... if we can reach someone it shouldn't be too hard to convince them for static resources like this 15:29 < tanvi> is there an example of the brute force attack? 15:29 < bhill2> dveditz: that's too bad 15:29 < terri> is there a backup plan if evangelizing isn't successful? 15:29 < freddyb> tanvi: http://www.w3.org/TR/SRI/#cross-origin-data-leakage-1 15:29 < bhill2> dev: much easier to go back to publicly cacheable dada, but I think that evangelization will work 15:30 < bhill2> dveditz: will be good to evangelize that for other reasons 15:30 < bhill2> jww: issue is resources for which you don't control the headers 15:30 < bhill2> ... don't want to give an oracle over non-public content 15:31 < bhill2> francois: talked with anne and we really tried to make this work differently 15:31 < bhill2> ... but there are pages on intranets and home routers which may be publicly cachable but only on that network 15:31 < bhill2> ... may contain secrets like a wifi password we don't want to leak 15:31 < tanvi> freddyb: i mean an example in the wild 15:32 < bhill2> s/francois/freddyb 15:32 < bhill2> mkwst: have you considered other options? like anonymous requests? 15:32 < bhill2> dev: that's what CORS * does? 15:32 < tanvi> if there is no cors header, then make the request without cookies 15:32 < bhill2> mkwst: a variant that skips CORS checks but still is anonymous 15:32 * freddyb nods 15:33 < bhill2> dev: we can experiment with looser policies going ahead, but hard to take away later 15:33 < bhill2> jww: lots of people are sad about this 15:33 < tanvi> me too 15:34 < bhill2> bhill2: mike's suggestion falls to the same issues as other network-topology authenticated resources like home routers/intranets 15:34 < bhill2> (maybe we can opt private address ranges out explicitly) 15:35 < bhill2> francois: first question we want input on: should there be headers that disable eligibility? 15:35 < bhill2> ... simpler now, still in spec, but still excludes a few things like authentication, refresh... 15:35 < bhill2> http://w3c.github.io/webappsec/specs/subresourceintegrity/#agility-1 15:36 < bhill2> freddyb: not that we should define headers, but they should be defined in fetch, anne's suggestion is to put it in fetch where it already is but not reinvent the wheel 15:36 < bhill2> (sorry link should be: http://w3c.github.io/webappsec/specs/subresourceintegrity/#is-resource-eligible-for-integrity-validation) 15:36 < bhill2> francois: so answer could be to refer to a specific part of the fetch spec? 15:37 < bhill2> +1 15:37 < francois> https://github.com/w3c/webappsec/issues/317 15:37 < bhill2> francois: next part, how to handle ineligible / invalid resources 15:38 < bhill2> ... previously we've determined to fail open in invalid metadata to enable forward compat 15:38 < bhill2> ... this issue is about how exactly to define that fail open behavior 15:39 < bhill2> dveditz: what about future algorithms, e.g. SHA3 15:39 < bhill2> ... really old clients won't know and enforce this at all 15:40 < bhill2> ... why should a client that knows about SRI but not the new algo be worse than a client that doesn't know about SRI at all? 15:40 < bhill2> francois: difference here is if author adds integrity attribute for resource that also has CORS headerrs 15:41 < bhill2> ... (if you are missing CORS headers, integrity check never happens) this is to make it more obvious that we would block the load 15:41 < bhill2> freddyb: should make a distinction between unsupported algorithm because it is unknown or because it is known and unsupported 15:42 < bhill2> ... that would mean whenever we remove an algorithm it should generate a warning because algorithm does not suffice 15:42 < bhill2> dveditz: I disagree, this breaks pages that are otherwise perfectly fine 15:42 < bhill2> ... put a warning on the console 15:43 < bhill2> freddyb: only time to fail closed would be we did perform the check but hashes didn't add? 15:44 < tanvi> for non-eligible, the integrity check is not going to happen anyway because their is no cors. so even if they fixed the integrity attribute, the load would still complete without checking integrity 15:45 < tanvi> what's the point of blocking those loads? 15:46 < bhill2> bhill2: question, what happens if CORS eligible status changes, do we fail closed? 15:46 < bhill2> dev: crossorigin=anonymous forces fail if CORS headers are missing before integrity check happens anyway 15:47 < bhill2> dev: agree with brad that guarantee UA is giving is to website, not user, can give warnings to console 15:47 < bhill2> dveditz: can we fire another event or will they not look for that? 15:47 < bhill2> dev: historically this is always console warnings 15:48 < bhill2> terri: worried about a hash broken and then actual collisions being created 15:48 < bhill2> dev: we leave it to the UA, if it is an algorithm you know to be wrong, the UA can fail closed but it is up to the UA 15:49 < bhill2> terri: will this be a problem for multiple hashes if oldest one is bad and only one makes the pass? 15:50 < bhill2> francois: you can specify more than one algorithm, and you can specify more than one hash 15:50 < bhill2> ... first pass is to find the best algorithm and discard the rest, next pass is to check against the remaining list of the hashes with the best algorithm known 15:51 < bhill2> TOPIC: Should we mention MIME types in the security considerations? #302 15:51 < bhill2> https://github.com/w3c/webappsec/pull/302 15:52 < bhill2> canonical example is the famous "GIFAR" 15:52 < bhill2> which can be a GIF and JAR file 15:52 < bhill2> http://softwareas.com/svg-and-vml-in-one-chameleon-file/ 15:53 < bhill2> freddyb: assumption is that if you're tagging something with a hash you have examined it somehow 15:54 < bhill2> terri: this is not GIFAR 15:54 < bhill2> dev: integrity only captures the body of the response, and other things control the behavior 15:54 < bhill2> ... think its fine to leave this for options in future versions 15:55 < bhill2> ... target is CDN, not arbitrary user-controlled content 15:56 < terri> Security journal with polyglot pdf+gz+??? files: https://www.alchemistowl.org/pocorgtfo/ (Note: swearing in the link, if you're opening it up in a public location) 15:56 < bhill2> freddyb: for now we only support link and script, for script there is just javascript and vbscript 15:56 -!- jww [~jww@team.cloak] has quit [Ping timeout: 180 seconds] 15:56 < bhill2> dveditz: I would leave it out for now 15:57 < bhill2> ... other specs address this, most of these chameleon resources are useful in an attack scenario e.g. where you have user uploaded content 15:57 < bhill2> ... not going to have an integrity attribute in the place where an image is being misused as a jar file, e.g. 15:57 < bhill2> ... we should worry about it elsewhere 15:57 < bhill2> +1 good point that attack location will not include integrity metadata anyway 15:58 < bhill2> dev: intent is for protecting your content, not someone else's 15:58 < bhill2> ... creating a 2nd preimage for benign content is much harder than creating a deliberate collision 15:59 < Zakim> -[Microsoft] 15:59 < Zakim> -jww 15:59 < Zakim> -mkwst 15:59 < Zakim> -[Mozilla] 15:59 < Zakim> - +1.415.857.aagg 15:59 < Zakim> -drx-goog 15:59 < Zakim> -tanvi 15:59 < Zakim> -BHill 15:59 < Zakim> -francois 15:59 < Zakim> -terri 16:00 < Zakim> -freddyb 16:00 < Zakim> SEC_WASWG()3:00PM has ended 16:00 < Zakim> Attendees were BHill, +1.418.907.aaaa, +1.415.736.aabb, jww, +1.206.876.aacc, francois, drx-goog, dveditz, +1.310.597.aadd, +1.503.712.aaee, [Microsoft], freddyb, tanvi, terri, 16:00 < Zakim> ... +1.650.253.aaff, mkwst, +1.415.857.aagg