14:50:48 RRSAgent has joined #webappsec 14:50:48 logging to http://www.w3.org/2016/07/13-webappsec-irc 14:50:49 then we should be good to move forward 14:51:11 thank you :) 14:51:21 then I'll repeat what I just said.. 14:51:21 you might send email, for broader visibility 14:51:40 oh, I just saw this specific question on the agenda that Brad sent around 14:51:47 I don't think it's particularly urgent 14:51:58 anyway, about Referrer policy moving forward 14:52:05 I'd like to add some text about CSS and referrers 14:52:16 now that we have the referrer policy header, I think we're in a good place where we can spec this 14:52:22 once that's done, we can move forward 14:52:56 EOM :) 14:53:25 rrsagent, make logs public 14:53:29 rrsagent, draft minutes 14:53:29 I have made the request to generate http://www.w3.org/2016/07/13-webappsec-minutes.html wseltzer 15:37:48 Zakim has joined #webappsec 15:38:10 botie has joined #webappsec 15:38:46 botie, inform bhill2 jochen left some notes on irc earlier, http://www.w3.org/2016/07/13-webappsec-minutes.html 15:38:46 will do 15:46:35 bhill2 has joined #webappsec 15:46:35 bhill2, at 2016-07-13 15:38 UTC, wseltzer said: jochen left some notes on irc earlier, http://www.w3.org/2016/07/13-webappsec-minutes.html 15:51:58 estark has joined #webappsec 15:53:09 dydz has joined #webappsec 15:55:25 yoav has joined #webappsec 15:57:30 bhill2_ has joined #webappsec 15:59:03 bhill2_ has changed the topic to: https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0014.html 16:00:47 Meeting: WebAppSec Teleconference, 13-Jul-2016 16:00:50 Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0014.html 16:01:00 Chairs: bhill2, dveditz 16:01:14 RRSAgent, draft minutes 16:01:14 I have made the request to generate http://www.w3.org/2016/07/13-webappsec-minutes.html bhill2_ 16:01:28 present+ bhill2, mkwst 16:01:37 present+ estark 16:01:49 present+ daniel bates 16:02:08 present+ terri 16:02:29 present+ dveditz 16:02:42 regrets+ wseltzer 16:02:51 can do 16:02:54 teddink_ has joined #webappsec 16:03:16 moneill2 has joined #webappsec 16:03:16 pranjal has joined #webappsec 16:04:15 present+ teddink 16:04:30 TOPIC: agenda bashing 16:04:49 bhill2_: Sent out a call for agenda items, put together some topic from the last month and a half. 16:04:55 ... Anything I missed? 16:05:06 Everyone: 16:05:07 TOPIC: minutes approval 16:05:20 https://www.w3.org/2011/webappsec/draft-minutes/2016-05-17-webappsec-minutes.html 16:05:20 https://www.w3.org/2011/webappsec/draft-minutes/2016-05-16-webappsec-minutes.html 16:05:31 bhill2_: Objections to approving these minutes? 16:05:31 bhill2: any objections to unanimous approval? 16:05:35 Everone: 16:05:39 bhill2_: Approved. 16:05:53 TOPIC: transition of some specs to WG NOTE 16:06:10 bhill2_: We put things on the board at the end of day 1 of the F2F. 16:06:23 francois has joined #webappsec 16:06:31 ... Came up with a list of things we might want to transition to NOTE. 16:06:40 ... CfC expires next Friday. 16:06:56 ... This basically means that we're not taking them towards REC. Just archived for historical purposes. 16:07:32 ... FPWD retains some IPR if we resurrect them (and we can, this isn't irrevocable). 16:07:39 ... Cookie Controls was the first one. 16:07:50 ... Mike suggested that Feature Policy might be a better home. 16:07:55 The Feature Policy proposal ( 16:07:55 https://wicg.github.io/feature-policy/) could be a better home for the 16:07:55 intended functionality as part of a broader and more coherent approach, 16:07:57 rather than putting this into CSP. 16:08:05 q 16:08:27 bhill2: would clear site data be also under feature policy? 16:08:46 mkwst: I see it as distinct because it operates on the storage for an origin and not just a page / resource 16:08:56 ... enough interest that it's worth continuing in that 16:09:02 estark: Is feature policy done by WebAppSec? 16:09:11 bhill2_: Currently in incubator group. WICG. 16:09:23 tanvi has joined #webappsec 16:09:26 ^ tanvi? wasn't me 16:09:34 present+ tanvi 16:09:36 yeah, that was me 16:10:10 mkwst: don't have a target group at the moment, Chrome puts ideas into incubation before looking for a group 16:10:10 present+ francois 16:10:21 ... when we are far enough along and have enough experience we think about where to move it 16:10:37 ... my impression is that web perf is interested but also some overlap here, no strong opinion 16:10:51 s/estark:/tanvi:/ 16:10:53 ... folks here and in web perf should be taking a look at it and there are a number of places it might life 16:11:34 moneill2: about cookie controls; one of the points of CSP was it allowed use of set-cookie headers in embedded resources 16:11:50 ... feature policy only gives control over javascript accessing document.cookie 16:12:13 mkwst: the only thing that would affect embedded resources is the embedded enforcement mechanism that we are investigating for CSP 16:12:30 ... which says you will only embed a frame if it accepts certain policy 16:12:51 moneill: but the CSP cookie controls allowed managing cookie headers for images, etc. 16:13:20 mkwst: it didn't and we didn't get far enough in specifying it; would suggest you look at Feature Policy, and we should consider how to handle that 16:13:50 ... document will suggest a policy that denies a certain thing for a set of origins, please file bugs against that as we might be able to support these features there 16:14:40 moneill2: meta tag in CSP was ruled out for feature policy, would be good to have that back as it is quite useful for content served by e.g. agencies 16:14:54 ... easier to have a library that can insert a meta tag than control headers 16:15:08 mkwst: good convo to have on the incubator group / github repo for feature policy 16:15:35 bhill2: any other concerns with stopping this work here? 16:15:52 Entry Point Regulation 16:15:52 https://www.w3.org/TR/epr/ 16:16:15 dveditz: Mozilla supports pushing this to NOTE. 16:16:25 bhill2_: Will ask drx to follow up on the list. 16:17:07 ... At F2F folks seemed to feel that the SameSite cookie work at the IETF took care of much of the same threats that EPR wanted to address. 16:17:22 terri: Sad to see it move to NOTE, but accurate, as no one is working on it. 16:17:23 terri: sad to see it moved to note but accurately reflects where the effort is 16:18:00 CSP Pinning 16:18:11 https://www.w3.org/TR/csp-pinning/ 16:18:25 bhill2_: We probably need something like this, but this probably isn't the right mechanism. 16:18:33 ... Costs to sending a default policy with all requests. 16:18:42 ... Platform needs a more general mechanism. 16:18:48 ... .well-known, manifest, etc. 16:19:00 mkwst: I agree. 16:19:38 TOPIC: Referrer Policy to PR: What is needed? 16:19:51 https://github.com/w3c/webappsec-referrer-policy/issues 16:20:07 bhill2_: Missing states we discussed at F2F have been added. 16:20:10 ... What's left? 16:20:23 estark: Three items left: 16:20:36 ... 1. Updating web platform tests: header and new policy states. 16:20:53 ... 2. Finish the HTML integration for the `referrerpolicy` attribute and new policy states. 16:21:18 Jochen left this note in IRC earlier: https://www.w3.org/2016/07/13-webappsec-minutes.html re: CSS 16:21:20 ... 3. Jochen wanted to do something for stylesheets. Process headers delivered with stylesheets for resources loaded via the sheet. 16:21:58 francois: I'm planning on doing some of the items Emily just mentioned. 16:22:05 ... New policy states to WPT and to HTML. 16:22:08 ... Fetch also. 16:22:11 q? 16:22:16 q+ 16:22:16 ... That's all I think is needed. 16:22:25 ack dveditz 16:22:37 dveditz: Two of the issues are in the 11 open issues for the spec. 16:23:12 dveditz: Perhaps we could invent a label for those issues in the repo so that we know what we need to get done. 16:23:35 https://github.com/w3c/webappsec-referrer-policy/issues/50 is the issue for finishing the work around the new states 16:24:09 dveditz: Just want to distinguish between editorial changes and big normative issues. 16:24:37 bhill2_: Meta-goal is to get specifications ready to go before TPAC, then I can poke at various folks about Fetch and HTML integrations. 16:24:54 ... That seems like a good forcing function to get resolution on these questions. 16:25:09 TOPIC: Mixed Content to PR 16:25:21 Should we allow localhost? 16:25:21 https://github.com/w3c/webappsec-mixed-content/issues/4 16:27:01 mkwst: 2 things: 1: align with secure contexts spec definitions; this has implications that 127.0.0.1 should not be considered mixed content 16:27:22 tanvi has joined #webappsec 16:27:24 ... because by going over loopback vs. network has same / similar security properties to something transiting the internet on a secure channel 16:27:37 ... 2: other issue is the name 'localhost' vs loopback address 16:28:04 ... there are some cases where localhost or *.localhost will hit the network for resolution, so would suggest we can't give it the same a priority secure designation 16:28:09 tanvi has joined #webappsec 16:28:14 ... as the loopback IP addresses 16:28:38 ... suggestions on the list were to align the document and update such that the name localhost doesn't have the same definition as loopback addresses 16:28:53 tanvi: should we do the second one first? or will we be decreasing security before increasing it? 16:29:18 mkwst: we are doing both at the same time in Chrome in Q3/Q4; I've landed for 127.0.0.1, have to check on localhost 16:29:45 ccowan: is this going to land with localhost CORS requirements as discussed at F2F? 16:30:03 mkwst: that is a bit more work and so I'm doing the one first, the other will take a bit longer 16:30:10 ccowan: as long as they're not incompatible in a sneaky way 16:30:38 mkwst: what this allows is folks to stop installing certificates for localhost which is an unalloyed good, later stuff will compose 16:30:42 ccowan: sounds great 16:30:46 tanvi: I'm ok with this change. 16:30:52 dveditz: +1 16:31:18 Zakim, who is here? 16:31:18 Present: bhill2, mkwst, estark, daniel, bates, terri, dveditz, teddink, tanvi, francois 16:31:20 On IRC I see tanvi, francois, pranjal, moneill2, teddink_, bhill2_, dydz, estark, botie, Zakim, RRSAgent, Jb, gszathmari, dveditz, MattN, terri, Mek_, adrianba, jyasskin, 16:31:20 ... slightlyoff, Josh_Soref, tobie, timeless, jochen___, jww, schuki, mounir, mkwst, wseltzer, trackbot 16:31:23 TOPIC: UIR with fallback 16:31:25 I'm even excited about this change: it should make it easier for some of our engineers working on protype hardware 16:31:31 https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0012.html 16:33:02 dveditz: he's proposing we do upgrade and if it fails, retry? 16:33:10 ... are redirects upgraded as well? 16:33:22 ... so we'd have to retry each half-loop potentially? 16:33:35 mkwst: I think we can work out these details 16:33:57 ... I understand why Peter likes the idea and the value he preceives 16:34:13 s/preceives/perceives 16:34:25 ... but we don't have any other mechanism in the platform that does something like this 16:34:42 ... so we have to do the work to invent that mechanism 16:35:00 ... this is problematic even for doing preflights for things like images as part of RFC1918 CORS 16:35:20 ... to support this at all we would need to do a request and start a new one that is tied to the old one and triggers all the same effects 16:35:38 ... this could be possible and there could be real value but not sure the effort would be justified 16:35:59 ... I do like the idea of magically turning it on and making one class of mixed content less prevalent 16:36:13 ... but don't think could implement in the near future, though that shouldn't be a gating factor on what we specify 16:36:35 tanvi: christophe doesn't think this is that difficult, but not super easy either, need justification and people asking for it 16:37:08 mkwst: peter's request is interesting on behalf of Let's Encrypt as a novel way to automate https upgrading 16:37:41 ... but also agree with brad that mixed scripts decrease that value 16:37:57 tanvi: some may be broken 16:38:27 mkwst: claim made was that it couldn't be automatic, would still need to be verified live after flipping the switch 16:38:44 ... opposed to allowing mixed scripts 16:38:58 yeah i wouldn't allow mixed script 16:39:41 tanvi: you're right, it would help some sites and not others and require testing 16:40:12 mkwst: interesting, has potential value, but not sure state of the world would allow it to be as automated as LE would like to do it by default 16:40:37 ... and with that, not sure the rearchitecting for the fallback would be worthwhile.... but that is colored by my understanding of the difficulty of implementing in Chrome 16:41:20 tanvi: our perspective at mozilla is to wait on this until we hear from websites that this would be really useful to them 16:42:10 bhill2: maybe Peter can give us some data by simulation. 16:42:21 mkwst: would also be interesting to know if a SW can polyfill this for origins we know about 16:43:17 ... add something to UIR that lets a ServiceWorker fill in with insecure content 16:45:12 bhill2: would still be opposed (with FB hat on) to allowing active mixed downgrades, need to know that redirecting user to https means https 16:45:52 TOPIC: Changing window.name behavior 16:45:59 https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0006.html 16:47:14 mkwst: seems reasonable to do what Artur suggests, clear on navigation as the spec says (but no browser actually does) 16:48:06 dveditz: believe that is for non-auxilliary windows, popups with names need to be targeted 16:48:16 mkwst: don't recall seeing that in the spec, but may have missed that 16:48:34 ... I think it is a reasonable thing to do regardless of what the spec says. Chrome doesn't clear it at all in any case. 16:48:51 ... would like to measure how often it is used and throw it away if low enough 16:49:03 ... but probably doesn't solve any XSS vectors because there are other sources 16:49:20 ... less inclined to break back compat because of that 16:50:21 ... doesn't appear that any Google bug bounties used window.name as a vector 16:51:20 bhill2_: Perhaps restricting character sets might be possible. 16:51:22 ccowan: if you restrict length, you will only break good applications, not malicious vectors 16:51:56 dveditz: not interested in changing charset or length, would break as much as flushing 16:52:06 ... would be nice to flush if data shows we can do it without breakage 16:52:50 mkwst: planning on adding metrics to next version of chrome (54) will hit stable in 12-18 weeks 16:53:23 TOPIC: CORS for developers: adopt as WG note? 16:53:30 https://docs.google.com/document/d/1AtxTDw-g9BSRW9n9kGTTqNkDTGcVfSKPAOjVGkPFu2k/edit#heading=h.gbk9567omrcz 16:54:36 interesting to publish as a WG note? 16:54:54 mkwst: I think so yes, would like to see more developer facing documentation from this group in general 16:55:02 ... both historical explainers and how-tos 16:55:15 terri: agree, would like to do more in this area 16:56:41 bhill2_: TPAC is coming. 16:56:49 ... In Portugal. 16:56:56 ... Our slot is Thursday and Friday. 16:57:00 ... After the AC meeting. 16:57:08 rrsagent, make minutes 16:57:08 I have made the request to generate http://www.w3.org/2016/07/13-webappsec-minutes.html bhill2_ 16:57:12 ... Maybe everything with Fetch, etc will be resolved already! 16:57:18 zakim, list attendees 16:57:18 As of this point the attendees have been bhill2, mkwst, estark, daniel, bates, terri, dveditz, teddink, tanvi, francois 16:57:23 rrsagent, make minutes 16:57:23 I have made the request to generate http://www.w3.org/2016/07/13-webappsec-minutes.html bhill2_ 16:57:30 rrsagent, set logs world 16:58:55 bhill2 has joined #webappsec 17:03:03 bhill2 has joined #webappsec 17:03:27 bhill2 has joined #webappsec 17:14:09 tanvi has joined #webappsec 18:12:00 bhill2_ has joined #webappsec 19:10:28 yoav has joined #webappsec 19:23:34 Zakim has left #webappsec 19:30:24 bhill2 has joined #webappsec 19:38:48 bhill2 has joined #webappsec 19:42:33 bhill2 has joined #webappsec 19:47:06 bhill2 has joined #webappsec 19:57:39 tanvi has left #webappsec 20:42:22 estark has joined #webappsec 21:03:55 bhill2 has joined #webappsec