19:47:16 <RRSAgent> RRSAgent has joined #webappsec
19:47:16 <RRSAgent> logging to http://www.w3.org/2015/11/16-webappsec-irc
19:47:18 <trackbot> RRSAgent, make logs world
19:47:18 <Zakim> Zakim has joined #webappsec
19:47:20 <trackbot> Zakim, this will be WASWG
19:47:20 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
19:47:21 <trackbot> Meeting: Web Application Security Working Group Teleconference
19:47:21 <trackbot> Date: 16 November 2015
19:52:45 <wseltzer> regrets+ wseltzer
19:53:16 <wseltzer> wseltzer has changed the topic to: Agenda Nov 16: https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0054.html
19:53:55 <bhill2> bhill2 has joined #webappsec
19:57:36 <gmaone> gmaone has joined #webappsec
19:59:37 <tanvi> tanvi has joined #webappsec
20:00:01 <jww> jww has joined #webappsec
20:00:01 <mkwst> present+ mkwst
20:00:20 <ckerschb> ckerschb has joined #webappsec
20:00:36 <gmaone> present+ gmaone
20:00:45 <jww> present+ jww
20:01:23 <ckerschb> present+ ckerschb
20:02:25 <tanvi> present+ tanvi
20:02:30 <bhill2> bhill2 has changed the topic to: https://lists.w3.org/Archives/Public/public-webappsec/
20:02:55 <bhill2> bhill2 has changed the topic to: https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0051.html
20:03:12 <bhill2> Meeting: WebAppSec Teleconference 16-Nov-2015
20:03:12 <Josh_Soref> present+ Josh_Soref
20:03:14 <dveditz> present+ dveditz
20:03:17 <bhill2> Chairs: bhill2, dveditz
20:03:36 <bhill2> present+ Brad Hill
20:03:53 <francois> present+ francois
20:03:56 <timeless> q+ to note that I've sent some feedback and will be sending a bit more about things that were sent to CR (sorry about the delay)
20:04:37 <bhill2> ack timeless
20:04:37 <Zakim> timeless, you wanted to note that I've sent some feedback and will be sending a bit more about things that were sent to CR (sorry about the delay)
20:05:53 <bhill2> scribenick mkwst
20:06:04 <bhill2> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0051.html
20:06:23 <mkwst> bhill2: Agenda bashing. Anything anyone wants to add?
20:06:32 <bhill2> TOPIC: Minutes approval
20:06:34 <mkwst> everyone: <silence>
20:06:34 <dveditz> both timeless _and_ Josh_Soref are here?
20:06:42 <bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-10-28-webappsec-minutes.html
20:06:42 <bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-10-29-webappsec-minutes.html
20:06:45 <mkwst> bhill2: Minutes from TPAC.
20:06:51 <RobTrace> RobTrace has joined #webappsec
20:06:57 <timeless> s/both timeless _and_ Josh_Soref are here?/
20:07:03 <mkwst> bhill2: Objections?
20:07:04 <timeless> s/present+ Josh_Soref/present+ timeless/
20:07:17 <mkwst> dveditz: No.
20:07:28 <mkwst> bhill2: No objection. Minutes approved.
20:07:29 <bhill2> TOPIC: News
20:07:30 <dveditz> er, "none" is better I guess
20:07:38 <dveditz> less ambiguous
20:07:43 <mkwst> bhill2: SRI -> CR.
20:07:50 <mkwst> bhill2: Congratulations!
20:08:05 <mkwst> bhill2: Believe we've satisfied all criteria to have smooth sailing to REC.
20:08:13 <mkwst> bhill2: 4 week comment period for CR.
20:08:19 <mkwst> bhill2: Will try to keep on schedule.
20:08:33 <mkwst> dveditz: Is PR the last step before REC?
20:08:49 <mkwst> bhill2: CR -> PR -> membership vote (AC) -> REC
20:09:10 <devd> devd has joined #webappsec
20:09:10 <puhley> puhley has joined #webappsec
20:09:12 <mkwst> dveditz: Ok, so this group takes it to PR, then lobbies to get to REC?
20:09:15 <mkwst> bhill2: Yup.
20:09:34 <mkwst> francois: Is it worth focusing on test suite to make sure we're happy with it?
20:09:44 <mkwst> bhill2: Having a good test suite is always a good thing.
20:10:00 <mkwst> ... Think it's unlikely that incremental improvements would make anyone vote for it.
20:10:33 <mkwst> ... Don't think it's on the critical path, but if you think something's lacking, then certainly add tests rather than add errata later.
20:10:53 <bhill2> TOPIC: New call time
20:10:59 <bhill2> http://doodle.com/poll/75bif7nd3cuyfqis
20:11:02 <mkwst> bhill2: Sent out a Doodle poll.
20:11:14 <mkwst> ... Will give folks here on the call a few minutes if you want to fill it out right now.
20:11:27 <mkwst> ... Looks like the leading times are 9:00 PST Tuesday or Wednesday.
20:11:53 <mkwst> ... Will be nice to move things into the European workday.
20:12:09 <mkwst> ... I had listed Tuesday as "If need be", but looking at my calendar, that's pretty bad actually.
20:12:22 <mkwst> ... Wednesday will work better for me.
20:12:34 <mkwst> ... How horrible are the "If need be" folks on Wednesday?
20:12:54 <mkwst> dveditz: Related to commuting.
20:13:03 <mkwst> jww: Not great, but not _terrible_.
20:13:28 <mkwst> francois: Fine with Wednesday.
20:13:39 <devd> I would prefer Tuesday
20:13:50 <mkwst> bhill2: Tuesday is officially in the lead, but if I edit my answer...
20:13:57 <mkwst> ... Should we go with Wednesday?
20:14:09 <mkwst> ... Hearing no objection, going with Wednesday.
20:14:22 <mkwst> ... If that turns out to be bad, we could alternate every other call.
20:14:27 <mkwst> ... I'll adjust the calendar.
20:14:33 <bhill2> TOPIC: Suborigins
20:15:26 <mkwst> tanvi: When's the next call? December 2nd at 9am?
20:15:33 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0037.html
20:15:34 <mkwst> bhill2: Looks right. Also, there's a calendar on the group homepage.
20:15:49 <mkwst> bhill2: jww, want to talk about suborigins?
20:15:55 <timeless> RRSAgent, draft minutes
20:15:55 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
20:15:57 <mkwst> jww: I sent something to the list, got some response.
20:16:12 <timeless> RRSAgent, make logs world
20:16:15 <timeless> RRSAgent, draft minutes
20:16:15 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
20:16:25 <dveditz> calendar and other good stuff: http://www.w3.org/2011/webappsec/
20:16:31 <mkwst> ... Suborigins gives servers the ability to add a namespace for a response that puts the response in a new origin in addition to scheme/host/port.
20:16:41 <timeless> s/scribenick mkwst//
20:16:47 <mkwst> ... Respond with `suborigin: foobar`, now you're in scheme/host/port/foobar
20:16:54 <mkwst> ... Experimenting with some ideas in Chrome.
20:17:00 <mkwst> ... Latest updates:
20:17:28 <mkwst> ... 1. XHR and Fetch would need a preflight on all requests from a suborigin because a suborigin can't know what suborigin the endpoint is in until the response comes in.
20:17:38 <mkwst> ... (Should we go over these one by one, or quick summary?)
20:17:44 <mkwst> bhill2: Inclined to pause for questions.
20:17:51 <mkwst> jww: Ok. Let's pause.
20:18:06 <mkwst> devd: Preflights. I don't understand why we insist on a preflight?
20:18:14 <mkwst> ... Why not avoid preflight for simple requests?
20:18:23 <mkwst> jww: That sounds reasonable.
20:18:36 <bhill2> mkwst: that's what I thought we agreed on
20:18:50 <mkwst> jww: Great. Let's do that instead!
20:19:02 <mkwst> dveditz: Suborigins have to be treated like origins, but not worse, right?
20:19:06 <mkwst> devd: Right.
20:19:10 <mkwst> jww: Right.
20:19:22 <mkwst> dveditz: Except that the CORS server needs to ack the suborigin.
20:19:36 <mkwst> jww: Right, there would be a CORS header for suborigin, just like origin.
20:19:57 <mkwst> ... For `postMessage`, by default the suborigin would be serialized into the origin field, but would create a...
20:20:02 <mkwst> devd: Wait, go back to 1.
20:20:13 <mkwst> ... Something about a * response in the CORS header.
20:20:24 <mkwst> ... * doesn't work with credentials.
20:20:41 <mkwst> ... How is that going to work with suborigins?
20:20:47 <mkwst> dveditz: Star is star.
20:21:01 <mkwst> devd: Star is an error with credentials set to true.
20:21:16 <mkwst> dveditz: It's ok to say that something is public by responding with star.
20:21:29 <mkwst> ... Otherwise it has to specifically acknowledge the requester.
20:21:37 <mkwst> ... Shouldn't change the rules for that.
20:22:03 <mkwst> dveditz: If it's a public response, you don't need to acknowledge the response.
20:22:29 <mkwst> devd: Let's say /foo requests /foo/bar. I want that to work in older browsers, and not break them to support suborigins.
20:22:36 <dveditz> can someone eating carrots/celery please mute
20:22:38 <bhill2> (can whoever is eating an apple please mute?)
20:22:38 <mkwst> jww: I'm confused about what you're confused about.
20:23:33 <mkwst> devd: If a completely different domain requests with credentials and the server responds with star...
20:23:54 <mkwst> jww: I understand the issue now. I'm trying to figure out what sounds reasonable. Let's take it offline now that I understand the concern.
20:23:58 <mkwst> ... Start a new thread?
20:24:52 <mkwst> ... 2. `postMessage`. Serialize the suborigin into the origin field. Could be issues with retrofitting applications, so might want to provide an `unsafe-postmessage-serialization` or something to get the origin without the suborigin, explicitly check the suborigin if you care.
20:25:21 <mkwst> ... 3. `localStorage`. Every suborigin gets a fresh jar, could provide an opt out mechanism.
20:25:36 <mkwst> ... annevk suggested banning localStorage. Don't know how practical that is.
20:25:49 <mkwst> devd: What does "banning" mean? Throw on access?
20:26:03 <mkwst> jww: I think Anne wants to ban the API as in throw it.
20:26:15 <mkwst> devd: Banning isn't practical, folks use it.
20:26:24 <terri> zakim, present+
20:26:25 <mkwst> ... Use case is things we don't trust and which don't have good practice.
20:26:37 <mkwst> ... Need to support those legacy things.
20:26:38 <timeless> s/zakim, present+/present+ terri/
20:26:45 <mkwst> dveditz: Not just `localStorage`, any storage, indexed db, etc.
20:26:57 <mkwst> devd: Anne doesn't like `localStorage` as it's sync and slow.
20:27:10 <mkwst> dveditz: Right, but the question is whether we create new storage or not.
20:27:28 <mkwst> devd: Create new storage. Sandbox solves the case where we want to throw.
20:27:55 <mkwst> jww: My position is that suborigins should be treated as a separate origin to the extent possible. Should get its own storage, just like any other domain.
20:28:10 <mkwst> dveditz: Banning the feature isn't a great idea. It's giving up. It's not what folks expect to happen.
20:28:10 <timeless> q+
20:28:30 <puhley_> puhley_ has joined #webappsec
20:28:38 <mkwst> timeless: Reason to ban things is to move the web forward. In exchange for shiny new, give up crappy old.
20:28:53 <mkwst> dveditz: Oh, you mean he's suggesting to ban `localStorage` but not indexed db?
20:29:32 <mkwst> devd: Right, but putting crappy code into a suborigin is why we want suborigins. We don't trust the old crappy code, we should support those APIs in suborigins to get the security benefits.
20:29:47 <mkwst> timeless: I don't have a horse in this, but if you keep it, you have to say why you're keeping it.
20:29:57 <mkwst> jww: Sounds good.
20:30:10 <timeless> q-
20:30:18 <mkwst> 4. Cookies!
20:30:23 <mkwst> jww: 4. Cookies!
20:30:47 <mkwst> ... Apps at Google that want suborigins that would need cookies from the parent origin
20:30:51 <dveditz> jww said explicitly "document.cookies" which is a subset of cookies in general
20:31:08 <mkwst> ... Mike pointed out that cookie model is somewhat broken as is, ignores scheme, etc.
20:31:33 <mkwst> ... Dev has pointed out that readable access to `document.cookie` is dangerous. Takeover suborigin, get access to login cookie.
20:32:01 <mkwst> devd: Network requests still send cookie though, right? So what's the concern about being logged in or not?
20:32:22 <mkwst> jww: Yes. I wrote `document.cookie` but I meant that cookies need to be shared in some respect.
20:32:36 <mkwst> devd: Sure, I'm _just_ talking about `document.cookie`. Let's remove that.
20:33:27 <mkwst> jww: I'm loath to put words in Artur's mouth.
20:33:37 <mkwst> mkwst: I think he was talking about `document.cookie`
20:34:29 <mkwst> jww: Removing `document.cookie` seems like a reasonable default, might need an opt-out for some applications.
20:34:42 <mkwst> ... Not sure what the exact behavior should be (throw or empty)?
20:34:48 <bhill2> q+
20:34:52 <mkwst> devd: Might want to separate writes from reads as well. Can discuss offline.
20:35:08 <bhill2> ack bhill
20:35:36 <mkwst> bhill2: Meta concern as chair: we talked about COWL at TPAC and noted that there are some similarities in terms of mechanisms and goals between it and suborigins.
20:35:41 <mkwst> ... Sandboxing as well.
20:36:08 <mkwst> ... I trust that our editors and authors are all smart and working on real apps with real concerns.
20:36:37 <timeless> q+ to +1 this, since it's useful for authors in the future
20:36:38 <mkwst> ... But it would be great if we had a document looking at these solutions side by side and explaining why choosing one over the other is the right thing to do in particular circumstances.
20:36:52 <dveditz> q+
20:37:01 <mkwst> ... It would be a shame if the only documentation of that was in the folklore of reading meeting minutes.
20:37:06 <timeless> ack me
20:37:06 <Zakim> timeless, you wanted to +1 this, since it's useful for authors in the future
20:37:12 <mkwst> .. Should lay out systematically.
20:37:21 <bhill2> http://www.w3.org/TR/COWL/
20:37:30 <mkwst> devd: Is the COWL spec ready? I think I have a reasonable understanding of suborigins.
20:37:39 <mkwst> ... Sandbox has a number of limitations that suborigins would solve.
20:38:16 <mkwst> jww: I tried at the top of the draft to compare suborigins and sandboxing. Truthfully, I don't understand COWL well enough yet to compare.
20:38:31 <mkwst> devd: COWL could explain why suborigins and sandbox don't solve?
20:38:35 <mkwst> ... Then we could merge into one doc.
20:39:17 <mkwst> bhill2: Regardless of which subset of these specs we proceed with, it would be valuable to compare the possible solutions and outline the authoring concerns that drove us to choose the solution we specified.
20:39:40 <mkwst> ... I'd suggest that jww should chat with Deian to talk through the comparison with COWL.
20:39:58 <mkwst> ... I know it's a big ask to have another top-level doc, but it would help clarify my thinking on the topic.
20:40:00 <wseltzer> present+ wseltzer
20:40:02 <mkwst> ... I'd be happy to help.
20:40:15 <mkwst> jww: Ok. Maybe we can arrange something on the mailing list to char.
20:41:04 <mkwst> dveditz: Mozilla devs aren't keen on implementing this. Why is it so much better than an actual subdomain or distinct port? Sites insecure in old browsers anyway?
20:41:16 <mkwst> ... Concrete examples would be helpful.
20:41:19 <wseltzer> rrsagent, pointer?
20:41:19 <RRSAgent> See http://www.w3.org/2015/11/16-webappsec-irc#T20-41-19
20:41:25 <mkwst> devd: Dropbox wants this. Right now.
20:41:33 <mkwst> ... I'll send an email.
20:41:40 <mkwst> dveditz: To the mailing list.
20:41:48 <mkwst> jww: I appreciate the difficulty of implementation.
20:42:04 <mkwst> ... UAs that don't implement it failing to protect is true of everything we do.
20:42:14 <mkwst> dveditz: Sure, but in this case, isn't it as easy to create a "real" origin.
20:42:28 <mkwst> devd: Business pressure (SEO, etc) to have everything on a single domain.
20:42:47 <mkwst> ... Could imagine every component on subdomains.
20:42:49 <bhill2> q+   X-Frame-Options and CSP impacts?
20:42:53 <bhill2> q+
20:43:01 <mkwst> ... Subdomains aren't as well isolated as suborigins could be (cookies, etc).
20:43:05 <mkwst> ... Should do this over email.
20:43:07 <dveditz> ack dveditz
20:43:14 <bhill2> ack bhill
20:43:25 <devd> woah .. sorry guys, I need to learn the speaker queue :(
20:43:32 <mkwst> bhill2: One other thing: what do we do with CSP and X-Frame-Options?
20:43:37 <timeless> s/q+   X-Frame-Options and CSP impacts?/q+ to mention X-Frame-Options and CSP impacts?
20:43:49 <mkwst> ... I can understand why you wouldn't want to move to a new domain, as things that depend on you would break.
20:43:56 <mkwst> ... But maybe that's desirable behavior.
20:44:10 <mkwst> ... Maybe we need CSP to apply to subdomains and/or suborigins?
20:44:15 <mkwst> ... Something to think about.
20:44:33 <bhill2> TOPIC: UI Security and Visibility API
20:44:33 <mkwst> TOPIC: UI Security / Visibility API
20:44:40 <bhill2> http://w3c.github.io/webappsec/specs/uisecurity/index.html
20:45:04 <mkwst> bhill2: A few calls ago, Dan joined us and went through his talk from Defcon. Iron Frame.
20:45:15 <mkwst> ... Have an existing UI Security spec.
20:45:22 <mkwst> ... Based on pixel scraping.
20:45:41 <mkwst> ... Performance impact, given modern GPUs, was bigger than any user agent was willing to take on.
20:45:57 <mkwst> ... Dan proposed an alternate approach, based on reordering layers.
20:46:15 <mkwst> ... Goal of causing layer to be drawn on top of other layers in the compositor.
20:46:25 <mkwst> ... I've rewritten UI Security in terms of that mechanism.
20:46:31 <mkwst> ... Declarative policy is simplified.
20:46:46 <mkwst> ... Can't describe detailed rectangles via DOM selectors, etc.
20:47:04 <mkwst> ... Now have an imperative API, which allows us to simplify the declarative API.
20:47:15 <mkwst> ... Added visibility API as it's directly related.
20:47:39 <dveditz> q+
20:47:41 <mkwst> ... Might model it in terms of mutation observer. Causes events to be fired, giving information about viewport.
20:47:57 <mkwst> ... I think the questions around the API are:
20:48:11 <mkwst> ... 1. Making API useful for paid content that wants to know whether they're visible.
20:48:29 <mkwst> ... Wants the `ancestorOrigin` concept to be part of the visiblity event that's fired.
20:48:44 <mkwst> ... Are Firefox/Edge interested in implementing something like that API?
20:48:54 <mkwst> dveditz: I think telling a frame who its parents are violates the SOP.
20:49:07 <mkwst> bhill2: `frame-ancestors` lets you make pretty good guesses.
20:49:25 <mkwst> devd: `frame-ancestors` doesn't leak it, you have to brute force.
20:49:37 <mkwst> bhill2: That's true.
20:49:45 <mkwst> ... It's been in Chrome for a pretty long time.
20:49:53 <mkwst> ... Are Chrome folks aware of exploitation?
20:50:11 <mkwst> dveditz: How do you get that information in Chrome?
20:51:18 <mkwst> mkwst: It's been in Chrome for a long time.
20:51:44 <mkwst> ... I talked with bz about it a while ago. He wasn't interested in implementing it at that point. Might be worth rekindling the conversation.
20:52:19 <timeless> -> http://peter.sh/2012/04/limiting-khtml-and-apple-prefixes-and-location-ancestororigins/ location.ancestorOrigins
20:52:28 <mkwst> bhill2: Understand that it can be seen as a violation of SOP. With my Facebook and Editor hat on, it seems like it's valuable for abuse protection.
20:52:48 <mkwst> ... If we know visibility, enables more interesting use cases with embedded documents.
20:53:08 <mkwst> ... Has always been the case that typing into an iframe gives you input exclusivity. Parent frames can't sniff keystrokes, etc.
20:53:30 <mkwst> ... Could extend the address bar. Could show what origin you're typing into.
20:53:55 <mkwst> ... On a scale of "Do it!" to "Absolutely not, that's completely crazy.", where does the group fall?
20:53:56 <wseltzer> +1
20:54:15 <wseltzer> q+
20:54:30 <bhill2> mkwst: browsers are skeptical about specifying UI, but we do this in limited ways in the mixed content spec
20:54:44 <bhill2> ... would be difficult to explain to users that a page consists of more than one origin
20:54:50 <bhill2> ... having one origin in the address bar is valuable
20:55:19 <bhill2> ... they have a chance to understand it, but making it more complicated would have to be backed up with user studies and a good way to present it that the spec might now allow
20:55:39 <dveditz> ack dveditz
20:56:07 <mkwst> dveditz: Input directive for CSP; appears to only make it difficult if you had multiple ones.
20:56:21 <mkwst> ... If you had a few of these items, it might be order dependentl.
20:56:46 <mkwst> bhill2: I think you could do that. Maintains internal state.
20:57:05 <mkwst> ... when event delivered to protected element, calculate bounding rec for that element, compare it to the last visibility event on the stack.
20:57:16 <mkwst> ... should be possible to add additional elements to be checked.
20:58:27 <mkwst> q+, Intersection Observer
20:58:38 <dveditz> ack wseltzer
20:58:49 <dveditz> ack intersection
20:58:53 <dveditz> ack Observer
20:59:12 <mkwst> wseltzer: Extending the address bar is probably necessary to enable pages to give up control of subcomponents, and inform users that they've done so.
20:59:28 <mkwst> ... Could be the basis of allowing sites to build a true peer-to-peer experience.
20:59:49 <mkwst> ... Useful to start thinking about now, even if it's only a few users who would understand what it's for at first.
21:01:05 <mkwst> mkwst: Intersection Observer is a thing. Would be interesting to see how much of that could be used for this.
21:01:22 <ckerschb> ckerschb has left #webappsec
21:01:27 <mkwst> bhill2: Thanks folks, bye!
21:01:27 <wseltzer> trackbot, end teleconf
21:01:27 <trackbot> Zakim, list attendees
21:01:27 <Zakim> As of this point the attendees have been mkwst, gmaone, jww, ckerschb, tanvi, Josh_Soref, dveditz, Brad, Hill, francois, terri, wseltzer
21:01:35 <trackbot> RRSAgent, please draft minutes
21:01:35 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html trackbot
21:01:36 <trackbot> RRSAgent, bye
21:01:36 <RRSAgent> I see no action items
21:01:38 <bhill2> bhill2 has joined #webappsec
21:19:43 <RRSAgent> RRSAgent has joined #webappsec
21:19:43 <RRSAgent> logging to http://www.w3.org/2015/11/16-webappsec-irc
21:19:50 <timeless> s/Josh_Soref/timeless/G
21:19:59 <timeless> RRSAgent, draft minutes
21:19:59 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
21:20:11 <timeless> RRSAgent, bye
21:20:17 <timeless> RRSAgent, make logs world
21:20:20 <timeless> RRSAgent, draft minutes
21:20:20 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
21:20:23 <timeless> RRSAgent, bye
21:20:23 <RRSAgent> I see no action items
21:23:46 <RRSAgent> RRSAgent has joined #webappsec
21:23:46 <RRSAgent> logging to http://www.w3.org/2015/11/16-webappsec-irc
21:23:50 <timeless> s/scribenick mkwst/scribenick: mkwst/
21:23:53 <timeless> RRSAgent, make logs world
21:23:58 <timeless> RRSAgent, draft minutes
21:23:58 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
21:24:26 <timeless> s/woah .. sorry guys, I need to learn the speaker queue :(//
21:24:41 <timeless> s/TOPIC: UI Security and Visibility API//
21:25:03 <timeless> s/No./None./
21:25:11 <timeless> s/less ambiguous//
21:25:16 <timeless> s/er, "none" is better I guess//
21:26:02 <timeless> s/can someone eating carrots/celery please mute//
21:26:10 <timeless> s/(can whoever is eating an apple please mute?)//
21:26:51 <timeless> s/Reason to ban/(Anne, and the web's) Reason to ban/
21:27:17 <timeless> s/4. Cookies!/4.-Cookies!
21:27:19 <timeless> s/4. Cookies!//
21:27:23 <timeless> s/4.-Cookies!/4. Cookies!
21:28:40 <wseltzer> s/If we know visibility,/Another feature not yet written-up: If we know visibility,/
21:28:46 <timeless> s/location.ancestorOrigins/"location.ancestorOrigins" April 17th, 2012/
21:28:55 <timeless> RRSAgent, draft minutes
21:28:55 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
21:29:17 <timeless> i|Input directive for CSP|scribenick: mkwst|
21:29:37 <timeless> i|mkwst: browsers|scribenick: bhill2|
21:29:41 <timeless> RRSAgent, draft minutes
21:29:41 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
21:30:22 <bhill2> bhill2 has joined #webappsec
21:30:28 <timeless> i|bhill2: Agenda bashing|scribenick: mkwst|
21:30:30 <timeless> RRSAgent, draft minutes
21:30:30 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
21:30:55 <timeless> i|Agenda bashing|topic: Agenda bashing
21:30:57 <timeless> RRSAgent, draft minutes
21:30:57 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
21:31:34 <timeless> s/TOPIC: Minutes approval//
21:31:54 <timeless> i|2015-10-28-webappsec-minutes.html|TOPIC: Minutes approval
21:31:57 <timeless> RRSAgent, draft minutes
21:31:57 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
21:32:59 <timeless> s|s/scribenick mkwst/scribenick: mkwst/||
21:33:07 <timeless> s|s/can someone eating carrots/celery please mute//||
21:33:14 <timeless> s|can someone eating carrots/celery please mute||
21:33:17 <timeless> RRSAgent, draft minutes
21:33:17 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
21:33:45 <timeless> RRSAgent, bye
21:33:45 <RRSAgent> I see no action items
21:34:58 <RRSAgent> RRSAgent has joined #webappsec
21:34:58 <RRSAgent> logging to http://www.w3.org/2015/11/16-webappsec-irc
21:35:01 <timeless> s|April 17th, 2012|in WebKit and Chrome before April 17th, 2012|
21:35:06 <timeless> RRSAgent, draft minutes
21:35:06 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/16-webappsec-minutes.html timeless
21:35:32 <timeless> RRSAgent, make logs world
21:35:35 <timeless> RRSAgent, bye
21:35:35 <RRSAgent> I see no action items