23:40:19 RRSAgent has joined #webappsec 23:40:19 logging to http://www.w3.org/2015/10/29-webappsec-irc 23:40:21 RRSAgent, make logs world 23:40:21 Zakim has joined #webappsec 23:40:23 Zakim, this will be WASWG 23:40:23 I do not see a conference matching that name scheduled within the next hour, trackbot 23:40:24 Meeting: Web Application Security Working Group Teleconference 23:40:24 Date: 29 October 2015 23:40:27 rrsagent, this meeing spans midnight 23:40:27 I'm logging. I don't understand 'this meeing spans midnight', wseltzer. Try /msg RRSAgent help 23:40:36 rrsagent, this meeting spans midnight 23:46:44 wonsuk has joined #webappsec 23:53:51 jungkees has joined #webappsec 00:06:24 rbarnes has joined #webappsec 00:08:46 francois has joined #webappsec 01:05:14 wonsuk has joined #webappsec 01:09:31 rbarnes has joined #webappsec 01:18:55 bhill2 has joined #webappsec 01:21:07 yoav has joined #webappsec 01:30:22 mnot has joined #webappsec 01:33:11 bhill2 has joined #webappsec 01:35:02 kiyoung has joined #webappsec 01:35:11 barryleiba has joined #webappsec 01:35:13 Yoshi has joined #webappsec 01:35:56 rbarnes has joined #webappsec 01:36:44 yoav has joined #webappsec 01:39:04 present+ bhill2 01:39:08 present+ francois 01:39:09 present+ BarryLeiba 01:39:13 present+ dveditz 01:39:32 present+ wseltzer 01:39:40 Melinda has joined #webappsec 01:39:42 present+ mek 01:40:35 present+ Melinda 01:42:08 scribe: bhill2 01:42:32 deian: SOP/CSP/CORS are discretionary access control 01:43:01 [Deian will share slides after] 01:44:01 ... mashup use cases and data sharing cases are difficult with DAC 01:44:50 ... libraries are over-permissioned, credentials are over-delegated and there are mashup scenarios we can't easily build between mutually distrusting services 01:47:31 wonsuk has joined #webappsec 01:48:27 hwlee has joined #webappsec 01:50:14 jgraham has joined #webappsec 01:53:44 JeffH has joined #webappsec 01:56:52 annevk has joined #webappsec 01:57:19 (window.location.origin should be document.origin) 02:00:55 what stops a context from stringifying the data and postMessaging a string with no label 02:01:04 s/what/dveditz: what/ 02:01:20 deian: there should be no definition for stringifying a labeled object 02:01:27 dveditz: would have to be opaque? 02:01:45 deian: there is a definition for how to structurally clone, which is to clone the label and then the opaque object 02:02:27 ... have to use a getter to open the opaque object, which taints your context when used 02:02:45 ... and who you can communicate with is then restricted 02:07:45 bhill2: what about navigating other contexts you have a handle to? 02:08:00 deian: you can't do that because of information flow policies 02:08:07 annevk: do you taint all the children? 02:09:53 deian: no.. mods to html5 02:10:01 bhill2: what about workers? 02:10:13 deian: only talk to workers through postMessage, so tainted 02:10:17 annevk: do you block push? 02:10:49 @@: how does this work with message ports? no concept of origins 02:11:05 deian: only allow sending messages when you know the origin at the other end 02:11:11 @@: but you can't know until too late 02:12:02 annevk: mostly have message ports for shared workers, apple just removed them, msft has no plans to support, and mostly never used - maybe they can go away 02:12:15 @@: used to queue tasks quickly or structured clone things 02:12:34 deian: maybe can look and decide when receiving message, not sure where to specify that 02:13:28 s/@@:/Mek:/ 02:13:37 thx wseltzer 02:14:29 deian: prototype was done in terms of CSP hooks 02:14:53 annevk: for navigation you need to hook directly into navigation to avoid traversing history 02:15:17 deian: maybe navigation source directive into CSP would make it a natural place to work 02:15:29 annevk: once you are confined you no longer have an active server connection 02:15:39 deian: yes, but it gets revoked once your confidentiality label changes 02:15:46 annevk: once you're confined, then things drop 02:16:05 dveditz: what happens to service worker? do you skip or drop if it's not an appropriate service worker? 02:16:48 annevk: might have to disable notifications, too, to avoid waking up service worker 02:18:21 deian: also, server-supplied labels for XHR 02:20:56 annevk: look at fetch since we've stopped adding features to XHR 02:21:59 deian: wanted to do this, but fetch made it awkward to look at response type to deal with labeled JSON 02:24:00 annevk: you can't extract an origin from a cowl:// URL, it is null / unique because that's not on the whitelist of schemes that have hierarchical authority 02:24:06 dveditz: we could add that.... 02:24:31 some discussion w/dveditz and annevk about suborigins, not yet defined 02:24:59 dveditz: some way of making a suborigin look like a url would be useful 02:26:20 annevk: you could just compare literals 02:26:35 dveditz: if literals, don't make it look like an origin, maybe even reject anything with a colon 02:27:40 annevk: CORS just uses string literal 02:27:58 deian: was a reason to extract origin, to send servers you're communicating with your context information 02:28:05 ... so for cross-origin requests, that is useful 02:28:29 dveditz: so this creates a leakage if you've blocked referrer 02:29:22 dveditz: like idea of signaling, because tells server more about how to answer a request 02:29:37 ... but it also leaks information you may not want to leak across origins, need to think about it and get wide review 02:30:22 annevk: use of commas in header may be a problem 02:30:54 dveditz: doesn't need to be json, could just be WSP delimited 02:31:11 ... what do brackets do for you? difference between AND and OR? 02:31:19 deian: yes, conjunction vs. disjunction 02:34:34 deian: header and js api has some mismatch- js api lets you specify in any format, but representation is always canonical ndis format 02:38:28 ... firefox patch in the works 02:38:41 ... also a subset we could do with a polyfill + CSP + 3rd party server 02:41:10 bhill2: It seems to me that suborigins overlaps. 02:41:19 ... Where does this fit in relation to that spec? 02:41:38 ... Suborigins are not about confinement, they want a public label for postmessage, normal cross-origin communication. 02:41:48 ... They need to be able to live as a top-level application. 02:42:05 ... Splitting out applications that happen to be deployed on the same domain without a synthetic domain. 02:42:13 deian: Disjunction does that. 02:42:35 ... No labeled cookies, etc. 02:42:55 bhill2: Seems like an explicit goal of suborigins that you could have localstorage and cookies and etc. Looks like a regular origin label. 02:43:04 ... Could have origin-labeled access to standard platform features. 02:43:23 deian: We could probably have some sort of labeled storage? 02:43:36 bhill2: Maybe suborigins are just the privilege part of this. 02:43:59 ... Privileges you expect. Reaching into other document contexts being considered cross-origin, etc. Doesn't imply navigation. 02:44:09 ... Would like to separate these concerns. 02:44:32 deian: Labels would do confinement, suborigins could do privileges. 02:45:53 bhill2: Header is the only way to enter suborigins, doesn't change state dynamically. 02:46:09 ... Forces isolation for the page from other things on the "same" origin. 02:47:37 annevk: what about permissions? 02:47:57 mkwst: "parent" origin permissions might cascade into suborigins, or it might be distinct - JoelW needs to decide this 02:48:21 ... might need to ask users more often and store it internally - can't put any more info into URL bar, probably not putting suborigin there 02:48:49 ... user would be confused why "google.com" keeps asking for permissions because the suborigin abstraction is not exposed 02:50:30 bhill2: Do I have to ask for permission every time for new disjunction states? 02:50:35 deian: Yes. 02:50:43 annevk: Since you're sandboxed, maybe the permissions are gone? 02:51:01 bhill2: You couldn't keep that up to date unless you were continually receiving messages from someone. 02:52:01 deian: But you couldn't receive messages unless you accepted the label. 02:52:15 annevk: Sensor API? Maybe you couldn't leak information that way. 02:52:19 deian: Open question! 02:52:29 http://www.chromium.org/developers/design-documents/per-page-suborigins 02:54:29 deian: If I have an iframe, I read something from somewhere else, I get tainted. But I still might have a handle to objects in the iframe. 02:54:36 ... Need to wipe out those references somehow. 02:54:39 ... Easy to do in Firefox. 02:54:48 ... Harder in Chrome. 02:55:07 ... Can we lock this to secure contexts? 02:55:13 dveditz: Yes. That's the whole point of that spec. 02:55:25 ... Browsers are generally moving towards locking things to secure contexts. 02:55:39 ... Only makes sense to talk about tainting if you know who you are to begin with. 02:55:45 ... So should require secure contexts. 02:55:53 deian: Future directions: 02:56:05 ... (More important to get v1 hammered out) 02:56:16 ... (Should talk to Joel to see what the overlap with suborigins might be) 02:57:11 bhill2: Yes. Would be nice if these were built on the same primitives. 03:10:24 bblfish has joined #webappsec 03:17:17 rbarnes has joined #webappsec 03:29:45 jyasskin has joined #webappsec 03:43:51 Zakim has left #webappsec 03:58:57 rbarnes has joined #webappsec 04:01:32 barryleiba has joined #webappsec 04:05:55 mnot has joined #webappsec 04:09:46 Melinda has joined #webappsec 04:10:04 rbarnes has joined #webappsec 04:11:50 bblfish has joined #webappsec 04:15:46 Zakim has joined #webappsec 04:23:57 rbarnes has joined #webappsec 04:28:40 npdoty has joined #webappsec 04:31:43 rbarnes has joined #webappsec 04:34:50 deian has joined #webappsec 04:36:05 TOPIC: Agenda bashing 04:38:44 TOPIC: containers 04:38:49 https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers 04:39:19 rbarnes: additional labels applied to contexts, local storage, etc. to prevent sharing state between e.g. two logins to Twitter with different accounts 04:39:25 dveditz: are these created by user or site? 04:39:31 rbarnes: user in current implementation 04:40:04 ... when you load something in a container, everything is in that container 04:40:30 ... effectively lightweight profiles 04:40:34 masato has joined #webappsec 04:40:59 ... in chrome each profile gets its own history, bookmarks, etc. 04:41:11 ... containers only are for page created state, share user-created state 04:41:29 mkwst: interested in extracting some of the features out and giving them to sites, not just to users 04:42:04 ... some projects in google are using chrome apps to get these properties 04:42:26 dveditz: firefox apps used to have that property and now they share cookies, etc. 04:42:46 annevk: because you don't want to have to login to Facebook 100 times 04:42:49 mkwst: but you do 04:43:45 mkwst: a site might not want to share by default that a facebook user is at the bank without that user's choice 04:44:07 ... boils down to double-keying for all storage in a secure origins context 04:44:33 ... tor browser has proven this is doable; breaks some things - if you opt-in, we can probably guarantee that it doesn't break things for those who opt-in 04:46:05 ... loaded in separate process, subframes in separate process, separate cookie jar and all things I load use that new cookie jar, and identity is distinct in different embedding contexts even if same-origin 04:46:20 .... only works in top-level contexts as a straw-man 04:46:50 dveditz: would this be site-wide? 04:47:16 mkwst: yes like hsts, with maybe a mandatory includessubdomain-like effect and locked to the topmost registerable domain 04:49:14 ... like first-party only cookies. If you're embedded your embeddor has no power over you, no ambient authority associated with the origin in another origin's context 04:49:35 dvetditz: e.g. a womans' shelter might use this so embedded trackers can't know the user's been there 04:49:58 mkwst: private mode is different about not leaving traces locally.... 04:50:44 rbarnes: this includes aspects of private browsing mode in terms of trackers, sharing, etc. 04:51:11 francois: primarily about preventing CSRF. 04:51:16 rbarnes has joined #webappsec 04:51:33 mkwst: primarily, but also if you know it is isolated it can be in a separate process, renderer can be hardened. 04:55:18 ... might be a different way of solving some of the problems that EPR is trying to tackle 04:55:20 wonsuk has joined #webappsec 04:55:52 ... example use case is to build as a web application, delivered through a browser, very sensitive things that are by-design not meant to be connected with the open web 04:56:05 ... say, to manage virtual machines 04:57:08 deian: what if the browser tells the user about this... 04:57:14 dveditz: then we would be triple keyed 04:57:27 mkwst: in my use cases I care about there is no need to tell the user 04:58:07 ... mozilla implementation requires user to know and decide what is sensitive 04:58:22 ... different properties if a site can opt in 04:59:24 q+ 04:59:50 wseltzer: how does a user do something with isolated bank? 05:00:12 mkwst: if isolated bank gives you a means of logging in outside the isolated context, you can do what you want normally 05:00:20 ... it might choose not to interact with you in those contexts 05:00:21 mnot has joined #webappsec 05:00:42 dveditz: firefox apps had this, chrome has this, tor browser is adding htis 05:00:47 s/htis/this/ 05:01:22 wseltzer: yes, but I think it is interesting and useful for the user to be able to interact with a site that declares itself this way 05:01:58 mkwst: interesting paper by Charlie Reis, et al. about multiple browsers 05:02:06 ... epr is one implementation of an idea in there, this is another 05:02:08 q+ 05:02:27 dveditz: I like what david is trying to do with EPR but manifest seems icky 05:02:34 http://www.collinjackson.com/research/papers/appisolation.pdf 05:02:42 mkwst: I suspect he will still want EPR 05:02:48 ack rbarnes 05:03:11 rbarnes: if we have a way for sites to opt out of containers, change or refresh container, overlaps nicely with clear site data ideas 05:03:21 ... if all site data is containerized and you can throw it away... 05:03:37 dveditz: label containers? 05:04:21 rbarnes: hsts like semantics with max-age would create auto-expiring state 05:05:29 q+ 05:05:38 ack bhill 05:06:18 mkwst: would not want subresources to opt you in, maybe only from the root of the registerable domain 05:07:02 bhill2: can you tie this to a manifested web app 05:07:11 mkwst: easier to do at domain level because cookies are broken 05:07:20 annevk: you need a cache for this to persist the state 05:07:26 ack rbarnes 05:08:05 rbarnes: having a label might let different origins 'hold hands' in their own universe 05:08:25 bhill2: you can use a public key like android apps 05:09:12 mkwst: would like to think about it with regard to syntax 05:10:25 deian: I'd help write it up 05:11:37 xiaoqian has joined #webappsec 05:11:54 wseltzer: can a user opt a site into this for themselves? 05:12:09 rbarnes: yes, it's already doing that, or could inject a header, or configure an origin by name... 05:12:13 ... tor browser already doing this 05:14:06 TOPIC: timing attacks 05:14:08 Kepeng has joined #webappsec 05:14:24 deian: aware of researchers that can do these kinds of leaks exfiltrating data with SVG by blurring an iframe 05:14:45 ... would be good to have guidance for spec authors on side channels and info leaks 05:16:46 ... even implementations-wise, e.g. a cache is likely to result in attacks if it is shared cross-origin 05:18:25 TOPIC: COWL non-origin labels 05:20:44 deian: maybe namespaces? 05:21:02 ... only thing that can mint privileges is the browser 05:21:08 ... mint a.com and give it to a.com page 05:21:25 ... but if we had something labeled geolocation: and we knew that only the browser could do that 05:21:37 ... only kinds are unique or delegated privileges 05:22:39 dveditz: could have a colon if it had, e.g. a character illegal in scheme names to disambiguate it from scheme names, or a fixed name like cowl:, but would have to register it 05:23:18 annevk: need to be serialized to go over the network 05:23:48 ... on network you could have a disambiguator when serialized, but object model would have different flags for origin vs. name 05:25:21 annevk: filed Fetch issue: https://github.com/whatwg/fetch/issues/150 05:25:37 origin label; suborigin label - can't be minted by page; application label - can be created by any JS; "permission" label (result of an API call, unforgable); fresh 05:26:15 annevk: could we start out a lot simpler if we only had a separate instance of a service worker that we can give some labeled object it can compute on and return the result to its caller 05:26:25 ... don't have to think about the interaction with as many things as browsing contexts 05:26:58 ... for service workers we're also considering cross-origin cases, haven't explored that for normal workers 05:28:16 annevk: thinking: a.com gives some data to b.com's service worker, b.com can't communicate back to b.com once it opens the labeled object 05:28:23 ... could make the draft much simpler 05:28:35 deian: but today you have UI 05:29:35 bhill2: UI seems like most interesting case to me, provide experience to user of composite information but not leak that back to remote servers 05:38:39 deian: what to do when label provided by server doesn't match what it is allowed to provide? 05:38:45 ... taking approach of not warning user about this 05:38:59 dveditz: should fail closed to the extent we can 05:39:58 ... what if we just drop it, call it a network error 05:40:04 ... new stuff nobody is using, we can check and be strict 05:41:09 mkwst: if we're going to be parsing, maybe extract this out to someplace where parsing happens 05:41:20 annevk: order matters, COWL before cookies 05:41:35 mkwst: have at least two blocks parsing CSP 05:41:48 annevk: that's because of service workers, but COWL is only right from the network 05:42:31 annevk: can a service worker add these labels....does it do the right thing 05:42:53 deian: service worker would have to abide by confinement 05:43:01 mkwst: would that mean you can find where redirects go? 05:43:21 ... if not-example.com returns labeled responses, I can read that cross-origin? 05:43:32 annevk: labeled data has to be CORS accessible 05:43:43 ... there is a problem with confining service workers because they are shared 05:44:12 ... to instances of b.com sharing a service worker, then a.com communicates with one in a way that introduces confinement, the other tabs stop working 05:44:28 ... if you want fetching to work offline, going to involve service workers, and foreign fetch is coming 05:44:57 ... so you'd have to have multiple instances of service workers 05:45:18 deian: may be able to think of service worker as extending the authority of the server and may not need to confine it 05:45:28 annevk: sw also has access to storage and other stuff 05:49:04 annevk thinks that chrome doesn't have wrappers, so existing references to a node in a different document that depended on being same origin won't be broken by setting the sandboxing flag 05:49:24 mkwst: true today, but not forever, eventually we will implement something like membranes... 05:49:24 virginie has joined #webappsec 05:50:02 annevk: maybe we should standardize membranes then... 06:00:45 Topic: AOB 06:01:57 Melinda: We presented some work on DNS API previously; we've continued work and have Firefox and Chrome extensions 06:02:38 ... work going into TLS after 1.3 06:03:07 [discussion of uses of DNSSEC, additional information, isolation modes, supplementing CA info] 06:03:39 bhill2: DNSSEC as a transport for policy 06:03:56 rbarnes: also cache priming 06:04:11 Melinda: Paul Wouters work 06:04:24 ... establishing authority 06:04:51 ... OpenSSL 1.2 implementation 06:06:48 rrsagent, make minutes 06:06:48 I have made the request to generate http://www.w3.org/2015/10/29-webappsec-minutes.html bhill2 06:06:54 rrsagent, set logs public-visible 06:07:10 meeting adjourned, transitioning to non-minuted unofficial security BoF in this room following the break 06:07:42 bhill2 has joined #webappsec 06:20:24 npdoty has joined #webappsec 06:37:29 rbarnes has joined #webappsec 07:01:33 barryleiba has joined #webappsec 07:02:38 wonsuk has joined #webappsec 07:15:07 barryleiba has left #webappsec 07:15:33 Zakim has left #webappsec 07:17:18 Melinda has joined #webappsec 07:25:20 bblfish has joined #webappsec 08:00:45 rbarnes has joined #webappsec 08:19:44 bblfish has joined #webappsec 08:23:33 bblfish has joined #webappsec 08:23:37 mnot has joined #webappsec 08:24:51 deian has joined #webappsec