19:56:54 <RRSAgent> RRSAgent has joined #webappsec
19:56:54 <RRSAgent> logging to http://www.w3.org/2015/01/12-webappsec-irc
19:56:56 <trackbot> RRSAgent, make logs world
19:56:56 <Zakim> Zakim has joined #webappsec
19:56:58 <trackbot> Zakim, this will be WASWG
19:56:58 <Zakim> ok, trackbot, I see SEC_WASWG()3:00PM already started
19:56:59 <trackbot> Meeting: Web Application Security Working Group Teleconference
19:56:59 <trackbot> Date: 12 January 2015
19:57:08 <wseltzer> zakim, who is here?
19:57:08 <Zakim> On the phone I see mkwst
19:57:09 <Zakim> On IRC I see RRSAgent, bhill2_, gmaone, francois, tanvi, dveditz, bhill2, terri, schuki, edulix, renoirb, Josh_Soref, tobie, timeless, mkwst, freddyb, wseltzer, trackbot
19:58:39 <Zakim> +??P2
19:58:46 <freddyb> Zakim, I am ??P2
19:58:46 <Zakim> +freddyb; got it
19:59:17 <Zakim> +Wendy
20:00:23 <bhill2_> bhill2_ has changed the topic to: https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0119.html
20:00:32 <Zakim> + +1.206.348.aaaa
20:00:36 <Zakim> + +1.418.907.aabb
20:00:41 <bhill2_> zakim, aaaa is bhill2_
20:00:41 <Zakim> +bhill2_; got it
20:00:59 <francois> zakim, aabb is francois
20:00:59 <Zakim> +francois; got it
20:01:01 <bhill2_> Meeting: WebAppSec WG Teleconference 12-Jan-2015
20:01:04 <bhill2_> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0119.html
20:01:10 <bhill2_> Chairs: bhill2_, dveditz
20:01:30 <bhill2_> zakim, who is here?
20:01:30 <Zakim> On the phone I see mkwst, freddyb, Wendy, bhill2_, francois
20:01:31 <Zakim> On IRC I see RRSAgent, bhill2_, gmaone, francois, tanvi, dveditz, bhill2, terri, schuki, edulix, renoirb, Josh_Soref, tobie, timeless, mkwst, freddyb, wseltzer, trackbot
20:01:36 <Zakim> +??P13
20:02:00 <gmaone> Zakim, ??P13 is me
20:02:00 <Zakim> +gmaone; got it
20:02:11 <deian> deian has joined #webappsec
20:02:24 <Zakim> + +1.646.355.aacc
20:02:42 <wseltzer> zakim, aacc is deian
20:02:42 <Zakim> +deian; got it
20:03:11 <Zakim> + +1.310.597.aadd
20:03:12 <bhill2_> Scribenick: deian
20:03:28 <Zakim> +[Mozilla]
20:03:38 <dveditz> Zakim, Mozilla has dveditz
20:03:39 <Zakim> +dveditz; got it
20:03:47 <tanvi> zakim, aadd is tanvi
20:03:47 <Zakim> +tanvi; got it
20:04:35 <bhill2_> jww will dial in after 12:30
20:05:03 <bhill2_> TOPIC: Minutes Approval
20:05:04 <deian> first topic: minutes approval
20:05:35 <bhill2_> http://www.w3.org/2014/12/15-webappsec-minutes.html
20:05:55 <bhill2_> minutes approved by unanimous consent
20:05:56 <deian> bhill2_: no objections, approved
20:05:59 <Zakim> +[Microsoft]
20:06:04 <deian> bhill2_: TOPIC: Agenda Bashing
20:06:16 <Zakim> + +1.408.463.aaee
20:06:18 <bhill2_> zakim, [Microsoft] has David Walp
20:06:18 <Zakim> +David, Walp; got it
20:06:29 <wseltzer> TOPIC: Agenda Bashing
20:06:32 <deian> wseltzer: thanks!
20:06:41 <terri> Zakim, aaee is me
20:06:41 <Zakim> +terri; got it
20:06:50 <DWalp> DWalp has joined #WebAppSec
20:07:02 <deian> dveditz: being able to set an attribute that says don't load MIX content in subresources. is that too new of an idea? is it too late to get it in v1?
20:07:17 <deian> mkwst: why don't we add that to the MIX section
20:07:30 <deian> dveditz: a version made it into editor draft, we shoudl talk about it
20:07:36 <deian> bhill2_: sounds good
20:07:59 <deian> bhill2_: any other things for agenda bashing?
20:08:29 <bhill2_> TOPIC: Ask your AC reps to indicate support for the charter.
20:08:38 <bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0236.html
20:08:58 <deian> bhill2_: approved by w3c, call was sent out to all commitee reps to indicate support/concerns.
20:09:20 <deian> bhill2_: contact your AC rep and encourage them to vote/indicate support so we can get that wrapped up and being on our new deliverables
20:09:27 <bhill2_> TOPIC: Microsoft's LC comments on MIX?
20:09:59 <deian> bhill2_: david you asked that we delay moving to recommendation
20:10:27 <deian> david: (nick?) will send email to update on microsoft's status
20:10:40 <wseltzer> s/nick?/DWalp/
20:10:43 <mkwst> https://w3c.github.io/webappsec/specs/mixedcontent/#strict-checking
20:11:01 <dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0095.html
20:11:14 <deian> dveditz: link is to spec. disussion started in mid december (link above)
20:12:13 <deian> dveditz: mkwst said that its not somethign we should add to CR since its a new feature. it's an interesting features, but implementers are asking whether they need to implement it. we should take a full process to look at this feature
20:12:49 <deian> bhill2_: we should put this into experimental
20:13:08 <deian> mkwst: if people think we should take more time, we should make sure not to put it in CR draft.
20:13:55 <deian> mkwst: this is relatively small feature. implimentation is faily trivial. I'd like to try to have it in
20:14:14 <deian> dveditz: other option is to go back to LC and add it there
20:14:28 <deian> DWalp: microsoft will make replies to comments we put out
20:15:12 <deian> bhill2_: we don't have to do formal LC, but we don't have to do it this way if we find that it can be added to CR and marked as experimental (couldn't hear that?)
20:15:45 <deian> bhill2_: there is some precedence for it especially given its similarlity to sandboxing turning off scripting.
20:15:56 <deian> bhill2_: its probably not any worse than sandboxing scripting
20:15:56 <mkwst> https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0128.html is that thread.
20:16:20 <deian> dveditz: did the attribute version of this go away?
20:16:33 <deian> mkwst: in the ED it sets the flag and is inherited down
20:17:15 <deian> mkwst: ...hard to hear.. but says we shold go back to list on this
20:17:42 <deian> dveditz: we haven't had any time to look at implications of implemenation. seems like a fine idea, but we want to make sure that we can accomplish the spec if it makes it in
20:18:06 <deian> dveditz: although our arch is different from chrome, happy to hear that you didn't have any trouble implementing
20:18:12 <bhill2_> TOPIC: Objection to MIX by the Director
20:18:19 <bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0002.html
20:19:08 <wseltzer> [not in his capacity as director, but as a concerned individual]
20:19:11 <deian> bhill2_: tim berners less commented on MIX. had concern that there are lots collections of open data on web and it's important that web apps access this
20:19:51 <wseltzer> q+
20:20:01 <bhill2_> ack wseltzer
20:20:04 <deian> bhill2_: spawened large discussion thread. no updates since bhill2_'s last comments. will find out if there is objection when moving to CR
20:20:23 <deian> wseltzer: at the moment he is not formally objecting as director, but as web developer of long standing
20:20:57 <deian> bhill2_: anyone know if there are designated experts on open data?
20:21:27 <deian> bhill2_: first data point didn't event set CORS, so MIX wouldn't break it. need expert on this
20:21:27 <wseltzer> s/designated/subject matter/
20:21:40 <deian> mkwst: we can assume that the # served over HTTPS is low
20:21:52 <deian> dveditz: more concerned about them using CORS so that they are sharable
20:22:17 <deian> bhill2_: if they all have to make updates to enable CORS anyway, there is less corcerned to ask them to enable HTTPS
20:22:34 <deian> bhill2_: but if they're already widely available today, then this is a different issue
20:22:57 <deian> wseltzer: as a first point of outreach, will reach out to w3c groups on open data
20:23:33 <wseltzer> ACTION: wseltzer to ask open data/linked data groups for info on data publishing for use in secure context
20:23:33 <trackbot> Created ACTION-209 - Ask open data/linked data groups for info on data publishing for use in secure context [on Wendy Seltzer - due 2015-01-19].
20:25:14 <deian> bhill2_: other suggestion is to be mroe agressive to update HTTP links to HTTPS that would otherwise be broken by MIX
20:25:25 <deian> tanvy: how do we know what the HTTPS version of the site is
20:25:49 <wseltzer> s/tanvy/tanvi/
20:25:56 <deian> mkwst: intead of blocking an HTTP link to a script preference, you would attempt to load it over HTTP. if it loads, then you're good, but if it blocks it would've blocked anyway
20:26:59 <deian> bhill2_: the concerned came from W3C pages. Can't find all the absolute links. If we're talking about removing breakages from moving to HTTPS, can we make this easier
20:27:38 <deian> tanvi: I'm fine with doing this, but in the past we've gotten feedback that you can't just assume that the HTTPS is the semantic equivalent
20:28:07 <deian> mkwst: HTTPS everywhere extensions has more complicated ruleset - there are cases where  HTTPS is on different origin
20:28:56 <deian> dveditz: we need to think about how this interacts with redirects. E.g. case is forbes where HTTPS redirects. Yet not following redirects can break
20:29:20 <deian> bhill2_: anybody in group have bigger dataset that we can use to look into this further
20:29:29 <deian> mkwst: will ask
20:30:09 <bhill2_> TOPIC: Accessible content security indicators
20:30:40 <deian> bhill2_: didn't link to this. need indication if we're going to switch from SHOULD to MUST
20:31:01 <deian> mkwst: in blink we can add a layout pass
20:31:18 <deian> mkwst: not sure how we would write a W3C spec
20:31:22 <deian> dveditz: same for mozilla
20:31:32 <deian> dveditz: chrome can get at data, but its not web visible
20:32:00 <deian> bhill2_: there are other browsers that don't have accesibility features (e.g., mobile). they should, but don't always
20:32:06 <Zakim> + +1.415.736.aaff
20:32:15 <deian> dveditz: will look into getting more info fom accessibilty people
20:32:21 <jww> jww has joined #webappsec
20:32:34 <deian> mkwst: there are some suggestion on how to do it in chromium
20:32:37 <wseltzer> zakim, aaff is jww
20:32:37 <Zakim> +jww; got it
20:33:08 <bhill2_> TOPIC: CSP whitelisting and geotargeting of domains
20:33:14 <bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0108.html
20:33:41 <deian> bhill2_: there is concern that there are sites that are trying to apply CSP, but oftentimes users get redirected according to geolocation to entirely different TLDs and this tends to break CSP
20:33:56 <deian> dveditz: problem for anyone except google and amazon?
20:34:13 <deian> have seen it on CNN
20:34:56 <deian> mkwest: I think we will need to find a workaround for this
20:35:23 <deian> ...hard to hear mkwest.. dveditz: this is not safe
20:35:42 <bhill2_> TOPIC: CSP 'self' in sandboxed contexts
20:35:50 <deian> bhill2_: need to workound this and continue discussion on list
20:35:52 <bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0104.html
20:36:56 <deian> jww: introduction of another origin concept seems qustionable. had same concern
20:37:19 <deian> dveditz: fallback case URL seems like its trying to get at the same value we're trying to use in practice for 'self'
20:37:38 <deian> mkwst: do we respect document.domain in this case? if we do why?
20:37:45 <deian> dveditz: its evil, ignore where possible
20:37:53 <deian> dveditz: we don't use origins for base fallback
20:38:08 <deian> dveditz: we do in some cases, like about:blank, but not sandbox frames
20:38:23 <deian> dveditz: in sadbox the origin differes, concepts introduced for this purpose
20:38:43 <deian> dveditz: sandbox is under-specified in terms of effictive origin
20:39:22 <deian> jww: we introduced a fundamental incompatability. two mechanisms that break eachother.
20:39:57 <deian> mkwst: if I don't know if I'm going to be sandboxed the sandbox is likely to break my page regardless
20:40:14 <deian> jww: if we get to the world where CSP is used everywhere then sandboxed everything will be broken
20:40:34 <deian> mkwst: if I do know if I wil sandboxed, I will design it so that it doesn't break
20:40:47 <deian> mkwst: intuition is that I'm more likely to sandbox my own code vs. third-party
20:41:27 <Zakim> -freddyb
20:41:28 <deian> bhill2_: self is a single token that is useful for a simple site policy. makes it a lot harder to apply CSP if we expand (?)
20:41:51 <deian> bhill2_: no consensus on this, bring it back to list
20:41:53 <freddyb> uh
20:42:05 <Zakim> +??P2
20:42:11 <freddyb> Zakim, ??P2 is me
20:42:11 <Zakim> +freddyb; got it
20:42:20 <deian> *painful noises*
20:42:35 <bhill2_> TOPIC: Remove the anchor element from v1 of SRI?
20:42:43 <bhill2_> https://github.com/w3c/webappsec/pull/143#issuecomment-69484590
20:42:54 <deian> bhill2_: discusses mostly as github issue
20:43:05 <deian> bhill2_: did not reach a definitive conclusion at TPAC
20:43:34 <deian> bhill2_: we thought that some of the most useful cases are download sides that point to HTTPS resources from HTTP sites
20:43:56 <deian> freddyb: my take it just remove it for v1
20:44:08 <deian> jww: there were some corner cases, seems like great thing to work for v2
20:44:26 <bhill2_> TOPIC: Set default media types for SRI?
20:44:33 <bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0099.html
20:44:35 <deian> bhill2_: won't make it to CR is neither Chome nor FF do it, let's punt to v2
20:45:11 <francois> q+
20:45:14 <deian> bhill2_: mkwst and jww didn't think that this was a great idea. anyone think that this is a good idea?
20:45:18 <bhill2_> ack francois
20:45:38 <deian> francois: I think that the comments were good, no longer think that it's a great idea.
20:45:43 <deian> bhill2_: ok, giving it up then
20:45:46 <bhill2_> TOPIC: Glenn Adams's bugs in Bugzilla. Move to Github?
20:45:59 <bhill2_> https://www.w3.org/Bugs/Public/buglist.cgi?component=Subresource%20Integrity&product=WebAppsSec&resolution
20:46:30 <deian> propose to just move them
20:46:40 <bhill2_> ACTION bhill2 to move SRI bugs in bugzilla to github
20:46:40 <trackbot> Created ACTION-210 - Move sri bugs in bugzilla to github [on Brad Hill - due 2015-01-19].
20:46:52 <bhill2_> TOPIC: Unsupported hashes / hash agility
20:46:59 <bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0014.html
20:47:21 <deian> bhill2_: how to deal with unsupported hashes and hash agility. two cases: metadata okay, but algorithm not trusted
20:47:32 <deian> other case is where old browser hasn't seen this
20:48:03 <deian> bhill2_: state on list: no resolution/consensus. do editors have prefered appraoch.
20:48:08 <deian> francois: no conclusion yet
20:48:19 <deian> or was that freddyb ?
20:48:22 <freddyb> that was me-^  :)
20:48:26 <deian> sorry :)
20:48:28 <freddyb> np
20:48:46 <deian> dveditz: this somewhat discourages adoption.
20:48:56 <deian> mkwst: no one is thinking about agility
20:49:10 <deian> mkwst: why does it discourage adoption?
20:49:19 <freddyb> .. mkwst earlier said he'd prefer fail-close because its easier
20:49:44 <deian> dveditz: because sites will break in middle-old browsers if we invent a new hash later and people start using it
20:50:15 <deian> dveditz: right now we have distinction between browsers that do not support it at all and those that do. the former will ignore, the latter will check hashes
20:50:58 <deian> mkwst: if you are using the integrity attribute then you are expressing intent about integrity of resource. if broser cannot check, it should not load the resource
20:51:17 <deian> mkwst: I think developers should use multiple hashs
20:51:40 <deian> ... missed a few things, sorry still hard to hear mkwst...
20:52:12 <mkwst> deian: sorry. :(
20:52:35 <deian> dveditz: don't trust the security of this so much that I care if it fail-open
20:52:40 <deian> mkwst: if it fails-open what's the point?
20:54:00 <deian> jww: difference between developer bug (choosing insecure hash) vs. failing to load resource should be distinguished
20:54:10 <wseltzer> they chose an insecure hash, so the property they thought was guaranteed isn't
20:55:10 <deian> bhill2_: likelyhood of finding exploits due to collision is small. even if security of sha256 is weakened by 1/2, we're still providing somewhat meaningful security
20:55:24 <francois> to help determine whether or not it will impact adoption, should we ask github (as a very early adopter of sri) what they think about failing open v. closed?
20:55:54 <wseltzer> +1 to failing closed
20:55:56 <deian> bhill2_: agreed, take this as action. people with strong opinions will prefer failing closed
20:56:02 <francois> q+
20:56:11 <deian> dveditz: failing closed is fine
20:56:19 <deian> ack francois
20:56:29 <bhill2_> ACTION bhill2 to ask GitHub if they prefer fail open / closed on unknown hashes
20:56:29 <trackbot> Created ACTION-211 - Ask github if they prefer fail open / closed on unknown hashes [on Brad Hill - due 2015-01-19].
20:56:38 <deian> francois: fine with failing closed but not if it impacts adoption significantly.
20:57:07 <deian> dveditz: the one nice thing about failing closed: if one typos sha256 and things fail-close, they'll fix it.
20:57:31 <deian> since they find out right away vs. fail-open
20:57:31 <francois> good point, that's much more reliable than relying on devtools warnings
20:57:36 <freddyb> fair point.
20:58:06 <deian> jww: if two UAs come to diff conclusion of security of different hash functions
20:58:18 <deian> jww: you might not know that it breaks on different UA
20:58:26 <deian> jww: (in favor of fail-open)
20:58:37 <deian> dveditz: you need to test on mulple UAs anyway
20:58:42 <tanvi> or maybe we should try and coordinate deprecation of hash algorithms
20:58:45 <tanvi> to avoid that issue
20:58:49 <deian> tanvi: yep :)
20:58:57 <freddyb> UA-1 allows only hash-1 and UA-2 allows only hash-2, you can still list both since they are combined with a logical OR, right?
20:59:28 <freddyb> tanvi: we can happily assign this to the "naming things with hashing" RFC ;-P
21:00:12 <tanvi> what's going on on the 26th?
21:00:14 <Zakim> -[Microsoft]
21:00:29 <freddyb> tanvi: owasp appsec cali
21:00:30 <deian> webappsec california, may propose meeting at least for drinks
21:00:36 <wseltzer> https://2015.appseccalifornia.org/ ?
21:00:44 <Zakim> -[Mozilla]
21:00:48 <Zakim> -Wendy
21:00:49 <tanvi> thanks
21:00:49 <Zakim> -jww
21:00:49 <Zakim> -freddyb
21:00:50 <bhill2_> rrsagent, make minutes
21:00:50 <RRSAgent> I have made the request to generate http://www.w3.org/2015/01/12-webappsec-minutes.html bhill2_
21:00:50 <Zakim> -mkwst
21:00:55 <Zakim> -tanvi
21:00:55 <bhill2_> rrsagent, set logs public-visible
21:00:58 <Zakim> -deian
21:00:59 <Zakim> -francois
21:01:00 <dveditz> wseltzer: yes
21:01:07 <Zakim> -bhill2_
21:01:08 <Zakim> -gmaone
21:01:13 <Zakim> -terri
21:01:15 <Zakim> SEC_WASWG()3:00PM has ended
21:01:15 <Zakim> Attendees were mkwst, freddyb, Wendy, +1.206.348.aaaa, +1.418.907.aabb, bhill2_, francois, gmaone, +1.646.355.aacc, deian, +1.310.597.aadd, dveditz, tanvi, +1.408.463.aaee, David,
21:01:15 <Zakim> ... Walp, terri, +1.415.736.aaff, jww
21:02:52 <bhill2> bhill2 has joined #webappsec
21:03:16 <bhill2> rrsagent, make minutes
21:03:16 <RRSAgent> I have made the request to generate http://www.w3.org/2015/01/12-webappsec-minutes.html bhill2
21:52:10 <deian> deian has joined #webappsec