16:52:22 <RRSAgent> RRSAgent has joined #webappsec
16:52:22 <RRSAgent> logging to http://www.w3.org/2016/11/16-webappsec-irc
16:53:19 <wseltzer> wseltzer has changed the topic to: WebAppSec 16 Nov https://lists.w3.org/Archives/Public/public-webappsec/2016Nov/0010.html
16:58:32 <bhill2_> bhill2_ has joined #webappsec
17:00:33 <bhill2_> present+ bhill2
17:00:45 <bhill2_> topic: https://lists.w3.org/Archives/Public/public-webappsec/2016Nov/0009.html
17:00:52 <wseltzer> present+ wseltzer
17:00:57 <bhill2_> zakim, list attendees
17:00:57 <Zakim> As of this point the attendees have been bhill2, wseltzer
17:01:25 <bhill2_> present+ JohnWIlander
17:01:27 <dydz> dydz has joined #webappsec
17:01:48 <bhill2_> present+ Daniel Bates
17:01:57 <mkwst> present+ mkwst
17:02:20 <bhill2_> Meeting: WebAppSec WG Teleconference, 16-Nov-2016
17:02:45 <teddink> present+ teddink
17:03:10 <bhill2_> Chairs: bhill2, dveditz
17:03:59 <bhill2_> present+ Deian Stefan
17:04:34 <bhill2_> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2016Nov/0009.html
17:04:41 <puhley> puhley has joined #webappsec
17:05:03 <bhill2_> TOPIC: Agenda Bashing
17:05:05 <bhill2_> none requested
17:05:10 <ArturJanc> ArturJanc has joined #webappsec
17:05:16 <dveditz> present+  dveditz
17:05:22 <ArturJanc> present+
17:05:25 <deian> deian has joined #webappsec
17:05:33 <mkwst> bhill2_: Normally we'd approve minutes.
17:05:51 <mkwst> ... But the automated minute uploader is down. I'll fix that up sometime soon.
17:06:03 <mkwst> TOPIC: News.
17:06:12 <wseltzer> q+
17:06:12 <mkwst> bhill2_: CSP2 is a proposed rec! Yay!
17:06:33 <mkwst> wseltzer: Reminder to remind your AC reps to support CSP2 -> REC.
17:06:45 <mkwst> ... AC review, showing of support is helpful.
17:06:51 <wseltzer> q-
17:07:04 <mkwst> bhill2_: Implementation of CSP: Embedded Enforcement.
17:07:51 <mkwst> ... `CSP-Allow-Origin`
17:07:53 <terri> present+ terri
17:08:14 <bhill2_> mkwst: allows an embedder to enforce a policy on an embedee
17:08:34 <bhill2_> ... suggest a policy for framed content, browser will only load if content agrees
17:09:20 <bhill2_> ... content agrees by a header listing what policy it agrees to, or if the enforced policy is subsumed by that policy
17:09:32 <bhill2_> ... right now we only do the CSP-Allow-Origin piece and are working on the other piece
17:09:54 <mkwst> bhill2_: Two requests for review.
17:10:08 <mkwst> ... IndexedDB. Screen Orientation.
17:10:20 <mkwst> ... Still working on a process for responding to these kinds of requests.
17:10:34 <mkwst> ... Folks are encouraged to take a look at these documents and provide feedback.
17:10:48 <mkwst> deian: To what extent can we chime in here?
17:11:09 <wseltzer> q+
17:11:18 <mkwst> ... For instance, IndexedDB says it doesn't handle PII, but some developers do store interesting data in these databases.
17:11:28 <mkwst> bhill2_: Everyone should feel encouraged and empowered to chime in.
17:11:37 <mkwst> ... We're all responsible for the security of the platform.
17:11:42 <mkwst> ... We're charted to advise.
17:11:48 <wseltzer> q-
17:11:50 <mkwst> ... "Wide" review is intended to be wide.
17:12:01 <mkwst> ... So say things if you think things should be said.
17:12:12 <mkwst> dveditz: Where do the reviews go?
17:12:30 <mkwst> ... "File comments as GitHub issues." Got it.
17:12:49 <mkwst> wseltzer: Right, folks are generally moving to GitHub. Will tag issues as "security".
17:13:07 <mkwst> bhill2_: Group by group. Each call for review will generally specify how comments should be submitted.
17:13:16 <mkwst> TOPIC: Rechartering.
17:13:28 <mkwst> bhill2_: Charter expires at the end of the year. Talked about this a bit a TPAC.
17:13:40 <mkwst> ... Scope is pretty broad, covers the things we're thinking about.
17:13:56 <mkwst> ... Anti-clickjacking might end up in Intersection Observer.
17:14:09 <mkwst> ... Perhaps we should make room to give it a home?
17:14:15 <mkwst> ... Discussion at TPAC.
17:14:26 <mkwst> ... ArturJanc suggested that we specifically mention XSS and CSRF.
17:14:45 <mkwst> ... And carve out room for SafeNode, etc.
17:14:48 <wseltzer> q+
17:14:54 <mkwst> ... And deal with large problems like timing attacks and side channels.
17:14:55 <bhill2_> ack wseltzer
17:15:24 <mkwst> wseltzer: A topic I'd like to bring to the group:
17:15:28 <bhill2_> wseltzer: we've been dealing with the question of normative references to Fetch for a while
17:15:30 <mkwst> ... Normative references to Fetch, etc.
17:15:38 <bhill2_> (will let you continue, mike, thanks)
17:15:43 <mkwst> ... Should that be in the charter more explicitly?
17:16:29 <mkwst> ... Fetch in WHATWG poses something of a challenge to the platform because there's a split among implementers and developers about whether they're able to use it.
17:16:53 <mkwst> ... IPR policy, royalty free commitments, process around recommendations.
17:16:57 <mkwst> ... Important to some implementers.
17:17:12 <mkwst> ... If we're not all looking at the same algorithms, that can cause security issues.
17:17:27 <mkwst> ... Small details around hooks matter.
17:17:40 <mkwst> ... Working to offer work modes that work with WHATWG.
17:17:43 <mkwst> ... Still trying to do that.
17:17:58 <mkwst> ... Looking to find a mode that works with WHATWG's existing development mode.
17:18:11 <mkwst> ... Snapshot and bring levels of the spec through the REC process.
17:18:29 <mkwst> ... Patent commitments attach at the time we hit REC.
17:18:31 <john_wilander_> john_wilander_ has joined #webappsec
17:18:51 <mkwst> ... Living standards are great for lots of things. We also need snapshots.
17:19:07 <mkwst> ... They're the pieces to which we can say folks have made patent commitments.
17:19:31 <mkwst> bhill2_: It would be great if we could come to agreement.
17:19:40 <mkwst> ... Not sure we have anything approaching consent from the relevant authors.
17:19:58 <mkwst> ... Wouldn't be unhappy to open up the possibility of bringing that into our scope.
17:20:35 <mkwst> ... But probably best to bring into email, as it would be a substantial extension of our scope, so folks will need to bring it to their counsel.
17:20:44 <mkwst> dveditz: CORS?
17:21:02 <mkwst> bhill2_: We included CORS by saying we were looking at cross-origin mashups and cooperation.
17:21:05 <mkwst> ... Fetch is bigger.
17:21:21 <mkwst> wseltzer: Taking that up would give us a clearer way to point people to active CORS development.
17:21:27 <mkwst> bhill2_: That was a concern I heard at TPAC.
17:21:29 <wseltzer> q+
17:21:46 <mkwst> ... W3C version forks SEO, etc.
17:21:53 <mkwst> ... Would be good to address those concerns.
17:22:03 <mkwst> wseltzer: Taking search engine traffic wouldn't be our goal.
17:22:24 <mkwst> ... We can recommend a stable version, but recommend to implementers that they file bugs against the development version.
17:22:38 <mkwst> bhill2_: Objections to ArturJanc's suggestions?
17:22:44 <mkwst> [crickets]
17:22:51 <teddink> No objections
17:23:12 <mkwst> bhill2_: Ok. We'll prepare an updated charter, and submit it to the group for review.
17:23:16 <bhill2_> TOPIC: Restrict window.name on cross-origin navigation
17:23:21 <mkwst> ... (We == dveditz and bhill2_)
17:23:30 <mkwst> bhill2_: john_wilander_ you wanted to raise this?
17:23:39 <mkwst> john_wilander_: Right. This was discussed back in July.
17:23:53 <mkwst> ... mkwst said Chrome could capture data on usage of `window.name`.
17:24:04 <mkwst> mkwst: I didn't do this. Sorry. :(
17:24:17 <mkwst> john_wilander_: We've started looking into this.
17:24:24 <mkwst> ... Ran into test failures from W3C.
17:24:31 <mkwst> ... Mostly around iframes that navigate cross-origin.
17:24:39 <mkwst> ... Could be starting from unique going to non-unique.
17:24:51 <mkwst> ... Embedder has named the frame, addresses the frame through its name.
17:24:59 <mkwst> ... More concerned about top-origin navigation.
17:25:19 <mkwst> dveditz: Addressing frames through their name is one of the primary purposes of `window.name`, right?
17:25:40 <mkwst> john_wilander_: We started clearing `window.name` upon cross-origin navigation.
17:25:46 <mkwst> ... Breaks some tests.
17:25:52 <mkwst> dveditz: Frames and popups, sites do that.
17:25:59 <mkwst> ... At least they did 10 years ago.
17:26:24 <mkwst> john_wilander_: Were also thinking about restricting length or characters in the string. Currently DOMString.
17:26:25 <deian> I think it's still the case. Some folks working on FF (bholley and bz) looked at removing window.name. They may have some metricts from looking at this
17:27:04 <mkwst> john_wilander_: Initially, this was called out as part of the evercookie; if `window.name` is never set, it persists.
17:27:12 <mkwst> ... Persistent tracker, etc.
17:27:20 <mkwst> ... Also called out as payload mechanism for XSS attacks.
17:27:33 <mkwst> ... Can dump JS into `window.name`, and then use it in the loaded page.
17:27:52 <mkwst> ... Acts like an environment variable that can make it easier to bypass XSS protections.
17:28:27 <mkwst> dveditz: So if we made it read-only, `window.open()`, etc, that would help the first case, but not the second. And it may or may not break things.
17:28:30 <mkwst> john_wilander_: Yup.
17:29:24 <mkwst> mkwst: I don't think this is a bad idea, FWIW. I didn't add metrics because I didn't think about it when I was in front of a computer, not because I think it's bad.
17:29:38 <mkwst> john_wilander_: We might ship it into Safari's tech preview to get feedback.
17:30:09 <bhill2_> (mike, I'll take over scribing from this topic forward, thanks)
17:30:11 <mkwst> mkwst: I'm interested in hearing what y'all hear. :)
17:30:11 <bhill2_> TOPIC: Restrict the loopback address to same-origin or Secure Contexts
17:30:41 <bhill2_> TOPIC: Restrict CORS-safelisted request headers according to RFC 7231,
17:31:07 <bhill2_> john_wilander: brought up at MtnView F2F, currently on a csp thread
17:31:19 <bhill2_> ... currently 4 safelisted request headers, of those only Content-Type has any restrictions on it
17:31:36 <bhill2_> ... that means a CORS requestor can add accept, accept-language and content-language with any characters in it
17:31:53 <bhill2_> ... reported when shellshock was a thing, to cross-origin send requests to servers with shellshock payload in it
17:32:15 <bhill2_> ... RFC7231 implies that the content should be restricted, but not what browsers implement
17:32:25 <bhill2_> ... we would like to enforce that
17:33:04 <bhill2_> bhill2: any thoughts from other implementers?
17:33:16 <bhill2_> mkwst: think the idea is generally reasonable, need to skim the thread for Jonas' concern
17:33:26 <bhill2_> ... seems he has issues with cors preflights generally
17:33:43 <bhill2_> ... notion of restricting values sent for a simple cors preflight is probably in line with the idea of a cors preflight
17:34:03 <bhill2_> ... limiting that data to protect unaware servers seems like a good thing to do, period
17:35:46 <bhill2_> dveditz: sicking is concerned that networking team weigh in
17:36:00 <puhley> puhley has joined #webappsec
17:36:00 <bhill2_> mkwst: can we put on agenda for next call to make sure we follow up?
17:36:14 <bhill2_> ... get an opinion from Chrome side, Dan organize an opinion from Mozilla
17:36:18 <teddink> I will make sure that someone on our networking side is looped in - they should have an opinion.
17:36:29 <bhill2_> dveditz: looks like Yoshino has an opinion, not sure Sicking is reachable
17:36:47 <bhill2_> TOPIC: Restrict the loopback address to same-origin or Secure Contexts
17:37:26 <bhill2_> john_wilander: started by looking at mixed content with local servers
17:37:35 <bhill2_> ... that want to do privileged things, mostly on desktop
17:37:54 <bhill2_> ... companion apps set up a local websocket server so extension can talk to local server, store things in crypto keychain, etc.
17:38:14 <bhill2_> ... dropbox has brought up that they would like to have some restrictions on this
17:38:27 <bhill2_> ... we treat it as mixed content, so an https page cannot talk to a local websocket but an http page can
17:38:42 <bhill2_> ... we would like to say that loopback address is actually secure and flip this
17:39:36 <bhill2_> dveditz: we've already agreed to first point to treat 127.0.0.1 as secure, and we are leaning towards localhost being localhost
17:39:57 <bhill2_> mkwst: not only in secure contexts and mixed content and is in candidate rec that should move to PR at some point
17:40:10 <bhill2_> ... chrome has already shipped behavior that 127.0.0.1 is accessible from secure contexts
17:40:28 <bhill2_> crispin: can someone recap what happened in last call's discussion
17:41:19 <mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/1652 https://www.chromestatus.com/metrics/feature/timeline/popularity/1653
17:41:25 <dveditz> https://www.w3.org/2016/10/19-webappsec-minutes.html
17:41:27 <wseltzer> rrsagent, draft minutes
17:41:27 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/16-webappsec-minutes.html wseltzer
17:41:28 <teddink> present+ Crispin Cowan
17:41:28 <bhill2_> mkwst: there are some metrics but only for dev channel at this point, will be more useful when they hit beta and stable
17:42:02 <bhill2_> mkwst: ratio of secure to non-secure is about 1:1 on dev channel
17:42:03 <dveditz> Crispin: see link above (10/19) for last minutes
17:42:51 <bhill2_> crispin: we had unexpected surprises when we tried this in Edge
17:43:00 <bhill2_> mkwst: I expect it will be AV
17:43:40 <bhill2_> crispin: we also hit cloud storage, DRM and CDNs
17:43:56 <bhill2_> ... so expect there are existing use cases that will be broken by this
17:44:16 <bhill2_> john_wilander: are you saying a page served from http is making connections to localhost?
17:44:29 <bhill2_> crispin: two years ago Edge made an attempt to do this, just blocked it
17:44:41 <bhill2_> ... a fair number of important partner organizations said we broke them
17:46:05 <bhill2_> ... they were using real local servers that they wanted to talk to
17:46:34 <tanvi> tanvi has joined #webappsec
17:46:40 <bhill2_> john_wilander: we have at least two password managers
17:47:02 <bhill2_> TOPIC: Clarify worker-src goals
17:48:17 <bhill2_> mkwst: suggests a few things
17:48:28 <bhill2_> ... 1. treat workers as scripts, not as child contexts
17:48:38 <bhill2_> ... 2. move worker-src to sit on top of script-src
17:48:46 <mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/258
17:48:46 <bhill2_> ... think this is reasonable, anne asked for it a while ago
17:49:42 <bhill2_> ... other question is whether various types of workers should have their own policy
17:49:52 <bhill2_> ... or should inherit the policy of the page that creates it
17:50:09 <bhill2_> ... Brian's suggestion is that dedicated workers are scripts and should have the same policy
17:50:21 <mkwst> https://twitter.com/mikewest/status/798464142206087168
17:50:26 <deian> deian has joined #webappsec
17:50:48 <deian> +1 in favor of these changes
17:50:54 <bhill2_> ... people have no idea what we are doing so there is opportunity to change it
17:51:54 <bhill2_> ... to me making a shared/service worker dependent on the context of the page that created it seems strange
17:52:06 <deian> I'm with you on it being strange. Though the suggestions for normal workers sounds good to me
17:52:58 <mkwst> bhill2_: Yeah, I think we went with this direction because it would be strange for shared/service worker behavior to be dependent upon the page that opened them.
17:53:58 <bhill2_> mkwst: would be good if folks interested hop onto that github thread
17:54:22 <bhill2_> TOPIC: Redacting ancestorOrigins according to Referrer Policy?
17:54:32 <bhill2_> https://github.com/w3c/webappsec-referrer-policy/pull/77
17:57:30 <bhill2_> bhill2: <rambling summary of thread>
17:57:43 <bhill2_> mkwst: think jochen wants to do minimal amount of work, not clear what that is
17:57:57 <bhill2_> ... if we could get a commitment from Firefox as to what they would ship, that would help
17:58:15 <bhill2_> ... emily wants to do minimum amount of work to call Referrer Policy done, move to CR and be done
17:58:42 <bhill2_> ... I think this makes sense, if we can come to a compromise that would be great
17:59:02 <bhill2_> ... fits well with what referrer policy should do, is a good idea regardless of Firefox shipping
18:00:00 <bhill2_> bhill2: is pairwise compare OK?
18:00:03 <bhill2_> mkwst: prefer that
18:01:15 <terri> +1 to moving it up one week for dec
18:01:31 <wseltzer> [Dec 14]
18:01:35 <bhill2_> zakim, list attendees
18:01:35 <Zakim> As of this point the attendees have been bhill2, wseltzer, JohnWIlander, Daniel, Bates, mkwst, teddink, Deian, Stefan, dveditz, ArturJanc, terri, Crispin, Cowan
18:01:39 <bhill2_> rrsagent, make minutes
18:01:39 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/16-webappsec-minutes.html bhill2_
18:01:43 <bhill2_> rrsagent, make logs world
18:02:23 <john_wilander_> john_wilander_ has left #webappsec
18:03:38 <wseltzer> i/MtnView/scribenick: bhill2_
18:03:49 <wseltzer> rrsagent, draft minutes
18:03:49 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/16-webappsec-minutes.html wseltzer
18:04:27 <wseltzer> i/Normally/scribenick: mkwst
18:04:29 <wseltzer> rrsagent, draft minutes
18:04:29 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/16-webappsec-minutes.html wseltzer
18:05:14 <bhill2> bhill2 has joined #webappsec
18:07:22 <bhill2> bhill2 has joined #webappsec
19:27:14 <tanvi> tanvi has joined #webappsec
19:34:47 <bhill2> bhill2 has joined #webappsec
20:22:35 <Zakim> Zakim has left #webappsec