15:33:26 <RRSAgent> RRSAgent has joined #webappsec
15:33:26 <RRSAgent> logging to http://www.w3.org/2014/10/27-webappsec-irc
15:33:28 <trackbot> RRSAgent, make logs world
15:33:28 <Zakim> Zakim has joined #webappsec
15:33:30 <trackbot> Zakim, this will be WASWG
15:33:30 <Zakim> ok, trackbot; I see SEC_WASWG()11:30AM scheduled to start 3 minutes ago
15:33:31 <trackbot> Meeting: Web Application Security Working Group Teleconference
15:33:31 <trackbot> Date: 27 October 2014
15:34:21 <wseltzer> zakim, call salon3
15:34:22 <Zakim> ok, wseltzer; the call is being made
15:34:22 <Zakim> SEC_WASWG()11:30AM has now started
15:34:23 <Zakim> +Salon3
15:40:38 <renoirb> Zakim, I am Renoir
15:40:38 <Zakim> sorry, renoirb, I do not see a party named 'Renoir'
15:47:25 <wseltzer> zakim, who is here?
15:47:25 <Zakim> On the phone I see Salon3
15:47:27 <Zakim> On IRC I see RRSAgent, bhill2, tobie, timeless, mkwst___, freddyb, renoirb, terri, wseltzer, trackbot
15:47:57 <wseltzer> zakim, Salon3 has bhill2, wseltzer, Renoir, wseltzer, rigo, Takeda,
15:47:57 <Zakim> +bhill2, wseltzer, Renoir, wseltzer, rigo, Takeda; got it
15:50:08 <wseltzer> zakim, Salon3 also has terri, timeless,
15:50:08 <Zakim> +terri, timeless; got it
15:50:31 <ckerschb> ckerschb has joined #webappsec
15:51:15 <Josh_Soref> Josh_Soref has joined #webappsec
15:51:27 <Kevin_Hill> Kevin_Hill has joined #webappsec
15:51:56 <timeless> topic: Introductions
15:52:08 <timeless> wseltzer: Wendy Seltzer, W3 Team Contact
15:52:27 <timeless> renoirb: Renoir, W3 Web Platform Docs
15:52:35 <rigo> rigo has joined #webappsec
15:52:35 <timeless> bhill2: Brad Hill, Chair, Facebook
15:52:45 <wseltzer> [thanks to our awesome scribe, timeless!]
15:52:47 <timeless> Josh_Soref: Josh Soref, BlackBerry, Scribe, Obscerver
15:52:49 <renoirb> s/W3 Web Platform Docs/W3C Team member, working on WebPlatform.org project/
15:53:05 <timeless> ckerschb: Christoph Kerschbom, Mozilla
15:53:11 <wei_james> wei_james has joined #webappsec
15:53:21 <timeless> Kevin_Hill: Kevin Hill, Microsoft
15:53:22 <ckerschb> s/Kerschbom/Kerschbaumer
15:53:30 <timeless> terri: Terri Oda, Intel
15:53:57 <wseltzer> zakim, Salon3 also has ckerschb, Kevin_Hill
15:53:58 <Zakim> +ckerschb, Kevin_Hill; got it
15:54:16 <timeless> keiji_takeda: Keiji Takeda, W3C KEIO, Japan
15:54:42 <wei_james> wei xiaohai
15:54:53 <timeless> s/wei_james/scribe/
15:55:10 <timeless> s/wei xiaohai/Wei Xiaohai, Tencent, China/
15:55:18 <colin> colin has joined #webappsec
15:55:29 <keiji> keiji has joined #webappsec
15:55:43 <timeless> colin: Colin, Whorlow, CESG (Observer)
15:56:04 <renoirb> I am an observer too
15:56:39 <timeless> jing_wang: Jing Wang, Qi, Observer
15:56:41 <wseltzer> zakim, Salon3 also has Wei_Xiaohai, Colin_Whorlow, fjh, Jing_Wang_Qi
15:56:41 <Zakim> +Wei_Xiaohai, Colin_Whorlow, fjh, Jing_Wang_Qi; got it
15:57:05 <timeless> fjh: Frederick Hirsch, Nokia
15:57:13 <rigo> rigo:  Rigo Wenning, W3C Staff, Observer
15:57:27 <timeless> s/rigo/scribe/
15:57:28 <timeless> s/rigo/scribe/
15:57:35 <timeless> s/scribe: //
15:57:39 <timeless> RRSAgent, draft minutes
15:57:39 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
15:57:47 <timeless> RRSAgent, make logs world
15:58:01 <timeless> wseltzer: thanks Josh_Soref for scribing
15:58:20 <timeless> s/ Rigo Wenning/rigo: Rigo Wenning/
15:58:21 <timeless> RRSAgent, make logs world
15:58:25 <timeless> RRSAgent, draft minutes
15:58:25 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
15:58:55 <bhill2> zakim, who is here?
15:58:55 <Zakim> On the phone I see Salon3
15:58:56 <Zakim> Salon3 has bhill2, wseltzer, Renoir, wseltzer, rigo, Takeda, terri, timeless, ckerschb, Kevin_Hill, Wei_Xiaohai, Colin_Whorlow, fjh, Jing_Wang_Qi
15:58:56 <Zakim> On IRC I see keiji, colin, wei_james, rigo, Kevin_Hill, Josh_Soref, ckerschb, Zakim, RRSAgent, bhill2, tobie, timeless, mkwst___, freddyb, renoirb, terri, wseltzer, trackbot
15:59:44 <glenn> glenn has joined #webappsec
16:00:14 <timeless> chair: bhill2
16:00:40 <timeless> s/Teleconference/F2F/
16:00:44 <timeless> RRSAgent, draft minutes
16:00:44 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
16:00:44 <bhill2> Topic: https://docs.google.com/document/d/1k6juq6E-mzlNzVr-tHhrh9mEh-d51Uf8wfgfo1I1yZQ/edit
16:00:49 <bhill2> bhill2 has changed the topic to: https://docs.google.com/document/d/1k6juq6E-mzlNzVr-tHhrh9mEh-d51Uf8wfgfo1I1yZQ/edit
16:00:50 <Zakim> +mkwst
16:01:10 <Jingwang_qi> Jingwang_qi has joined #webappsec
16:01:13 <Zakim> +tanvi
16:01:14 <timeless> mkwst___: Mike Wast, Google
16:01:25 <mkwst___> s/Wast/West/ :)
16:01:33 <timeless> s|s/Wast/West/ :)||
16:01:37 <timeless> s/Wast/West/
16:01:48 <timeless> tanvi: I'm on my way, I'll be late
16:02:05 <timeless> tanvi: Tanvi Vias, Mozilla
16:02:12 <timeless> s/Vias/Vyas/
16:02:49 <bhill2> Agenda: https://docs.google.com/document/d/1k6juq6E-mzlNzVr-tHhrh9mEh-d51Uf8wfgfo1I1yZQ/edit
16:03:44 <wseltzer> Present+ Brad_Hill, Christoph_Kerschbaumer, Kevin_Hill, Terri_Oda, Frederick_Hirsch, Keiji_Takeda, Renoir_Boulanger, Wendy_Seltzer
16:03:54 <timeless> dstefan: Deian Stefan, Stanford, Observer
16:04:15 <timeless> RRSAgent, draft minutes
16:04:15 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
16:04:56 <timeless> Topic: Agenda
16:05:10 <wseltzer> Present+ Josh_Soref, JingWang_Qi, Colin_Whorlow, Rigo_Wenning, Deian_Stefan, Wei_Xiaohai
16:05:10 <timeless> bhill2: I've put up the Agenda on Google Docs
16:05:15 <timeless> ... we can do some agenda bashing now
16:05:24 <timeless> ... I've also sent out a Survey Monkey survey
16:05:30 <bhill2> https://www.surveymonkey.com/s/8VPQT7J
16:05:31 <wseltzer> Present+ Mike_West, Tanvi_Vyas
16:05:31 <timeless> ... there are more than 7 people in the room now
16:05:39 <timeless> ... so, I ask people to fill out the survey
16:05:55 <timeless> s|https://www.surveymonkey.com/s/8VPQT7J|-> https://www.surveymonkey.com/s/8VPQT7J WebAppSec 2014 Rechartering Survey|
16:05:58 <timeless> RRSAgent, draft minutes
16:05:58 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
16:06:19 <timeless> ... we only have so much bandwidth, so we need to pick which items to focus on
16:06:30 <timeless> ... after people have time to fill out the survey
16:06:38 <timeless> ... I'll prune things from the plan
16:07:03 <timeless> ... of the topics /NOT/ on the survey, we'll have introductions
16:07:15 <fjh> fjh has joined #webappsec
16:07:15 <timeless> ... later this afternoon, we'll have David Ross, from Google dial in
16:07:29 <fjh> rrsagent, generate minutes
16:07:29 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html fjh
16:07:30 <timeless> ... to talk about Entry-Point-Regulation
16:07:34 <timeless> ... at 15:30 local-time
16:07:48 <timeless> ... if we can get things together, hopefully he can be a full member at that point
16:08:01 <timeless> ... today, we'll mostly do CSP in the morning session
16:08:09 <timeless> ... and possibly Referer-Policy and Mixed-Content
16:08:28 <timeless> ... immediately after lunch, we're going to host a 1hr meeting of the Web-Security Interest Group
16:08:39 <timeless> ... the IG is a cross section group
16:08:46 <timeless> ... it should be interesting, please come and attend that
16:08:56 <timeless> ... we'll resume at 15:15 to start on rechartering topics
16:09:07 <timeless> ... to talk about David Ross's idea, and first set of pruning
16:09:15 <timeless> ... tomorrow morning, we'll continue with Rechartering topics
16:09:26 <timeless> ... Frederick XXX and Joel Brown to talk about YYY
16:09:31 <timeless> ... after lunch, we have open time
16:09:54 <timeless> ... there's also an AC meeting then, I'll have to step out
16:10:02 <timeless> ... dveditz can run the meeting then
16:10:22 <timeless> ... we'll be one of the first groups to run into conflicts involving dependencies to WHATWG specs
16:10:34 <timeless> s/Frederick XXX/Frederik Braun/
16:10:40 <timeless> s/Joel Brown/Joel Weinberger/
16:10:45 <timeless> s/YYY/Subresource Integrity (SRI)/
16:10:58 <timeless> ... this meeting is the third anniversary of the WebAppSec WG
16:11:03 <timeless> ... we've only gotten one thing to REC
16:11:07 <anssik> anssik has joined #webappsec
16:11:13 <timeless> ... i'd like us to get more things to REC this year
16:11:20 <timeless> ... we have tests holding us up
16:11:28 <timeless> ... so i'd like to see work on Web CSP
16:11:37 <timeless> ... i'd like to see people working with these technologies
16:11:49 <timeless> ... 18-19% of pages based on Chrome metrics have CSP policies
16:12:03 <timeless> ... but based on web sites that have CSP it's only 0.1%
16:12:17 <timeless> ... i think we could do more to support the rest of the community getting the deployment percentage up
16:12:27 <timeless> ... AoB?
16:12:33 <timeless> RRSAgent, draft minutes
16:12:33 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
16:13:06 <timeless> ... I have a request in my inbox to have an AdHoc session at TPAC on Mandatory Secure Origins for new/powerful web platform features
16:13:26 <timeless> ... an ML thread started by Chris Palmer at google
16:13:42 <mkwst___> http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features <-- "Prefer Secure Origins For Powerful New Features"
16:13:43 <timeless> ... it's a question about whether W3C should lead the charge to an ALL https:// web
16:13:59 <timeless> s|http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features <-- "Prefer Secure Origins For Powerful New Features"|-> http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features "Prefer Secure Origins For Powerful New Features"|
16:14:02 <timeless> RRSAgent, draft minutes
16:14:02 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
16:14:13 <fjh_> fjh_ has joined #webappsec
16:14:14 <timeless> ... depending on how we progress through the agenda, maybe we can do that tomorrow as well
16:14:40 <timeless> fjh: you might want to include Usability and
16:14:49 <timeless> ... re: TBL's message  (to TAG?)
16:14:58 <timeless> ... it would be good to balance security with usability
16:15:29 <mkwst___> http://lists.w3.org/Archives/Public/www-tag/2014Sep/0040.html "XMLHTTPRequest restrictions by origin" is probably Tim's post that's being referred to.
16:15:29 <timeless> Topic: Usability and Consent
16:15:37 <timeless> fjh: there's a workshop in Berlin
16:15:42 <timeless> ... on Security/Usability
16:15:53 <timeless> ... this has also come up in DAP and everywhere
16:16:07 <timeless> ... we're looking to get papers+thoughts on how to improve the interaction with the user
16:16:12 <rigo> http://www.w3.org/2014/privacyws/
16:16:31 <timeless> s|http://www.w3.org/2014/privacyws/|-> http://www.w3.org/2014/privacyws/ W3C Workshop on Privacy and User–Centric Controls|
16:16:39 <timeless> topic: CSP issues
16:16:51 <wseltzer> Present+ Dan_Veditz
16:17:12 <timeless> i/Tanvi Vias, Mozilla/dveditz: Dan Veditz, Co-Chair, Mozilla/
16:17:20 <timeless> RRSAgent, draft minutes
16:17:20 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
16:17:25 <wseltzer> zakim, salon3 also has dveditz
16:17:25 <Zakim> +dveditz; got it
16:17:37 <timeless> bhill2: last week on Monday, I issued a call on the ML to move from LC to CR
16:17:43 <timeless> ... as part of that transition, this is more formal
16:17:47 <timeless> ... not just inside the WG
16:17:59 <timeless> ... we have to document that we've addressed all issues
16:18:16 <timeless> ... in scrubbing the ML, we need to be sure that we've formally addressed things
16:18:21 <timeless> ... a couple of things in the agenda
16:18:28 <timeless> ... a couple in the Tracker, and on Github
16:18:48 <timeless> ... thanks to mkwst___ for starting a thorough scrub of the ML
16:18:57 <bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0178.html
16:19:28 <timeless> ... Brian Smith wasn't sure if Referrer Policy belonged in CSP
16:19:48 <timeless> ... whether Referrer Policy reflected XSS
16:19:58 <timeless> ... should CSP strictly reduce privileges of a page
16:20:05 <timeless> ... or if they should be their own directive
16:20:10 <timeless> ... i believe the discussion in the group was
16:20:21 <timeless> ... as part of our charter, we're trying to reduce cognitive load
16:20:32 <timeless> ... and reduce header bloat
16:20:50 <timeless> ... I want to see if we can reach a consensus
16:20:59 <timeless> ... can we get a show of hands (anonymous for minutes)
16:21:11 <timeless> ... should we remove things which lesson restrictions
16:21:16 <wseltzer> s/lesson/lessen/
16:21:16 <timeless> Zakim, who is talking?
16:21:26 <Zakim> timeless, listening for 10 seconds I heard sound from the following: tanvi (4%), Salon3 (74%)
16:21:38 <timeless> mkwst___: He was more suggesting that they be in their own header
16:21:49 <timeless> dveditz: there would be a different spec for it
16:22:01 <timeless> mkwst___: the CSP2 delegates to QQQ
16:22:09 <wseltzer> Present+ Christine_Runnegar
16:22:10 <timeless> s/QQQ/Refer/
16:22:16 <timeless> ... RRR defers to SSS
16:22:21 <timeless> bhill2: why not use ...
16:22:26 <timeless> dveditz: because it's there
16:22:37 <timeless> ... I understand Brian Smith's objections
16:22:50 <timeless> ... if he's afraid of the feature in general
16:22:54 <timeless> ... but not if it's just where
16:23:03 <timeless> tanvi: what if we ....
16:23:09 <timeless> s/.../change the default/
16:23:13 <timeless> mkwst___: I believe that is what it does
16:23:18 <timeless> tanvi: ok
16:23:27 <timeless> dveditz: we need backwards compat with previous CSP
16:23:55 <timeless> mkwst___: we currently block a couple of CSP directives
16:24:00 <timeless> ... from being set in the Meta Header
16:24:03 <timeless> ... one is Sandbox
16:24:20 <timeless> ... another is Reflected XSS
16:24:26 <timeless> dveditz: another is Frame-Ancestor
16:24:29 <timeless> ... i think there were 4
16:24:35 <timeless> ... there's a slight discrepancy in the spec
16:24:40 <timeless> ... it lists 3 things
16:24:50 <timeless> ... but if you read frame-ancestors, it says...
16:24:59 <timeless> ... we should add frame-ancestors to the list
16:25:02 <timeless> ... for completeness
16:25:06 <timeless> mkwst___: we should do that
16:25:11 <timeless> bhill2: i'll file an issue
16:25:22 <timeless> mkwst___: the other is Report-URI
16:25:37 <timeless> mkwst___: whether the commonality of these three
16:25:43 <timeless> ... justifies splitting out to a separate header
16:25:51 <timeless> ... i fall to the "one-header" side
16:26:04 <timeless> ... developers say "i'm settings these policies"
16:26:25 <timeless> ... i'm sympathetic to the idea of cohesiveness "all positive, or all negative, all loosen, or all tighten"
16:26:31 <dveditz> dveditz has joined #webappsec
16:26:38 <timeless> ... a CSP header that tightens, or loosens,
16:26:45 <timeless> ... I haven't seen any proposals for names that make sense
16:26:49 <bhill2> created new GitHub Issue: https://github.com/w3c/webappsec/issues/67
16:26:59 <timeless> ... in the absence of such proposals, putting everything into a Policy bucket makes sense to me
16:27:00 <timeless> bhill2: +1
16:27:13 <timeless> ... as Chair, we have this specified, we're ready to go to CR
16:27:18 <deian> deian has joined #webappsec
16:27:24 <timeless> ... there's something to be said for being done rather than starting over
16:27:37 <timeless> ... the potential harm in terms of ideological consistency in the spec is small
16:27:47 <timeless> ... I suppose we could just define a header name in the existing Referrer spec
16:27:56 <timeless> ... I think short of that, we should default to leaving it where it is
16:28:02 <timeless> ... i don't see strong objections,
16:28:09 <timeless> ... It sounds like Brian Smith could live with it
16:28:14 <timeless> ... in the absence of strong objections
16:28:19 <timeless> ... I'll take an action to respond to him
16:28:27 <timeless> ... on the list, and close that as an open issue
16:29:07 <bhill2> http://www.w3.org/2011/webappsec/track/issues/62
16:29:22 <timeless> i/Referrer Policy belonged in CSP/Topic: CSP Issue: Referrer Policy belonged in CSP/
16:29:42 <timeless> Topic: CSP Issue: is reflected-xss at risk
16:29:50 <timeless> bhill2: I don't think Mozilla has an implementation
16:29:57 <timeless> ... Chromium has
16:30:11 <timeless> ... if Microsoft doesn't intend, then I think we need to take it out
16:30:35 <timeless> Kevin_Hill: We intend to implement
16:30:38 <timeless> ... i'll verify
16:31:19 <timeless> ... there's an actions assigned to David Walp on this
16:31:26 <timeless> mkwst___: WebKit also implements this
16:31:34 <timeless> ... but it isn't really a separate implementation
16:32:03 <bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0218.html
16:32:05 <timeless> Topic: CSP Issue: EEE
16:32:12 <timeless> s/Topic: CSP Issue: EEE//
16:32:24 <timeless> i/http/Topic: CSP Issue: report-only: "true|false"/
16:32:37 <timeless> bhill2: our conclusion was that if you're interested in this
16:32:47 <timeless> ... you could smuggle it in as part of a GET URI
16:32:54 <timeless> ... I want to see if we're happy with that
16:32:58 <timeless> dveditz: I'm really happy with that
16:33:07 <Zakim> -tanvi
16:33:08 <timeless> bhill2: no objections, we'll consider this resolved
16:33:13 <timeless> Topic: CSP Issue: EEE
16:33:18 <bhill2> https://url.spec.whatwg.org/#concept-url-origin
16:33:18 <timeless> RRSAgent, draft minutes
16:33:18 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
16:33:31 <timeless> s/EEE/concept-url-origin/
16:33:43 <timeless> bhill2: we touched on things like data, uri, source-doc
16:33:47 <timeless> ... after we talked about this
16:33:54 <timeless> ... the folks writing the URL spec decided
16:33:57 <Zakim> +tanvi
16:33:58 <timeless> ... Blob has an origin
16:34:08 <timeless> mkwst___: in chrome, I believe that a Blob will return the origin
16:34:21 <timeless> ... it's potentially problematic
16:34:33 <timeless> ... since it allows sites to bypass
16:34:41 <timeless> dveditz: our position would be
16:34:50 <timeless> ... if we don't require Blobs to be explicitly listed
16:35:00 <timeless> ... then we'd require unsafe-inline
16:35:09 <timeless> ... Blob is potentially the same as script-injected stuff
16:35:28 <timeless> mkwst___: i'd strongly suggest we make developers list Blobs explicitly as a frame source
16:35:37 <timeless> bhill2: if we're happy with the existing spec text
16:35:50 <timeless> ... and we aren't concerned that the new url-origin spec breaks things
16:36:03 <timeless> ... and we're not worried about WebRTC ...
16:36:07 <timeless> ... then I think we're ok
16:36:30 <fjh> fjh has joined #webappsec
16:36:40 <timeless> s/we're not worried about WebRTC/we'll have to discuss it in context of WebRTC later/
16:36:41 <bhill2> we have work items queued up for CSP v.next to deal with WebRTC, which will also re-raise how to deal with blobs of various origins and security properties
16:36:50 <timeless> RRSAgent, draft mintues
16:36:50 <RRSAgent> I'm logging. I don't understand 'draft mintues', timeless.  Try /msg RRSAgent help
16:36:52 <timeless> RRSAgent, draft minutes
16:36:52 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
16:36:58 <bhill2> so we can leave Level 2 as-is for now, and revisit in more depth in the future when this behavior is more defined
16:37:19 <gludi|2> gludi|2 has joined #webappsec
16:37:24 <timeless> Topic: CSP Issue: EEF
16:37:25 <bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0123.html
16:37:37 <timeless> s/EEF/img-src and inline <svg>/
16:37:54 <timeless> bhill2: should unsafe-inline be directed for img-src
16:38:17 <timeless> ... annevk discussed on the list that
16:38:40 <timeless> ... * CSP is about Fetching Resources
16:38:59 <timeless> ... * CSP is about Meeting Developer expectations protecting against attacks
16:39:08 <timeless> dveditz: CSP has grown into more than just a set of fetching rules
16:39:15 <timeless> ... which is why we argued for a fairly generic name
16:39:25 <timeless> ... but i don't think we want to change it to a feature-switch list
16:39:37 <timeless> ... to enable/disable html5 features because you happen not to like them
16:39:50 <timeless> ... from Mozilla's perspective, I think, inline-svg is just Page Content
16:39:58 <timeless> ... it shouldn't need to be covered by an on-off
16:40:02 <timeless> bhill2: i'm happy with that
16:40:13 <timeless> ... you could draw a picture using a Table
16:40:41 <timeless> dveditz: the scripts in svg would be controlled by the page's policy on controlling scripts
16:40:49 <timeless> bhill2: i'm sympathetic, and i'm happy to consider the issue closed
16:40:53 <timeless> ... that svg is page content
16:41:09 <timeless> dveditz: if it's loaded as an image, CSP is applied to the fetch before we discover it's an image
16:41:23 <timeless> bhill2: it's a slippery slope, there's no logical place to stop
16:41:27 <timeless> ... anything other than <script>
16:41:44 <bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0015.html
16:42:05 <timeless> i/http/Topic: CSP Issue:  prevent 401 attach/
16:42:06 <gludi|3> gludi|3 has joined #webappsec
16:42:18 <timeless> bhill2: I think we want to explicitly punt for CSP2
16:42:24 <timeless> ... there's some history here
16:42:32 <timeless> ... i think PayPal found this issue and reported it
16:42:35 <timeless> ... browsers fixed it
16:42:43 <timeless> ... and it turned out to be a security-nightmare
16:42:46 <timeless> ... and it was ripped out
16:42:54 <timeless> ... if I include a third party image
16:42:59 <timeless> ... if that image returns 401
16:43:14 <timeless> ... you'll get a browser-security-prompt for the dialog
16:43:32 <timeless> ... and users will think it was coming from the top-level-page
16:43:45 <timeless> ... Chrome blocked the load silently
16:43:52 <timeless> ... but without rate-limiting
16:43:59 <timeless> ... which allowed for attacks on home routers etc.
16:44:03 <gludi|3> gludi|3 has left #webappsec
16:44:11 <timeless> ... because http-basic implementations rarely have rate-limiting
16:44:26 <timeless> ... the question is should we put this on CSP3 and ask resource owners define policies
16:44:35 <timeless> mkwst___: i think i'd agree that we should come up with a policy
16:44:41 <timeless> ... and not require web sites define a policy
16:44:50 <timeless> ... it isn't clear to me if it should be part of mixed-content
16:44:59 <timeless> ... where is Digest/Mixed auth defined?
16:45:11 <timeless> dveditz: HTTP, and handling of prompts is left as an exercise to the UA
16:45:24 <timeless> mkwst___: i'd suggest auto-fail any non-top-level-origin request
16:45:33 <timeless> ... i doubt it's web-safe
16:45:38 <timeless> ... but it's something i'd like to try
16:45:50 <timeless> dveditz: without the page author having to say how to handle it
16:45:58 <timeless> ... --- i think it's appropriate for our WG to discuss
16:46:08 <timeless> ... I don't know if you could have a policy
16:46:15 <timeless> ... is CSP the place to put it
16:46:24 <timeless> ... we should discuss it in our group
16:46:36 <timeless> ... or perhaps w/ the WS IG
16:46:44 <timeless> ... as a security thing, it's well w/in our scope
16:46:49 <timeless> ... but I don't know what
16:46:53 <timeless> ... i'd rather something that just-works
16:46:59 <timeless> ... without authors having to say something
16:47:07 <timeless> ... in which case it probably goes into HTML
16:47:12 <timeless> ... i don't think it goes into Mixed
16:47:20 <timeless> ... because the issue is wether or not it's Mixed
16:47:21 <timeless> mkwst___: +1
16:47:30 <timeless> ... it doesn't feel like it's a decision website authors should make
16:47:36 <timeless> ... and I don't think they'd make it well
16:47:48 <timeless> tanvi: I think Chrome's implementation only doesn't do it for Images
16:47:52 <timeless> ... they tried XHR and others
16:47:59 <timeless> ... I don't know we can do this w/o breaking compat
16:48:20 <timeless> bhill2: I think there were cases of Enterprise Single Signon using tracking pixels
16:48:35 <timeless> ... for this part of the agenda, that it's clear it isn't CSP2, and probably not CSP.next
16:48:40 <timeless> ... but it's clear it should have a home
16:48:55 <timeless> ... I'll create an issue, and respond to Hatter Jiang
16:48:59 <timeless> ... objections?
16:49:00 <timeless> [ None ]
16:49:12 <timeless> Topic: CSP Issue: EEG
16:49:27 <timeless> RRSAgent, draft minutes
16:49:27 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
16:50:01 <timeless> s/EEG/may we have script-ancestors to protect JSONP call/
16:50:31 <timeless> -> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0146.html may we have script-ancestors to protect JSONP call
16:50:57 <timeless> bhill2: we'll respond that this is under consideration for v.Next
16:51:11 <bhill2> https://www.w3.org/2011/webappsec/track/issues/open
16:51:28 <timeless> i/http/Topic: CSP Issues: Tracker
16:51:34 <timeless> s|i/http/Topic: CSP Issues: Tracker||
16:51:37 <timeless> i/http/Topic: CSP Issues: Tracker/
16:51:41 <bhill2> https://www.w3.org/2011/webappsec/track/issues/30
16:52:42 <wseltzer> Present+ Nick_Doty
16:52:53 <timeless> i/http/Topic: CSP Issues: ISSUE-30 How to address dynamic application of CSP post page load .../
16:53:01 <timeless> bhill2: I think this is already addressed in the spec
16:53:42 <timeless> dveditz: is that for static or dynamic?
16:53:45 <timeless> ... we've resolved the meta
16:53:53 <timeless> ... but for scriptable, we've punted to a future version
16:53:59 <timeless> mkwst___: scriptable is covered by ISSUE-34
16:54:06 <timeless> dveditz: ok, ISSUE-30 is done
16:55:35 <timeless> Topic: CSP Issues: ISSUE-31
16:55:40 <timeless> bhill2: are we ok on this?
16:55:42 <wseltzer> issue-31?
16:55:42 <trackbot> issue-31 -- What specification's definition of URL/URI are we using for path parsing in CSP 1.1? -- open
16:55:42 <trackbot> http://www.w3.org/2011/webappsec/track/issues/31
16:55:46 <timeless> mkwst___: we're as ok as HTML is
16:56:02 <timeless> bhill2: closed...
16:56:15 <timeless> Topic: CSP Issues: ISSUE-33
16:56:27 <timeless> issue-33?
16:56:27 <trackbot> issue-33 -- Need to address blob, data, filesystem URL types with greater specificity in CSP 1.1 spec -- closed
16:56:27 <trackbot> http://www.w3.org/2011/webappsec/track/issues/33
16:56:56 <bhill2> https://www.w3.org/2011/webappsec/track/issues/37
16:56:59 <timeless> s/ISSUE-33/ISSUE-37/
16:57:04 <Zakim> -tanvi
16:57:06 <timeless> mkwst___: I think we addressed this
16:57:08 <bhill2> Move past this one for now, need more context.
16:57:36 <timeless> Topic: CSP Issues: ISSUE-54 policy-uri vs. policy-url
16:57:53 <timeless> dveditz: we dropped policy-...
16:58:03 <timeless> bhill2: annevk was bothered by uri v. url
16:58:07 <timeless> dveditz: we have it in report-
16:58:08 <wseltzer> Present+ Peleus_Uhley
16:58:41 <timeless> bhill2: this was raised after CSP 1.0
16:59:10 <timeless> Topic: CSP Issues: ISSUE-37 How to apply plugin-types in CSP 1.1 to iframes
16:59:16 <timeless> mkwst___: the spec covers this
16:59:23 <timeless> bhill2: can you update the tracker and close it?
16:59:25 <timeless> mkwst___: yes
17:00:01 <timeless> Topic: CSP Issues: ISSUE-68 How to manage 401 phishing prompts by subresources
17:00:07 <timeless> bhill2: we just talked about that
17:00:11 <timeless> ... i'll change the status to open
17:00:25 <timeless> Topic: CSP Issues: ISSUE-63: Disposition of ch-csp client hint
17:01:33 <timeless> mkwst___: we change ch-csp to csp to respond to mnot's ...
17:01:52 <bhill2> https://www.w3.org/2011/webappsec/track/issues/pendingreview
17:02:03 <timeless> Topic: CSP Issues: ISSUE-66 No-external-navigation as potential csp3 feature
17:02:04 <bhill2> https://www.w3.org/2011/webappsec/track/issues/56
17:02:09 <timeless> bhill2: v.Next
17:02:31 <timeless> Topic: CSP Issues: ISSUE-56 Should we restrict subsequent navigation within child-src?
17:02:55 <timeless> bhill2: csp-client-hint and unsafe-client-redirect-tokens address this issue
17:02:59 <timeless> ... -> closed
17:03:28 <timeless> Topic: CSP Issues: ISSUE-58: Late binding of CSP policies
17:03:34 <timeless> bhill2: we have text for this
17:03:38 <timeless> ... -> closed
17:03:58 <timeless> Topic: CSP Issues:  ISSUE-59: Figure out how to use CSP appropriately with SVG modes
17:04:00 <bhill2> https://www.w3.org/2011/webappsec/track/issues/59
17:04:06 <timeless> issue-59?
17:04:06 <trackbot> issue-59 -- Figure out how to use CSP appropriately with SVG modes -- pending review
17:04:06 <trackbot> http://www.w3.org/2011/webappsec/track/issues/59
17:04:15 <timeless> bhill2: ... -> closed
17:04:32 <bhill2> https://www.w3.org/2011/webappsec/track/actions/open
17:04:53 <timeless> i|http|Topic: CSP Open Actions|
17:05:13 <bhill2> https://www.w3.org/2011/webappsec/track/actions/174/edit
17:05:26 <timeless> Topic: CSP ACTION-174: Raise frame-ancestors/fetch/neterror on list
17:05:36 <timeless> bhill2: how do we deal with things in CSP that aren't perfect matches
17:05:54 <timeless> ... returning a network error a failure to load because of a frame-ancestors policy
17:06:28 <timeless> ... everywhere else in CSP, it's treated as a parameter to the fetch algorithm
17:06:39 <timeless> ... if my page tries to load an image, and it's blocked by CSP
17:06:45 <timeless> ... it looks like a network error
17:06:54 <timeless> ... for a frame, you load the page first
17:07:05 <timeless> ... do you fire the onerror handler in the parent page
17:07:28 <tanvi> tanvi has joined #webappsec
17:07:32 <timeless> bhill2: if it fails, it's because you shouldn't have access to what's inside
17:07:42 <timeless> ... terri wrote some tests at the hackathon
17:07:53 <timeless> ... @ Test The Web Forward in Portland
17:07:58 <timeless> ... Firefox fires and Chrome does not
17:08:05 <timeless> ... mkwst___ are you ok w/ this language?
17:08:14 <timeless> ... difficulties for Blink?
17:08:25 <timeless> mkwst___: as long as a failed load because of CSP is indistinguishable from
17:08:35 <timeless> ... we had problems w/ the XSF auditor in Chrome
17:08:43 <wseltzer> s/XSF/XSS/
17:08:43 <dveditz> dveditz has joined #webappsec
17:08:55 <timeless> ... you could use the XSS auditor to block the page based on text in the page
17:09:16 <timeless> ... we did work to make XSS loads (success/failure) transparent to the openers
17:09:17 <schuki> schuki has joined #webappsec
17:09:20 <timeless> ... I don't know the text in the spec
17:09:26 <timeless> ... i'll take a quick look at it
17:09:36 <timeless> bhill2: i'll reassign the action to mkwst___
17:10:15 <timeless> mkwst___: doesn't load ...
17:10:19 <timeless> ... we sandbox to a unique origin
17:10:34 <mkwst___> step 3.2 of https://w3c.github.io/webappsec/specs/content-security-policy/#frame-ancestors
17:10:46 <timeless> bhill2: you want to make it indistinguisable
17:10:58 <timeless> mkwst___: that was the justification
17:11:21 <timeless> bhill2: the spec says to act as if you have an empty 200 response
17:11:45 <timeless> mkwst___: if you don't sandbox into a unique origin, then it's possible to determine if it loaded successfully or not
17:11:54 <timeless> ... a same-origin page can be introspected
17:12:10 <timeless> dveditz: if it's same-origin and it was successful
17:12:14 <timeless> ... then you can reach in
17:12:29 <timeless> ... you could test by whether it's sandboxed or not
17:12:38 <timeless> mkwst___: if it's cross-origin, you can't reach in
17:12:46 <timeless> ... if it's an empty response for 200,
17:12:52 <timeless> ... within chrome,
17:13:06 <timeless> ... i had to specifically set the origin of the page to make sure it was explicitly inaccessible
17:13:11 <timeless> bhill2: so an about:blank equivalent
17:13:21 <timeless> ... instead of empty content from that origin
17:13:28 <timeless> mkwst___: that was the context that i ended up w/
17:13:41 <timeless> dveditz: if the intent is to prevent the parent page from knowing if it's blocked on not
17:13:49 <timeless> ... then they can know if they can't reach into the page
17:13:56 <timeless> bhill2: this is for cross-origin pages
17:14:05 <timeless> mkwst___: there's not much we can do about same-origin pages
17:14:27 <timeless> mkwst___: this was the easiest way for me to write "the page should be cross origin"
17:14:38 <timeless> ... i don't care if the implementation actually sandboxes, or not
17:14:49 <timeless> ... what's important is that the page be distinct origin to the parent on failure
17:14:55 <timeless> bhill2: sounds ok to me
17:15:05 <timeless> ... how does it sound to other implementers in the room?
17:15:16 <timeless> terri: hard to test for me
17:15:23 <timeless> bhill2: test that onerror doesn't fire
17:15:29 <timeless> mkwst___: use report-uri
17:15:40 <timeless> terri: makes sense
17:15:53 <timeless> bhill2: i don't here proposals for changing that part of the spec
17:16:02 <timeless> ... can we mark this as closed?
17:16:05 <npdoty> npdoty has joined #webappsec
17:16:17 <timeless> ... punt to make sure our tests ensure implementations are applying the existing spec test?
17:16:20 <timeless> ... -> closed
17:16:39 <timeless> ckerschb: i guess we can do that
17:16:45 <timeless> dveditz: XFrameOptions...
17:16:59 <timeless> ... but presumably that [IETF] should also not
17:17:07 <timeless> ... their spec isn't that detailed
17:17:10 <timeless> bhill2: yeah...
17:17:18 <timeless> ... probably makes sense to do consistently
17:17:27 <timeless> ... the ietf spec doesn't delve into details
17:17:30 <timeless> dveditz: it might
17:18:01 <bhill2> http://tools.ietf.org/html/rfc7034#section-2.3.2.1
17:18:07 <timeless> ... it was designed to describe what was done, not to be prescriptive
17:18:31 <timeless>    Implementations of this vary: some browsers will show a message that
17:18:31 <timeless>    allows the user to safely open the target page in a new window,
17:18:31 <timeless>    whereas other implementations will simply render an empty frame.
17:18:41 <timeless> dveditz: it describes content
17:18:47 <timeless> ... the window would be not-same-origin
17:19:20 <timeless> bhill2: the new window / empty frame will need to be not-same-origin
17:19:50 <bhill2> https://www.w3.org/2011/webappsec/track/actions/191
17:20:02 <timeless> Topic: CSP ACTION-191: Inconsistency in source hash description
17:20:33 <timeless> bhill2: is this a typo?
17:20:40 <timeless> mkwst___: i haven't looked
17:20:50 <timeless> Topic: CSP GitHub issues
17:21:21 <timeless> i/CSP/[ Coffee Break until 10:30 ]/
17:21:24 <timeless> RRSAgent, draft mintues
17:21:24 <RRSAgent> I'm logging. I don't understand 'draft mintues', timeless.  Try /msg RRSAgent help
17:21:27 <timeless> RRSAgent, draft minutes
17:21:27 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html timeless
17:27:06 <ckerschb> ckerschb has joined #webappsec
17:37:03 <deian> deian has joined #webappsec
17:37:45 <npdoty> scribenick: npdoty
17:37:55 <npdoty> bhill2: adding an acknowledgements section. doesn't seem too controversial
17:38:14 <npdoty> mkwst___: if you have any suggestions of people to ack, that would be great
17:38:21 <npdoty> bhill2: Neil, on the script/hash
17:38:31 <npdoty> mkwst___: if we add a section, don't want to miss people
17:39:04 <npdoty> issue a call for acknowledgements, something for the chair to do
17:39:29 <tanvi> tanvi has joined #webappsec
17:39:47 <bhill2> https://github.com/w3c/webappsec/issues/63
17:39:51 <npdoty> many thanks to our previous scribe, who all agree is great
17:40:11 <npdoty> bhill2: for the current milestone?
17:40:21 <npdoty> mkwst___: sure. non-normative, so can add without a problem
17:40:29 <bhill2> https://github.com/w3c/webappsec/issues/49
17:41:01 <npdoty> bhill2: comment was that ABNF for host-part doesn't allow for ipv6 address
17:41:15 <npdoty> ... my response was that this was by design. the origin-based model of security doesn't work very well for ip addresses
17:41:28 <npdoty> ... not the intent. CORS doesn't work for ipv6 addresses as well
17:41:51 <npdoty> rigo: looking forward a number of years, expect a switch to IPv6
17:42:19 <npdoty> ... should at least say if we don't know what to do, so that researchers can look into it
17:42:26 <npdoty> ... note it as a long-term issue
17:42:48 <npdoty> bhill2: an issue for IPv4 as well, even though ABNF can handle it, not a good part of the web security model and origins
17:43:02 <npdoty> ... origins typically more associated with names than with IP addresses
17:43:45 <npdoty> ... should we change the spec to allow specifying IPv6 addresses in the host portion?
17:44:12 <npdoty> rigo: why prohibit it? might want a high-security application to specify a very specific IP address
17:44:32 <npdoty> The Web Origin Concept, https://www.ietf.org/rfc/rfc6454.txt
17:44:59 <bhill2> https://www.ietf.org/rfc/rfc6454.txt
17:45:26 <npdoty> bhill2: Section 7.1 of rfc6454, not sure if it allows an IP address or not
17:46:28 <npdoty> debate over whether 6454 allows for IP address origins (seems like yes)
17:46:39 <npdoty> mkwst___: if we allow ipv4, we should allow ipv6
17:46:50 <npdoty> ... but IP addresses are origins that are difficult to reason about
17:46:52 <npdoty> ... don't feel strongly
17:47:41 <npdoty> ... in Chrome, consider an IP address to be an origin, supports localStorage, etc.
17:47:58 <npdoty> bhill2: no ABNF for host in 6454
17:48:18 <npdoty> ... could reference URI, rather than defining it in CSP
17:48:35 <npdoty> @@: but we specify an algorithm for how to parse it
17:48:47 <npdoty> ... actually, just refers to parts based on URI
17:49:11 <bhill2> http://www.w3.org/TR/CSP2/#host-part
17:49:14 <npdoty> mkwst___: we'd have to change host-part to include both colons and braces (only at beginning and end)
17:49:22 <npdoty> ... making sure it's well-formed would be a little more complicated
17:49:24 <npdoty> ... but not a lot of work
17:49:47 <npdoty> ... currently we allow IPv4 addresses, but don't verify their validity
17:50:01 <npdoty> s/braces/brackets/
17:50:20 <npdoty> bhill2: sense I'm getting is that we should probably do this
17:50:42 <npdoty> @@: split into origin name / IP address
17:50:46 <npdoty> mkwst___: not a very significant change
17:51:00 <npdoty> bhill2: github issue assigned
17:51:22 <puhley> puhley has joined #webappsec
17:51:27 <npdoty> s/@@/dveditz/
17:51:43 <npdoty> dveditz: can you note the security implications of using IP addresses?
17:52:20 <npdoty> mkwst___: result of a bad input here is that something doesn't load, a safe result
17:52:27 <rigo_> rigo_ has joined #webappsec
17:52:31 <colin> colin has joined #webappsec
17:52:42 <npdoty> bhill2: end of our issues across mailing list, tracker and github for CSP2
17:53:03 <npdoty> ... any objections to considering this a satisfactory disposition of Last Call comments by the Working Group?
17:53:08 <npdoty> ... pending action items today
17:53:22 <npdoty> ... any objections to requesting transition of CSP2 to CR?
17:53:36 <npdoty> dveditz: clarification about srcdoc and iframe
17:54:36 <npdoty> ... if framesrc is none, should src doc be loadable or not? could see different outcomes
17:54:52 <npdoty> bhill2: good question.
17:55:02 <npdoty> mkwst___: good question.
17:55:14 <npdoty> ... not sure we have a test for it.
17:56:06 <npdoty> [scribe not quite capturing these details]
17:56:39 <fjh> fjh has joined #webappsec
17:57:36 <npdoty> dveditz: might surprise someone who thinks they're turning off all iframes. but if it's an iframe from the same origin, then there's no change in privileges anyway
17:57:40 <npdoty> bhill2: give a name to the iframe?
17:58:08 <npdoty> bhill2: can you open an issue with the necessary clarifications?
17:58:11 <npdoty> dveditz: yes.
17:59:00 <npdoty> bhill2: that's it for CSP level 2
17:59:10 <npdoty> ... once we wrap up these issues, hear no objections to advance to CR
17:59:17 <bhill2> TOPIC: Content Security Policy v 1.0 to Note
17:59:34 <npdoty> bhill2: take CSP 1.0 to WG Note status, once CSP 2 is at CR
17:59:49 <npdoty> ... currently we have two CSP documents on Recommendation-track
17:59:59 <npdoty> ... main issue for advancement will be development of a test suite
18:00:00 <JingwangQi> JingwangQi has joined #webappsec
18:00:18 <npdoty> ... very limited overlap. several implementations will be working on CSP 2 compatibility
18:00:28 <npdoty> ... don't see a strong case for continuing effort on CSP 1
18:00:42 <npdoty> ... call for retiring CSP 1, moving it to Note status
18:00:54 <npdoty> ... received assent on the mailing list. want to confirm here
18:01:26 <npdoty> dveditz: concern is what people use specs for.
18:01:34 <npdoty> ... would take longer to get CSP 2 fully implemented/tested
18:01:46 <npdoty> ... authors unlikely to care about the difference between Note and Rec
18:01:56 <Kevin_Hill> Kevin_Hill has joined #webappsec
18:02:10 <npdoty> @@@: working on WebPlatform docs. would be glad to help document the differences
18:02:29 <npdoty> ... as a developer recommendation
18:02:43 <npdoty> bhill2: which do we want to encourage developers to use?
18:02:57 <npdoty> @@@: as a developer, I'm not sure which one I should be using, especially regarding frame- options
18:03:19 <npdoty> mkwst___: CSP2 options are behind a compatibility flag for Chrome beta/stable
18:03:49 <npdoty> bhill2: a few things are different, like handling of blobs. breaking changes for things that were underspecified and so implemented in non-interoperable ways
18:04:22 <npdoty> ... clearly want people to abandon the old use cases in those
18:04:36 <npdoty> ... any objections to this call for consensus?
18:04:57 <npdoty> resolved: as of advancement of CSP2 to CR, WG will request that CSP1 move to WG Note
18:05:35 <npdoty> Topic: next topics
18:05:53 <npdoty> bhill2: lunch break. didn't get to the other documents topics
18:06:12 <marcosc> marcosc has joined #webappsec
18:06:34 <timeless> Zakim, who is here?
18:06:34 <Zakim> On the phone I see Salon3, mkwst
18:06:35 <Zakim> Salon3 has bhill2, wseltzer, Renoir, wseltzer, rigo, Takeda, terri, timeless, ckerschb, Kevin_Hill, Wei_Xiaohai, Colin_Whorlow, fjh, Jing_Wang_Qi, dveditz
18:06:35 <Zakim> On IRC I see marcosc, Kevin_Hill, JingwangQi, fjh, colin, rigo, puhley, tanvi, deian, ckerschb, npdoty, schuki, dveditz, gludi|2, anssik, glenn, keiji, wei_james, Josh_Soref,
18:06:35 <Zakim> ... Zakim, RRSAgent, bhill2, tobie, timeless, mkwst___, freddyb, renoirb, terri, wseltzer, trackbot
18:06:55 <timeless> Zakim, timeless has left Salon3
18:06:55 <Zakim> -timeless; got it
18:07:24 <npdoty> can talk about MIX etc. from 13:00 to 14:00
18:07:25 <npdoty> updating agenda
18:07:37 <npdoty> reconvene at 13:00, for an hour, before Web Security Interest Group
18:07:57 <npdoty> after that, 15:15, rechartering discussions
18:08:03 <Zakim> -mkwst
18:08:05 <npdoty> rrsagent, draft minutes
18:08:05 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html npdoty
18:09:44 <npdoty> i/Topic: Introductions/scribenick: timeless/
18:09:48 <npdoty> rrsagent, draft minutes
18:09:48 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/27-webappsec-minutes.html npdoty
18:11:05 <Zakim> -Salon3
18:11:05 <Zakim> SEC_WASWG()11:30AM has ended
18:11:05 <Zakim> Attendees were bhill2, wseltzer, Renoir, rigo, Takeda, terri, timeless, ckerschb, Kevin_Hill, Wei_Xiaohai, Colin_Whorlow, fjh, Jing_Wang_Qi, mkwst, tanvi, dveditz
18:14:03 <colin> quit
18:21:42 <puhley> puhley has joined #webappsec
18:30:32 <puhley> puhley has joined #webappsec
18:36:04 <gludi|2> gludi|2 has joined #webappsec
18:43:18 <deian> deian has joined #webappsec
18:47:35 <dveditz> dveditz has joined #webappsec
19:01:27 <timeless> s/quit//
19:01:34 <RRSAgent> I'm logging. I don't understand 'this meeting spans midnight <- if you want a single log for the two days', timeless.  Try /msg RRSAgent help
19:01:51 <dveditz_> dveditz_ has joined #webappsec
19:07:38 <dveditz> dveditz has joined #webappsec
19:34:39 <puhley> puhley has joined #webappsec
19:41:47 <puhley> puhley has joined #webappsec
19:59:54 <Zakim> SEC_WASWG()11:30AM has now started
20:00:02 <Zakim> +mkwst
20:00:33 <tanvi> tanvi has joined #webappsec
20:00:58 <npdoty> npdoty has joined #webappsec
20:02:52 <ckerschb> ckerschb has joined #webappsec
20:03:59 <Zakim> + +1.408.988.aaaa
20:04:07 <dveditz> dveditz has joined #webappsec
20:04:13 <bhill2> bhill2 has joined #webappsec
20:06:12 <JeffH> JeffH has joined #webappsec
20:06:28 <deian> deian has joined #webappsec
20:06:48 <JeffH> brad(bh): user interface sec: completed last call, waiting on implementations
20:07:09 <JeffH> bh: what should we do with this spec?  Rec track, or Note ?
20:07:27 <JeffH> bh: strong interest in this from Paypal and FB and perhaps other properties
20:08:01 <Jingwang_qi> Jingwang_qi has joined #webappsec
20:08:15 <JeffH> tanvi: we Moz haven't talked about it
20:08:29 <JeffH> dveditz: is on backburner, no consensus on it
20:09:38 <ckerschb_> ckerschb_ has joined #webappsec
20:09:56 <JeffH> bh: just rreying to get sense of whehter issues are "we're just busy/queue is long" or whether " we don't want it to happen" -- eg if FB threw $ at it and it got impl'd would that be a problem?
20:10:23 <JeffH> dveditz: dunno....if someone shows up with resources then is ok?
20:10:53 <JeffH> bh: as long as there isn't pricipled opposition.....we keep it in charter?
20:11:10 <JeffH> ques for Mike West (mw):  any opposition?
20:11:37 <JeffH> mw: some issues in compositer in blink - dunno what status of that is or details?
20:12:20 <JeffH> bh: sounds like not pricipled opposition == so keep in charter discussion
20:12:35 <JeffH> bh: next referrer policy -- seems we're closer on that?
20:13:24 <JeffH> mw:  going to LC at some point here, but need to talk about mixed content first cuz of testing issues
20:13:52 <wei_james> wei_james has joined #webappsec
20:14:02 <JeffH> mw: if we're just talking about ghoing from WD to CR, then we don't have to worry about Fetch(), so for referrer policy we
20:14:36 <JeffH> are closer to haveing worked out what fetch() needs to return ... don't think it'll take months & months to work out.
20:14:48 <JeffH> bh: end of Jan-2015 LC ?
20:14:53 <JeffH> mw: yeah, that's fine.
20:16:02 <JeffH> bh: MX (mixed content) has some open issues, what do we do with the spec parts that talk about treating of local content -- shuold that be
20:17:00 <JeffH> part of MX or some other thing.....ie public / private division?  eg 'don't let resources fetched from Internet query things on the local net'  -- but that's broken some use cases
20:18:41 <JeffH> mw: i'm fine with bringing out the pub/priv distinct into sep doc(?), but its prob a good idea of thinking about how to expose IoT critters to the larger web -- we need to get something on paper for how to do this -- MX perhaps isn't the place -- so lets breakout pub/priv from MX, and leave room in chartering discussoin to have pub/priv in the chargter
20:19:56 <JeffH> dved: pub/priv distinct is easier to make in IPv4 world, but less do-able in IPv6 world -- and in IoT world, you'll have things on you home nets that are never updated and so exposing to internet will be an issue
20:20:20 <JeffH> mw: well, it's a prob we want to solve, and would like this group to try to figure it out.
20:20:33 <JeffH> bh: created action 196 for MW to make this change to MX
20:21:12 <JeffH> mw: with pub/priv removed, don't think there's anything left that's not substantially controversial.  TAG had nits on it.
20:21:40 <JeffH> tanvi: MX checks are after HSTS checks, but that isn't case in chrome, and can be changed in FF.
20:23:31 <bhill2> ?
20:23:38 <bhill2> is jeffh still connected?
20:23:49 <deian> deian has joined #webappsec
20:23:57 <JeffH> mw: hsts should happed after HSTS.....two sides #1: mx shd happen before HSTS cuz that shows dvloprs soething broken, and there's brwosers that don't support HSTS.  (2) HSTS is an expression from dvlpr that they want the site to be secure all the time, so the arg is we shud not treat those origins as mx cuz there's
20:24:27 <JeffH> not a net request out over unsecure connections for those origins
20:24:31 <Kevin_Hill> Kevin_Hill has joined #webappsec
20:24:52 <JeffH> tanvi: maybe we should leave this out of this spec (MX)?
20:25:04 <JeffH> mw: can do that, but the fetch() spec will need to account for it
20:26:26 <JeffH> mw: depends on who i'm talking to can see both args -- until all bwrs support STS, dvlprs need to know their sites are not secure, so for now have MX ahead in eval of STS,  later can move it MX behind STS eval
20:26:36 <JeffH> tanvi: can go either way
20:30:07 <JeffH> brad: at FB they are painfully aware that there's a LONG tail behind the "big 5" browsers -- so we should had MX warnings fire, even if you're enforcing STS
20:30:35 <JeffH> "lots of folks in world going without a safety net..."
20:31:50 <JeffH> mw: https everywhere (HE) is special case -- we need to get up into the extension and get an answer and then figure out hwat to do whith it -- so so
20:32:25 <JeffH> don't think should be in the spec -- in chrome we've agreed HE should work but we havnt done the work yet
20:32:33 <JeffH> tanvi: FF is in similar situation wrt HE
20:33:13 <JeffH> bh: end of Jan 2015 MX last call ?
20:33:16 <JeffH> mw: sure
20:34:56 <JeffH> mw: not sure if fetch() is going to be a prob -- mx and referrer policy are fairly integrated with fetch(), RP has algs that fetch is supposed to call into, and if that doesn't happen we have issues
20:35:39 <JeffH> bh: do we take to AC the topic of "making WhatWG specs 'referenceable' from W3C specs ?"
20:36:39 <JeffH> wendys (ws): issues underdiscsussion around that eg making normative references from w3c specs to whatwg -- there's experience from html5 wg that perhaps we can draw on
20:36:58 <JeffH> bh: do an ad-hoc this week and talk with Robin and maybe Tim?    ws: yes....
20:41:00 <wseltzer> https://www.surveymonkey.com/s/8VPQT7J
20:41:29 <dveditz_> dveditz_ has joined #webappsec
20:43:00 <npdoty> npdoty has joined #webappsec
20:46:43 <gmaone> gmaone has joined #webappsec
20:48:22 <deian> deian has joined #webappsec
20:54:03 <hadleybeeman> hadleybeeman has joined #webappsec
20:54:51 <wseltzer> [We're waiting for the WebSec IG informal meeting, starting at 1400 local time]
20:57:38 <JeffH> JeffH has joined #webappsec
21:01:45 <keiji> keiji has joined #webappsec
21:03:18 <glenn> glenn has joined #webappsec
21:05:17 <fjh> fjh has joined #webappsec
21:05:36 <hadleybeeman> hadleybeeman has left #webappsec
21:05:42 <fjh> fjh has joined #webappsec
21:05:53 <fjh> fjh has joined #webappsec
21:06:35 <dveditz> dveditz has joined #webappsec
21:06:56 <Zakim> - +1.408.988.aaaa
21:07:22 <glenn_> glenn_ has joined #webappsec
21:10:05 <QiJingwang> QiJingwang has joined #webappsec
21:11:07 <fjh> zakim, who is here?
21:11:09 <Zakim> On the phone I see mkwst
21:11:09 <Zakim> On IRC I see QiJingwang, glenn_, dveditz, fjh, glenn, keiji, JeffH, deian, npdoty, dveditz_, Kevin_Hill, wei_james, ckerschb, Jingwang_qi, bhill2, tanvi, puhley, schuki, anssik,
21:11:09 <Zakim> ... Josh_Soref, Zakim, RRSAgent, tobie, timeless, mkwst___, freddyb, renoirb, terri, wseltzer, trackbot
21:11:25 <gludi|2> gludi|2 has joined #webappsec
21:11:26 <tanvi> we are in #websec
21:11:27 <wseltzer> [WebSec IG discussion in #websec for the next hour]
21:51:42 <fjh> fjh has joined #webappsec
22:01:01 <weijames> weijames has joined #webappsec
22:02:59 <gludi|2> gludi|2 has joined #webappsec
22:03:31 <weijames_> weijames_ has joined #webappsec
22:07:19 <gludi|43> gludi|43 has joined #webappsec
22:09:48 <bhill2> bhill2 has joined #webappsec
22:10:09 <QIJINGWANG> QIJINGWANG has joined #webappsec
22:16:48 <bhill2> zakim, room for 4
22:16:48 <Zakim> I don't understand 'room for 4', bhill2
22:17:00 <bhill2> folks, we're having trouble with the zakim dialin
22:17:06 <bhill2> I have a ticket in to sysreq
22:17:38 <bhill2> zakim, room for 4?
22:17:39 <Zakim> ok, bhill2; conference Team_(webappsec)22:17Z scheduled with code 92794 (WASWG) for 60 minutes until 2317Z
22:17:42 <tanvi> tanvi has joined #webappsec
22:18:11 <mkwst___> :/
22:18:25 <dveditz> Zakim: you lie
22:18:43 <bhill2> join us in david ross's hangout
22:18:43 <bhill2> https://plus.google.com/hangouts/_/google.com/drx-hillbrad
22:20:00 <Zakim> disconnecting the lone participant, mkwst, in SEC_WASWG()11:30AM
22:20:01 <Zakim> SEC_WASWG()11:30AM has ended
22:20:01 <Zakim> Attendees were mkwst, +1.408.988.aaaa
22:21:27 <Zakim> Team_(webappsec)22:17Z has now started
22:21:34 <Zakim> + +1.408.988.aaaa
22:22:32 <bhill2> you might want to be on both, mike, for david's slides at 30 after the hour
22:22:56 <Zakim> +mkwst
22:23:42 <jeff> jeff has joined #webappsec
22:24:46 <dveditz> RRSAgent: Scribe: Daniel Veditz
22:24:46 <RRSAgent> I'm logging. I don't understand 'Scribe: Daniel Veditz', dveditz.  Try /msg RRSAgent help
22:24:47 <bhill2> https://www.surveymonkey.com/analyze/3qMVUxph8E9HsdkPaLIpt8Y1Q05CYO9iStlWC7eWDAY_3D
22:24:55 <bhill2> let's look over results of survey so far
22:24:59 <dveditz> Scribe: Daniel Veditz
22:25:04 <dveditz> scribenick: dveditz
22:25:26 <mkwst___> bhill2: the result link is tied to your account.
22:25:31 <dveditz> bhill2: 13 people responded to the survey
22:25:55 <dveditz> 11/13 thought credential management was a good thing to work on, 1 did not
22:26:10 <dveditz> 7/13 say yes to write-only form elements
22:26:23 <dveditz> 3/13 say we should NOT work on it
22:26:42 <dveditz> 7/11 say yes to MIME sniffing, 2/11 say no
22:28:14 <dveditz> can you see the screen now, mkwst___ /
22:28:16 <dveditz> ?
22:28:42 <mkwst___> dveditz: yes. but I can't mute/unmute the hangouts independently. :/
22:28:48 <mkwst___> dveditz: so I'm just muted now.
22:29:05 <dveditz> bhill2: Csp level 3 features has unanimous support
22:29:28 <dveditz> ... secure-only child browsing context has 7 supporting
22:29:46 <dveditz> ... additional cookie data 7 for, 2 opposed
22:30:55 <dveditz> ... gut feel is we need to prune this to a couple items, not 10 -- and we're going to add more tomorrow
22:30:56 <Zakim> + +1.425.830.aabb
22:31:20 <dveditz> ... but we need people to work on things (other than mkwst___ -- unrealistic that he sign up for everything)
22:31:38 <dveditz> davidross joins the call
22:31:45 <wseltzer> zakim, aabb is davidross
22:31:45 <Zakim> +davidross; got it
22:32:31 <dveditz> TOPIC: Entry Point Regulation proposal
22:33:22 <dveditz> davidross: introducing ERP, pulled together a prototype chrome extension
22:33:56 <dveditz> ... inspiration from charlie reis et al paper (App Isolation)
22:33:57 <JeffH> http://randomdross.blogspot.com/2014/08/entry-point-regulation-for-web-apps.html
22:34:14 <JeffH> https://github.com/google/epr
22:34:16 <dveditz> ... premise: apps are fundamentally less vulnerable to xss and xsrf than web apps
22:34:40 <dveditz> ... why? 1) too many potential entry points to web apps
22:35:03 <dveditz> ... mobile apps declare their front doors
22:35:17 <dveditz> ... can think of this as a bug in the web platform, maybe we can fix this
22:35:43 <JeffH> link to preso ?
22:36:34 <dveditz> ... complementary to CSP. CSP can be problematic if a library requires unsafe-eval. EPR attacks injection from a different angle
22:38:38 <dveditz> ... Architecture: per site manifests that list entry points. cross-origin requests to other  urls get redirected
22:39:01 <dveditz> ... X-EPR http header indicates EPR support
22:39:16 <dveditz> ... implemented to avoid spamming sites with manifest requests
22:39:32 <Kevin_Hill> Kevin_Hill has joined #webappsec
22:39:33 <dveditz> ... has a first-use problem like HSTS
22:40:30 <dveditz> ... Csrf is probably Ok because we will have made the first request before the use is actually authenticated, so limits attack possibilities
22:40:56 <dveditz> ... manifests are cached for a certain period of time
22:41:21 <dveditz> ... X-epr can be enhanced in the future to permit based on paths
22:41:38 <dveditz> ... manifest entries: simple path strings or regexp
22:41:54 <dveditz> ... navigation type (stylesheet, document, script, etc)
22:42:08 <dveditz> ... whether data is supported (post, query string, hash)
22:42:14 <dveditz> ... maybe others? but simpler is better
22:43:11 <dveditz> ... analysis of recent xss vulns: 20 of identified issues likely mitigated by an implementation of EPR
22:43:33 <dveditz> s/20/20%/
22:44:00 <dveditz> ... status: open source, up on github. there's a blog and a mailing list
22:44:01 <tanvi> blog link?
22:44:24 <wseltzer> http://randomdross.blogspot.com/2014/08/entry-point-regulation-for-web-apps.html
22:44:42 <dveditz> ... future? manifest generation tools, standardization (maybe as part of web app manifests), implementation in browsers?
22:44:53 <tanvi> thanks wseltzer
22:45:14 <JeffH> blog link up above also along with github link
22:45:20 <dveditz> ... that's about it. here's an example of a sample manifest [on screen]
22:45:58 <wseltzer> q?
22:46:34 <dveditz> bhill2: couple questions. there's a number of trends going on, web apps specifying manifests....
22:46:52 <dveditz> ... are you familiar with app links? http://applinks.org
22:47:24 <dveditz> ... creates deep links into apps (i.e. LESS regulated entry points)
22:47:59 <dveditz> ... if you're doing a single page app only certain transitions are available which might mitigate some of the same concerns
22:48:18 <dveditz> davidross: yeah, i see this more for the vast array of legacy style apps
22:48:35 <dveditz> ... maybe not single-page apps, but I don't know how much of the web is moving that way
22:49:12 <dveditz> bhill2: there are application designs that mitigate these risks at the design level
22:49:26 <jin> jin has joined #webappsec
22:49:29 <dveditz> davidross: <someone at MS> found that this was difficult to do in practice
22:49:54 <dveditz> bhill2: what's the behavior if I go somewhere that's not allowed by these manifests?
22:50:32 <dveditz> davidross: undefined in the spec currently, might block, might allow through unauthenticated... I don't know what makes sense
22:50:44 <dveditz> ... could redirect to a standard error page provided in the manifest
22:50:51 <dveditz> bhill2: have you thought about abuse cases?
22:51:13 <dveditz> ... deep linking is part tof what makes the web awesome. There's always been tension around deep linking
22:51:35 <dveditz> davidross: I've heard that feedback. if you're a site opperator there's already ways for you to do that
22:51:45 <dveditz> ... XFO is one way to limit things
22:52:06 <dveditz> ... if the whole web moved to this model then yes, this would restrict some freedom
22:52:33 <dveditz> ... but in the case of a web console you wouldn't want people to navigate into a state that wasn't supported
22:53:09 <dveditz> ... another example is the app platform, you'd want EPR to limit access but not nececssarily on the open web
22:53:38 <dveditz> terri: I worked on a similar idea in an academic context and we were concerned about the size of the manifest
22:53:54 <rigo> rigo has joined #webappsec
22:54:16 <dveditz> davidross: shouldn't be over a megabyte even for a complex site.  wouldn't send as a header, and it's largely cacheable
22:54:32 <dveditz> Kevin_Hill: concern about download size on mobile
22:54:49 <dveditz> davidross: if it's just a list of URLs it wouldn't need to be that large
22:55:06 <dveditz> bhill2: ???
22:55:29 <bhill2> question was if manifest was origin-granularity or arbitrary based on what resource opts into?
22:55:30 <dveditz> davidross: you could adapt it to apply only to pages under a certain path, not affecting the rest of the site
22:56:00 <dveditz> terri: was performance affected in a noticeable way?
22:56:20 <dveditz> davidross: didn't notice a performance impact, other than the hit of downloading the initial manifest
22:56:50 <dveditz> terri: yes, we did that and found a 30% perf hit if it was synchronous load and no caching
22:57:29 <dveditz> davidross: we could define it asynchronously and say "best effort" on initial hit
22:57:33 <dveditz> bhill2: preload list in chrome?
22:57:36 <dveditz> ... joking
22:58:06 <dveditz> terri: I'm excited about this if we can make it work, disappointed we couldn't make it work in our academic context
22:58:35 <dveditz> tanvi: can we talk about the details of the manifest, what the capabilities are/
22:58:47 <dveditz> s/\//?/
22:59:21 <terri> HTML version of the academic paper in question: http://terri.zone12.com/doc/academic/soma/
22:59:53 <dveditz> github exampe manifest
23:00:05 <terri> pdf version (although I'm guessing no one here would prefer it): http://terri.zone12.com/doc/academic/oda-ccs-08.pdf
23:00:35 <dveditz> davidross: site, how long to cache, reportUrl for errors like CSP
23:01:00 <dveditz> ... defaultResBehavior -- that's any resource that's not navigating a browser (images, styles, etc)
23:02:21 <dveditz> ... rules are paths and regexp and what to do with them. first one is the path "/" and applies to "navigations" -- anyone can navigate it. "allowData" false means any query string will will be blocked
23:02:58 <dveditz> ... regexp "^/\\d+$" allows navigation to numeric pages
23:03:42 <dveditz> ... then an example of an OR regexp of paths not to allow navigation to
23:03:49 <JeffH> see also: ABE - Application Boundaries Enforcer  http://noscript.net/abe/
23:04:28 <dveditz> bhill2:  how does this map to the web app manifest spec?
23:04:49 <JeffH> https://w3c.github.io/manifest/ <--- is this what BHill was mentioning?
23:05:04 <dveditz> @@: was talking to them last night and the difference sounds like EPR is a site scope
23:05:18 <bhill2> https://github.com/w3c/manifest
23:05:44 <wseltzer> s/@@:/mnot:/
23:06:27 <dveditz> JeffH: there are lots of examples like this, ABE for example.
23:07:00 <dveditz> bhill2: is this something you [jeffh], terri and david could research and determine where this work should take place
23:07:23 <dveditz> terri: my gut feel is this should happen here because I don't think they have the security expertise there
23:07:52 <dveditz> bhill2: we can add security expertise to those groups if it's easier to get into a release track in another place
23:08:17 <dveditz> bhill2: what do you think about that, david?
23:08:40 <dveditz> davidross: yeah, sure, sounds good.  Need your contact information
23:08:46 <bhill2> q?
23:09:14 <fjh> fjh has joined #webappsec
23:09:33 <dveditz> bhill2: thanks very much david. next steps are to make sure you and terri get hooked up and maybe you can get back to us next monday on our regularly scheduled WASWG teleconf
23:09:45 <Zakim> -davidross
23:09:55 <dveditz> davidross: I will follow up with terri, sounds good
23:10:37 <dveditz> bhill2: adding another soapbox -- we need to think about what we do with bookmarklets
23:10:52 <dveditz> ... CSP has broken them, not entirely with intent, but has no plans to fix them
23:11:30 <dveditz> ... we do have a priority of consituancies, and although bookmarklets are an imperfect technology they have been around for 20 years
23:11:41 <dveditz> ... and in many browsers are the only extension point
23:11:55 <dveditz> ... it's a shame we're breaking them and not providing an alternative
23:12:17 <dveditz> ... "go write an extension", but those are diverse, different in every browser, even between chrome and mobile chrome
23:12:40 <dveditz> ... let's see if there's something we can do to revive this concept to restore the user's choice
23:13:29 <jeff> jeff has joined #webappsec
23:14:44 <wseltzer> dveditz: it would be simple to add support for bookmarklets, but what do we do when the bookmarklet adds resources to the page?
23:15:13 <wseltzer> ... unless we made a switch "apply bookmarklet or CSP"
23:15:43 <wseltzer> bhill2: would you put up a dialog?
23:16:01 <wseltzer> dveditz: UX folks wouldn't like that
23:16:32 <wseltzer> ... some way to say "yes, this is a bookmarklet"
23:16:35 <wseltzer> +1 to bookmarklets
23:17:41 <wseltzer> q+
23:17:56 <dveditz> mkwst___: we're doin work in chrome to make bookmarklets work. the bookmarklet script itself works, but if it tries to add 3rd party scripts then those break
23:18:04 <bhill2> ack wseltzer
23:18:34 <dveditz> wseltzer: I share your concern about making user's bookmarklets work
23:19:17 <dveditz> ... if I want to delegate my security to a bookmarklet then I should be able to do that, even to a 3rd party script
23:19:38 <rigo> q+
23:20:09 <dveditz> bhill2: I've seen this at conferences where bookmarklets are an entrypoint for users learning to hack the web
23:20:33 <dveditz> bhill2: can't do gigantic stuff, but simple tweaks don't need to be in a heavyweight extension
23:21:09 <dveditz> mkwst___: I think your proposal would be to have an api to launch bookmarklets
23:21:50 <dveditz> ... if you built an extension whose purpose was to launch bookmarklets (like greasemonkey) then you could play around with the spec because we allow extensions to do more than bookmarklets
23:22:17 <dveditz> bhill2: I'd prefer bookmarklets because they aren't tied to a particular browser's implementation
23:22:33 <dveditz> mkwst___: I'm agreeing with you, I'm saying this is a way you could test this out today in chrome
23:22:57 <dveditz> terri: or let people modify the site's CSP to include things they trust?
23:23:48 <dveditz> @@: seen this again and again... we have a technology and then we get pushback because we didn't take user's concerns seriously
23:24:06 <dveditz> ... does CSp serve the user or control the user?
23:24:24 <rigo> s/@@/rigo/
23:24:51 <dveditz> Kevin_Hill: curious to get some data from the IE team about how prevalent bookmarklets are
23:25:23 <dveditz> bhill2: one of the guys upset about this is the guy who wrote instapaper -- more popular than sites that use CSP
23:25:44 <rigo> I particularly see parallels to TCG if security policy is used to control the user (can't do bookmarklet anymore)
23:26:16 <dveditz> bhill2: let's take it back to the list
23:26:20 <bhill2> ACTION bhill2 to take bookmarklets discussion back to the list
23:26:20 <rigo> and fear pushback because of suspicion that CSP will be used to lock the user
23:26:20 <trackbot> Created ACTION-198 - Take bookmarklets discussion back to the list [on Brad Hill - due 2014-11-03].
23:27:09 <bhill2> dveditz: bookmarklets that import lots of 3rd party code can be bad if that behavior changes
23:28:46 <dveditz> bhill2: according to the original agenda we've got another hour
23:28:52 <colin> colin has joined #webappsec
23:29:16 <dveditz> ... do we want to go through some of these now or do it in the morning/
23:30:44 <dveditz> ... secure introduction of internet-connected things: user friendly pairing. got 4 'noes" , "big hairball, need IoT people in the room"
23:31:04 <dveditz> wseltzer: there is an IoT WG starting to gather
23:31:13 <dveditz> bhill2: shall we prune this one?