23:36:26 RRSAgent has joined #webappsec 23:36:26 logging to http://www.w3.org/2015/10/28-webappsec-irc 23:36:36 rrsagent, this meeting spans midnight 23:36:44 trackbot, start meeting 23:36:46 RRSAgent, make logs world 23:36:48 Zakim, this will be WASWG 23:36:49 I do not see a conference matching that name scheduled within the next hour, trackbot 23:36:49 Meeting: Web Application Security Working Group Teleconference 23:36:50 Date: 28 October 2015 23:37:48 Meeting: Web Application Security Working Group F2F, Day 1 (TPAC) 23:40:56 Agenda: https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit?usp=sharing 23:41:16 wseltzer has changed the topic to: TPAC Meetings, Oct 28, 29. https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit?usp=sharing 23:42:15 colin has joined #webappsec 23:46:39 bhill2 has joined #webappsec 23:50:42 SIN_ has joined #webappsec 23:51:50 kiyoung has joined #webappsec 23:52:48 francois has joined #webappsec 23:53:14 bhill2 has joined #webappsec 23:57:09 twhalen has joined #webappsec 23:59:08 cscho has joined #webappsec 00:00:26 ygkim has joined #webappsec 00:03:24 Meeting: WebAppSec F2F, TPAC 2015, 29-Oct-2015 00:03:30 Chairs: bhill, dveditz 00:03:35 deiu has joined #webappsec 00:03:38 Agenda: https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit# 00:03:43 present+ deiu 00:03:49 Min has joined #webappsec 00:04:18 keiji has joined #webappsec 00:04:23 present+ francois 00:04:36 Kepeng has joined #webappsec 00:04:37 present+ wseltzer 00:04:37 ccho4 has joined #webappsec 00:04:43 present+ bhill 00:04:48 present+ keiji 00:04:53 present+ dveditz 00:04:58 present+ twhalen 00:05:02 present+ Kepeng 00:05:04 rbarnes has joined #webappsec 00:05:05 present+ mek 00:05:08 present+ 00:05:14 present+ 00:05:20 Kazue has joined #webappsec 00:05:35 kodonog has joined #webappsec 00:05:56 present+ rbarnes, colin 00:08:54 present+ cscho4 00:09:10 jyasskin has joined #webappsec 00:09:14 https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit# 00:09:15 agenda link: https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit# 00:09:17 present+ jyasskin 00:09:59 JeffH has joined #webappsec 00:10:58 scribe: JeffH 00:11:02 present+ mkwst 00:11:05 TOPIC: minutes approval 00:11:08 present+ cscho 00:11:32 http://www.w3.org/2011/webappsec/draft-minutes/2015-10-19-webappsec-minutes.html 00:11:40 minutes unanimously approved 00:12:23 present+ JeffH 00:12:50 WebAppSec WG Update preso by bhill2 00:12:57 npdoty has joined #webappsec 00:13:13 rrsagent, pointer? 00:13:13 See http://www.w3.org/2015/10/28-webappsec-irc#T00-13-13 00:13:32 present+ npdoty 00:13:43 agenda: https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit 00:14:12 https://www.irccloud.com/pastebin/YTSsB2Vl/ 00:14:27 Can we add it to the secure context agenda? 00:15:15 link to preso? 00:15:28 https://www.w3.org/2015/10/TPAC/slides/WebAppSec-TPAC2015-Update.pptx 00:15:33 ^Brad's slides 00:16:15 thx 00:16:49 on Broad Themes slide #3 00:20:07 S #6 subresource integrity SRI 00:20:22 s 7: Referrer Policy -- fpwd 00:20:42 s 9: upgrade insecure requests 00:20:55 s 10: UI Security 00:22:13 s 11: Cred mgmt 00:22:41 q+ 00:22:43 bhill2: questions? 00:24:10 ?: asks about diff btwn "creds mgmt" spec and the work in "creds CG" 00:24:54 bhill2: the latter is about "creds" like driver licenses, not username/pswds which is what creds mgmt spec is about 00:25:56 present +kodonog 00:25:59 mikwest: creds mgmt api is extensible and we are working to take into account the creds CG's use cases 00:27:21 https://www.w3.org/2015/10/TPAC/slides/WebAppSec-TPAC2015-Update.pptx (world-readable link, per bhill) 00:28:34 q+ to ask about clear-site-data or private browsing 00:29:34 mkwst: have secveral specs trying to give websites better functionality to ease migtation to https, eg upgrade insecure requests 00:29:39 ack Kepeng 00:29:42 ack npdoty 00:29:42 npdoty, you wanted to ask about clear-site-data or private browsing 00:29:59 npdoty: curious about clear-site-data 00:30:12 http://w3c.github.io/webappsec-clear-site-data/ 00:30:41 mkwst: there is a spec, have someone impl'g this qtr, will have impl early nxt yr. spec has been stable. 00:30:53 q+ to ask about error codes (API) when mixed content load errors are triggered 00:31:26 mkwst: some discussion re private browsing mode -- eg webapp policy to only be loaded in incognito mode -- need to restart that discussion 00:31:33 sangrae has joined #webappsec 00:32:24 ?: wrt private browsing mode aka icognito, went to women's shelter for use case, they didn't think would make sense to require all users of their webapp to use incognito mode 00:33:19 ?: they are thinking that having some sort of way for user to "clear all website data" for given site/webapp is better way to go -- mkwst: please chat with Tara et al 00:33:37 q+ 00:34:08 ack deiu 00:34:08 deiu, you wanted to ask about error codes (API) when mixed content load errors are triggered 00:34:11 bhill2: webapp is authoritative for its data, but users' browsing history the user is authoratative for it, so would require some sort of user interaction 00:35:09 s/?: wrt/francois: wrt/ 00:35:17 andre: is there any kind of api or way to get to the error when a mixed content req fails -- i as dvlpr don't get the info easily, but especially annoying for users, and no 00:35:39 easy way for the webapp devlpr to display meaning ful into to user 00:36:02 kiyoung has joined #webappsec 00:36:38 yoav has joined #webappsec 00:37:04 mkwst: there's ways to do that now eg leveraging CSP, TimBL was asking last night about a diff status code that comes back on XHR -- but there's limits such as if it is a redirect can't give the webapp access to the target of the redirct -- doing some thing like a status code or firing a mixedcontent event, pls file bug on the spec and make suggestions 00:37:38 dveditz: folks often don't have onError on everything... 00:37:58 mkwst: there's a variety of ways to give dvlprs the info they desire/need 00:38:21 rbarnes: leery of giving folks "timing" apis for priv concerns 00:38:46 mkwst: if u have specific concerns pls talk to web perf folks (they ahve timing apis...) 00:39:15 rbarnes: just want to make sure that if we add anything we do it carefully 00:39:22 I think francois's point was that a more valuable mechanism would be clearing recent history for all sites (so as to remove the search engine results page before you clicked on the particular site, for example) as opposed to private browsing mode for that whole origin, so it would be more like a prompt for browser ui for clearing local history 00:39:41 wonsuk has joined #webappsec 00:39:51 q+ 00:40:21 bhill2: look at what info you get from CSP "default-src: https" -- think about the developer senario cuz it is diff w/XHR. 00:40:39 ack Kepeng 00:40:52 dveditz: hmm might be other ways to do it...mkwest: pls file bug 00:41:11 ack keiji 00:41:14 s/andre/andrei 00:41:53 keiji: saw something about fido mentioned -- new web authn wg proposed -- what rel will have with cred mgmt api ? 00:42:52 dveditz: cred mgmt api here is extensible and hopefully the web authn wg can use it as basis for its work 00:44:17 mkwest: we want to think about creds sourced by say oauth, and perhaps that gives the creds CG what they need because they are somewhat similar 00:45:01 bihill2: we can discuss this later today 00:45:11 TOPIC: Subresource Integrity 00:45:35 ?: pretty much ready to go to CR, have some minor issues to address 00:46:00 need to do a bit more work on test harness 00:46:08 bhill2: we can go to CR with what we have 00:46:36 dveditz: issues are spread across 2 diff repos, we need to move issues? 00:46:50 ?: pref would be to move issues 00:47:38 https://github.com/w3c/webappsec/issues/486 00:47:47 dveditz: issues of note 00:47:49 https://github.com/w3c/webappsec/issues/363 00:48:04 https://github.com/w3c/webappsec-subresource-integrity/issues/3 00:48:15 https://github.com/w3c/webappsec-subresource-integrity/issues/12 00:48:25 ?: #486 - planning to do that one, but is in a diff spec so not blocking us 00:49:29 francois: #363: needs more discussion -- bhill had good response to consider 00:50:28 bhill2: devdatta has been asking questions about this also -- do we need to add explainer text for the current specs SRI and CSP? 00:50:51 q+ 00:50:55 bhill2: goals and thread models explained well in each sep spec -- not sure is worth it 00:51:46 ack npdoty 00:52:00 mkwst: would be useful to ahve a general explainer doc on how to use the suite of webappsec specs to construct a secure site -- -take this in consideration in CSP3 -- don't want to add to CSP2 which is almost done 00:52:18 ccho4 has joined #webappsec 00:52:32 keiji has joined #webappsec 00:52:35 ndoty: would be valuable to do overall explanation -- webplatform.org might be place to do some of this 00:52:44 https://www.webplatform.org/ 00:53:29 npdoty: +1 to the goal, doesn't and shouldn't be in the specification which has a very different audience 00:53:50 bhill2: better dvlpr doc would be a good thing, but getting folks signed up to do this work difficult, but thinks we can close this #363 in terms of its relation to SRI and CSP2 00:54:14 bhill2: 00:55:11 bblfish has joined #webappsec 00:55:21 dveditz: the other issue is secretarial -- so will send the transition message for SRI next week 00:56:12 TOPIC: CSP 2 to REC status 00:56:23 bhill2: have an impl rpt for CSP2 00:56:28 https://w3c.github.io/webappsec/implementation_reports/CSP2_implementation_report.html 00:56:33 thx 00:56:47 see above 00:57:30 cscho has joined #webappsec 00:57:48 bhill2: have 3 or 4 hundred tests for CSP2 but not everything is covered yet, so could use help in writing test cases 00:58:14 see report linked above to see ones that need to be added 00:59:30 overall status on CSP2 tests in chrome and FF -- see rpt above -- both browsers have CSP2 aspects still to implement 01:00:09 bhill2: would prefer to go to Prop Rec having solid impls and test suite coverage 01:00:19 francois: we will try to do that with SRI also 01:00:25 rrsagent, generate minutes 01:00:25 I have made the request to generate http://www.w3.org/2015/10/28-webappsec-minutes.html cscho 01:02:00 bhil2: to go to rec need all normative refs at same matiurity level -- there's ways to finess this -- but really want to have assurance of solid normative text when going to PR thus need test suite and impls to be solid 01:02:26 ivan__ has joined #webappsec 01:02:37 q? 01:02:52 BREAK TIME till 1030h local time 01:03:02 wonsuk has joined #webappsec 01:08:03 wonsuk has joined #webappsec 01:09:29 npdoty has joined #webappsec 01:12:54 keiji has joined #webappsec 01:18:29 keiji has joined #webappsec 01:23:35 gao has joined #webappsec 01:24:31 yoav has joined #webappsec 01:28:49 yoav has joined #webappsec 01:28:55 SIN_ has joined #webappsec 01:29:38 barryleiba has joined #webappsec 01:30:47 npdoty has joined #webappsec 01:31:10 SIN has joined #webappsec 01:33:00 rbarnes has joined #webappsec 01:33:53 kiyoung has joined #webappsec 01:34:05 scribe: dveditz 01:34:15 Present+ yoav 01:34:18 kodonog has joined #webappsec 01:34:25 TOPIC: Secure Contexts 01:35:08 bhill2: our calls have moved from "covering recent topics" to a rotation featuring a group of specs each meeting, rotating through the many specs we have over several weeks 01:35:35 present+ Barry Leiba 01:35:37 mkwst: "Secure Contexts" is pretty close to done, a couple of topics worth discussing 01:35:43 present+ Jungkee_Song 01:35:48 http://w3c.github.io/webappsec-secure-contexts/ 01:36:13 ... a "Secure Context" needs to be delivered securely, e.g. over TLS (with some exceptions such as local file:///, loopbacks etc are considered secure) 01:36:35 ... diagrams showing how different contexts work with each other 01:37:37 ... we saw some "abuse" where inner secure frames fed data back to insecure frames 01:38:09 ... Example 2 (in spec): is a TLS popup from an insecure page a secure context? 01:38:25 annevk has joined #webappsec 01:38:33 ... yes, seems only tangentially related. we see this in the case of navigations for example. 01:38:44 Kepeng has joined #webappsec 01:39:01 ... would be strange to consider a secure page as not a secure context because it came from an insecure page. 01:39:18 ... however, there's a chance for leakage 01:39:41 ... also one could have a handle (window.open/ opener) and can postMessage() each other 01:39:52 Melinda has joined #webappsec 01:40:04 kazue has joined #webappsec 01:40:20 ... there can be complicated situations. Talked a little with Travis from microsoft. he's concerned with this use-case 01:40:32 ygkim has joined #webappsec 01:40:37 ... we might want to consider a popup as a tainted context 01:41:10 rbarnes: we might want to do what we do with workers, just break the connection. Don't let the insecure context have a handle to the secure one 01:41:59 mkwst: we have a referrer relation. the page can say "rel=noreferrer" and if we do that there's no leakage. We can consider it secure in that case 01:42:39 ... I've opened an issue with annevk to create a rel=noopener because sometimes you _do_ want the referrer and really were just using it for the noopener side-effect 01:43:11 annevk: That's what makes it auxiliary, and if you break that then it's no longer an auxiliary context. No tainting 01:43:26 ... are we limiting broadcast channel? 01:43:41 mkwst: there's still a variety of side-channels (message events, etc) 01:44:23 ... trying to make it more difficult to do the kind of shim Netflix has done. I don't think they would use a popup in this way 01:44:45 ... what Travis didn't like was that this would be difficult to implement in edge 01:45:19 ... he would like it so that if two things are same origin they have to have the same security context 01:45:57 Present+ annevk 01:46:14 q+ jyasskin document.domain? 01:46:25 ... we remove window.opener. can null out window returned from window.open(). can still get a handle by naming it and then window.open() to the same name. once you have a reference there's a variety of ways to communicate 01:46:51 ... I don't think Chrome has iplemented broadcastMessage() like Firefox, but even without that there are storage change events and others 01:47:12 q? 01:47:17 yoav: why would localStorage be hard? couldn't they pass the data by stuffing the answers in localStorage? 01:47:25 what is the threat that we're trying to prevent against? a network attacker modifies an HTTP page, and opens an HTTPS page, and the HTTPS page collaborates with the network attacker? 01:47:36 rbarnes: because they'd have to do so from a popup and we think they wouldn't want the annoyance of a popup 01:47:41 ack jyasskin 01:47:44 ack 01:47:48 ack document.domain? 01:47:48 q- document.domain? 01:48:01 jyasskin: do you want to bring up the document.domain question? Do you want to block access from a secure context? 01:48:27 mkwst: yeah, I'd be happy to do that. we already restrict a number of things from secure contexts in chrome 01:49:11 q+ to understand the threat of the network attacker 01:49:11 annevk: but secure contexts are not opt in, how would you do that without breaking old sites? 01:49:35 q+ 01:49:50 mkwst: I'd do it the other way, touching document.domain turns off the secure context, possibly breaking access to objects the context already has references to 01:50:29 annevk: or if you do something that requires a secure context (e.g register a service worker) then it turns off document.domain 01:51:17 mkwst: question came up wrt service workers, should things that are not usable securely be invisible, or should they throw? 01:51:22 ack npdoty 01:51:22 npdoty, you wanted to understand the threat of the network attacker 01:51:32 s/annevk:/jyasskin/ 01:51:40 npdoty: I'm trying to understand the threat model here in the embedded iframe 01:53:10 ... if something is delivered over http with a link to https, that's a secure context. It may not be the one intended by the original author, but it's still secure 01:53:34 ... users can't see the origin of a frame, but they can in the case of a popup 01:53:35 ack bhill 01:54:02 bhill2: I see the threat model here as asking for permission, if the user sees one thing in the urlbar and the iframe is a different origin 01:54:25 ... everywhere else the context is authoritative for its origin, it's allowed to leak data if it wants to 01:55:27 npdoty has joined #webappsec 01:55:59 rbarnes: if we say feature X is only available to secure contexts then an attacker can frame a secure page and use postMessage to get access to that feature 01:56:26 npdoty: are you worried that the framed site is collaborating with the attacker? you can always collaborate 01:56:44 mkwst: it may not be intentional collaboration, it's just a feature that was found and used in that way 01:57:15 bhill2: we're still not enforcing confinement here. we're stopping an obvious and convenient bypass but there are still other ways available 01:57:24 mkwst: I agree, it's not complete isolation 01:58:12 ... I don't think it's necessary. It would be wonderful to do that and I'd like to but not sure we can. this seems reasonable to not break things on the web too much while giving developers tools to do their jobs 01:58:30 ... popups get in the user's face, less likely that it would be abused. 01:58:44 ... what owuld you like to see in the doc (or anywhere) to make that a reasonable claim to make 01:58:54 I think the unintentional collaboration point is important; if we think it's likely to create a danger where a site will typically make it easy for network attackers to access, that makes sense 01:58:59 +1 "attractive nuisance" 01:59:04 bhill2: sounds like there's not a particular threat model, we're closing down an attractive nuisance 01:59:21 mkwst: we're closing down a practical way to abuse this we've seen in the wild 02:00:00 q? 02:00:09 jyasskin: if someone can find an iframe that can do what they need then they've won, while with a popup they can't 02:00:25 ... but if the popup is invisible then they still win 02:00:53 mkwst: chrome has put a lot of work into stopping popunders and other invisible popups. We dont think there should be invisible popups 02:01:00 ... and if there are any it's a bug 02:01:37 ... forcing https is less a concern than making sure particular APIs are not available to things that were delivered insecurely 02:02:17 bhill2: we should touch on this again in the context of COWL tomorrow 02:02:40 ... can we define this as a kind of restriction? keep this in mind for tomorrow 02:03:10 mkwst: doc has a section on threat modesl and risks. look it through and see if you can make it better 02:03:32 npdoty: while we're on that note... should we consider other threat models or say explicitly we're not considering one. 02:04:14 ... part of whta we're doing with a network attacker model is that if users are ask for a permission they can be reasonably sure which origin is requesting it. 02:04:26 rrsagent, generate minutes 02:04:26 I have made the request to generate http://www.w3.org/2015/10/28-webappsec-minutes.html cscho 02:04:47 ... but there hasn't been a lot of adoption of CSP, so it's either the obvious origin or it's someone who found an XSS bug in that origin 02:05:07 rbarnes: or any 3rd party legitimately included by the origin 02:05:36 bhill2: if you have a correct application this helps prevent exploitation; if you have an incorrect application well.... 02:06:19 npdoty: discussed this week -- the presence of a CSP that denies inline script is indicator of secure context. 02:06:30 mkwst: but an attacker can inject that CSP after doing its attack 02:07:04 npdoty: it might be valuable to include a clause saying there are other kinds of attacks and that this is not a complete silver bullet 02:07:46 bhill2: we can't make the claim "this app cannot be exploited" 02:08:02 pauljeong__ has joined #webappsec 02:08:06 ... not sure it provides much to make the opposite assertion 02:08:37 SIN has joined #webappsec 02:09:02 dveditz: if we assume invisible / popunder windows are impossible, should we specify somewhere that this should not happen? 02:09:33 mkwst: joachim is working on this and I would love for him to better specify this, e.g. how user gestures are tracked and consumed in chrome 02:09:45 ... would be good to document, but practically speaking we haven't had time, there are many and it is difficult 02:09:55 ... send joachim an email and ask 02:10:07 s/joachim/jochen/ 02:10:20 dveditz: would that be something that would be in this group or in HTML? 02:10:41 mkwst: there is some term in html that has a couple of points but is fairly sparsely defined. expanding on it to be useful for this would be some work 02:10:48 q? 02:11:36 mkwst: there's a couple more things that I've worked with annevk on, such as what flags to add to fetch and so on 02:11:49 https://github.com/w3c/webappsec-secure-contexts/issues/5 02:11:59 ... issue number 5: boris seemed to agree (in a long comment) "but you need a lot of tests" 02:12:26 ... we need to figure out how to advance the spec even though it concerns things that are not in the version o HTML defined by the w3c 02:13:12 ... I asked web-apps and they pointed at an HTML 5.1 doc that contains a bunch of things, I'm not convinced that's any more stable and I'd prefer continuing to reference the WHATWG specification. 02:13:30 q+ 02:14:12 wseltzer: I should speak up on the normative reference policy -- it is something we'll ahve to address in the w3c generally 02:14:53 ... as more things are produced referencing more outside things. we are not saying everything has to be done in w3c so lets find a way to describe when 02:15:21 ... things developed elsewhere are sufficiently stable and develped sufficiently openly to serve as a reference. 02:15:32 q- 02:15:40 ... maybe we can chase down some directors while we're here 02:16:06 mkwst: there are some things still open at this point but they are details. the general structure and outline seems complete 02:16:36 ... the TAG was happy with it last time they looked, @@ was happy with it. matter of weeks not months to wrap it up 02:17:25 mkwst: dveditz filed a bug on the relation between mixed content and secure contexts 02:17:40 virginie has joined #webappsec 02:18:00 TOPIC: Mixed Content 02:18:01 http://w3c.github.io/webappsec-mixed-content/ 02:18:07 ... mixed content defines how content can be loaded into a page delivered over TLS 02:18:25 ... secure context defines when content can be loaded into a secure context 02:18:59 ... MIX used to talk about "potential secure origins" -- I've changed it to URLs and authenticated 02:19:55 ... in MIX we can tell by the URL form itself. "unauthenticated" response is something we can tell based ont he actual response (deprecated security, or none) 02:20:36 ... a question to dveditz: have you had a chance to review the changes to the document 02:21:06 dveditz: have not had a chance to do more than skim what you said but it seems you made the distinction so the terms are no longer confusingly similar 02:21:20 ... I raised this in behalf of others at mozilla, have to make sure this addresses their concerns as well 02:21:41 mkwst: the reason there is a distinction is that the secure context spec is not only concerned with TLS but also accepts things like file, localhost, 127.0.0.1, etc. 02:21:43 mkwst: the reason there's a distinction is that secure context is concerned with not only TLS but things like file:// or loopback 02:22:12 ... and we need to define the behaviors for those that are different from those for mixed content blocking 02:22:33 ... other than that I think the mixed content is done. maybe we have to go back to CR because I changed the definition 02:22:54 ... I don't think they are substantive changes, but mayne someone else will. can we slip this by the director? 02:23:22 ... the other issue is whether we want some kind of error reporting based on mixed content (raised in the session yesterday) 02:24:10 ... now that annevk is here: TBL and others said it would be nice to know when failures were due to mixed content blocking as opposed to other kinds of network errors. what's your opinion on that? 02:24:16 annevk: is it actually a good idea? 02:24:51 mkwst: I think it's reasonable to give developers some idea when things are broken because of something they're doing wrong so they can fix it 02:25:35 annevk: historically we avoid saying much when we block things for security reasons. so mixed content in an iframe -- would we show a different error page? 02:26:16 mkwst: if it's stuff outside your context then no, but if it's stuff loaded in your own context and it fails it would help to know about it 02:26:25 mkwst: xhr, fetch, javascript 02:26:43 annevk: I think we've gotten by without this for a long time 02:27:17 mkwst: in the recent past we've gotten more strict about mixed content blocking (like xhr). we'd like more people to migrate and giving them better errors might help 02:27:30 annevk: I'm still not convinced 02:27:57 mkwst: things that redirect are a problematic case -- you can't just tell by inspecting your own origin 02:28:13 annevk: if it's just tim I'm still not convinced. it's added complexity. 02:28:38 bhill2: what does this give us that csp errors don't? are we going to respond right there, or is it for debugging later? 02:28:52 ... if it's debugging then reporting seems good enough 02:29:00 annevk: does CSP report on this? 02:29:15 mkwst: if you set up your CSP to block mixed content then yes 02:30:00 ... tim's concern was associated with doing an xhr, having it fail, and wanting to do something else whether it's an offline failure vs mixed content. 02:30:16 rbarnes: I'm baffled, what would you do differently? 02:30:36 mkwst: I'm giving you all the information I know about the use case 02:30:39 pleased for my bafflement to be immortalized in the minutes 02:30:44 wseltzer: maybe it's a jog for the TAG 02:30:52 s/jog/job/ 02:30:53 mnot: I have to be somewhere.... 02:31:19 annevk: if it's just the offline thing you can check navigator.online 02:31:41 bhill2: we can have a rule, we have to have two independent requests for a feature 02:31:48 navigator.onLine 02:32:05 mkwst: if we can show other ways to do it I think that's sufficient 02:32:43 wseltzer: in all seriousness it could be helpful for the TAG to describe how things could be done securely using new features the director might not know about 02:33:05 npdoty: if we had better docs on webplatform.org then _any_ developer could find out 02:34:45 mkwst: brief context Yan broke the internet, you can do timing attacks using CSP and HSTS. 02:35:19 I hadn't realized the Firefox behavior was intentional, that's good to know 02:35:26 https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0095.html 02:35:26 (FWIW, CORS preflights are cached too) 02:35:32 rbarnes: new topic "hsts priming", priming the state like cache priming. 02:36:31 ... because browsers learn about HSTS through headers behavior depends on whether a browser had already visited that domain or not 02:37:13 ... proposal: if you have a non-https request that would be blocked by mixed content, but which HSTS would fix, then do a lookup (innocuous) to see if the site has HSTS. 02:37:33 ... either the site doesn't and the request gets blocked anyway, or it does and you can safely upgrade it 02:38:47 yoav: is the mixed content request going out, or blocking the response coming back in? 02:39:03 ... if it's images you still send the insecure request and then degrade the state 02:39:41 mkwst: how does mixed content deal with redirects? Is an fetched as http: that redirects to https: still mixed content? 02:39:55 annevk: Yes. 02:40:25 annevk: Because the redirect is non-confidential, and can't guarantee integrity. 02:40:32 mkwst: and https: to http: still renders? 02:41:34 annevk: images render. they simply flag the page as being insecure. 02:41:47 annevk: in both cases you describe, the result would be mixed content. 02:42:08 rbarnes: you can cache "no HSTS" for a shorter time, such as the lifetime of the document 02:42:42 ... we do need to change the order of fetch because mixed content blocking happens before the HSTS upgrade happens 02:43:30 mkwst: is this worth doing? what I heard from you was that this affects 1% of all potentially blocked mixed content in Firefox. 02:43:45 ... at what level is it worth doing the work 02:44:07 SIN has joined #webappsec 02:44:13 mnot: not sure that's the right metric. if this helps people switch to https then it's a good thing 02:44:59 I think mnot is saying that it could be a larger percentage, when you consider sites that haven't upgraded to https *because* they saw mixed content failures, but would 02:45:54 rbarnes: the stuff that would be fixed is 0.02% of request, so it's small, but for future sites converting this would help 02:46:29 dveditz: there are two issues: changing the order of rewriting/blocking would help a lot of people 02:46:44 mkwst: but we need to do this priming to be able to do this or we have non-deterministic behavior 02:47:00 mkwst: we need to do priming before switching order to remove indeterminism. 02:47:10 ... and developers will have visited all of the sites they depend on so things will appear to work, but will be broken for users on first visit 02:47:24 ... devs will have visited all the sites, so the page will work for them. users will have a broken site because they will have blocked content 02:48:03 bhill2: where would this live, a modification to fetch? 02:48:21 annevk: we could do it that way. we have a secrion on preflights, we could have a section on this 02:49:13 JeffH: I would expect the priming to be added to the IETF rfc XXXX because if you do this that spec is no longer stand-alone 02:50:24 bblfish has joined #webappsec 02:50:30 mkwst: as far as I know no browser implements 12.4 "Disallow Mixed Security Context Loads" in the hsts spec 02:51:35 ... fetch spec doesn't define how pinning is going to work 02:51:57 rbarnes: the hsts spec defines how you get the hsts information, store it, and use it 02:53:34 annevk: what mkwst means is that there is an upgrade step but there's nothing in fetch that says "handle the response to see if there's hsts" 02:53:53 yoav: would be nice if priming could be async 02:54:03 annevk/rbarnes: you have to block the request 02:54:18 yoav: I want to be able to send these priming requests ahead of time 02:54:28 mkwst: ...as part of the preload phase 02:55:09 JeffH: I should chat with you guys. I'm still concerned 02:55:32 annevk: not mentioned here, but in the html spec there's a bit about the websocket requests and hsts 02:55:54 JeffH: we have folklore locked up in our brain. we need to document this because we're not all here forever 02:55:57 s/concerned/concerned about references that should appear in IETF HSTS/ 02:56:08 q? 02:56:10 ... a lot of times there are missing linkages 02:57:12 rrsagent, please stay 02:57:21 bhill2: adjourning for lunch, resuming at 1:15 03:08:00 barryleiba has joined #webappsec 03:31:42 virginie has left #webappsec 03:53:59 yoav has joined #webappsec 03:54:17 barryleiba has joined #webappsec 03:55:31 rbarnes has joined #webappsec 03:56:25 rrsagent, make minutes 03:56:25