08:04:32 RRSAgent has joined #webappsec 08:04:32 logging to http://www.w3.org/2015/07/13-webappsec-irc 08:04:42 francois has joined #webappsec 08:04:50 Zakim has joined #webappsec 08:05:13 Meeting: WebAppSec Berlin F2F, Day 1, 13-July-2015 08:05:15 freddyb has joined #webappsec 08:05:16 Agenda: https://github.com/w3c/webappsec/blob/master/admin/berlin-f2f-july-2015-agenda.md 08:05:25 Chairs: bhill2, dveditz 08:05:42 JonathanKingston has joined #webappsec 08:06:17 opening webex shortly 08:06:21 present+ wseltzer 08:06:22 rbarnes has joined #webappsec 08:06:34 present+ bhill2 08:06:47 rrsagent, draft minutes 08:06:47 I have made the request to generate http://www.w3.org/2015/07/13-webappsec-minutes.html bhill2 08:06:51 present+ dveditz 08:06:52 rrsagent, make logs world 08:07:00 present+ francois 08:07:11 present+ freddyb 08:08:13 present+ JonathanKingston 08:08:31 scribenick: wseltzer 08:08:38 topic: Introductions 08:09:09 bhill2: Genesis of this meeting, conversations about "what would it take to get all the Web commiunication secure" 08:09:41 ... what are the edge cases, how do optimistic/opportunistic upgrades work 08:09:58 ... upgrades, mixed content and interaction with same-origin 08:10:10 ... tomorrow's agenda focused on that conversation, with TAG 08:10:23 ... what do we want to build here? sponsor in IETF? work with TAG? 08:10:41 agenda: https://github.com/w3c/webappsec/blob/master/admin/berlin-f2f-july-2015-agenda.md 08:11:01 bhill2: SRI is about ready to head to CR, so we could talk about that too 08:11:12 ... agenda has room for other discussion 08:11:27 wseltzer: leads w3c's technology and society domain 08:11:52 ... on w3c side responsible for trying to figure out what it means to keep the web secure and private while enabling all the things we want to do on the web 08:12:15 rbarnes: Mozillan, security agitator, trying to figure out how to deprecate insecure http 08:12:26 dveditz: Mozillan, also co-chair of WG 08:12:50 freddyb: Mozillan, co-editor of SRI 08:13:03 https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ 08:13:12 francois: Mozillan, co-editor of SRI and implementor of it in Firefox, in security engineering group 08:13:48 jonathankingston: cyber.me a startup doing security training for developers, want to improve the security for the web 08:14:37 axel: observer Deutsche Telecom, research group, some issues with formally joining given legal structure of DT at the moment 08:15:45 axel: interested in secure elements, NFC 08:15:54 Cyber-AMI 08:16:04 ... interested in web crypto, support for native applications, how to integrate native features accessing secure elements into the web platform 08:16:49 dveditz: browser vendors have gotten gun shy about launching binary blobs after the disasters that plugins and activeX have been, would be interested in better defining the security model 08:17:09 axel: for some years, url schemes worked, but may be multiple targets 08:17:26 dveditz: and may not be a communication path back 08:17:40 axel: and chrome started showing mixed content warnings when launching these schemes 08:20:11 ... also was a founding member of InfoCard foundation, board member of OpenID foundation and implemented Firefox plugins to enable these technologies 08:22:29 bhill2: I think FIDO Alliance is planning a member submission once they get through their IP process 08:23:27 ... any discussion on SRI? 08:23:38 freddyb: Most of the discussion is minor editorial nits 08:23:45 ... no formal objections 08:23:59 ... clearer reference to CORS 08:24:05 ... security considerations 08:24:14 dveditz: 15 open issues, How do those look? 08:24:31 francois: filter on milestones 08:25:16 freddyb: biggest issue for v2 is probably more subresources 08:25:24 francois: also caching 08:25:48 rbarnes: e.g. say "this defines no new caching behavior" 08:26:21 freddyb: for v2, cross-origin caching by hash, if we can do it smartly 08:27:52 freddyb: would be interesting to use SRI for import directive in CSS, but needs re-specification in terms of CSS, and may be easier to wait for CSS to redefine how that works in terms of fetch 08:28:38 ... in terms of nested content, for something like an iframe, just check the content and if that content wants to put integrity on its own resources, it can do that 08:29:11 ... but transitive descent is the job of each window to handle it's own resources 08:29:46 dveditz: why not images? 08:30:30 freddyb: wasn't considered in the threat model as compared to code execution possible with script and css 08:31:00 dveditz: image substitution can be damaging, e.g. a presidential campaign linking to an off-site image from a non-supporter 08:31:14 dveditz: any technical difficulties in adding this to arbitrary elements? 08:31:21 freddyb: we don't think so 08:31:31 francois: images easy, iframes harder 08:31:58 freddyb: mostly wanted to move fast, get code review, ship things 08:32:36 dveditz: objects & embeds, but those are tricky because we don't always do the loads for those 08:33:55 bhill2: what about HTML imports? 08:34:25 freddyb: can be tricky because of blocking 08:34:31 alexr: blocks paint, not parse 08:34:55 present+ AlexRussell 08:36:29 francois: probably landing in firefox this week 08:36:45 bhill2: does the test suite have full coverage? 08:37:24 francois: on my to-do list to review 08:37:47 bhill2: my impression is that it's in good shape 08:39:03 https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6263699-subresource-integrity 08:40:54 JonathanKingston: working on SRI support as a broccoli plugin for Ember.js 08:41:01 ... use it out of the box without any scary features 08:41:50 ... 3 examples: same origin (relative path), external, third option to specify the url is same as origin but w/absolute path 08:42:32 JonathanKingston: I might be interested in working on an IG note on same-origin policy 08:42:47 devditz: what is reasoning behind fail-open for non-CORS? 08:43:17 ... if developer has added an integrity attribute, aren't they asking for failure behavior 08:43:39 francois: pretty much only getting the hash wrong will block, everything else syntax-wise fails open to give us flexibility for future extensibility 08:44:11 dveditz: what is benefit of failing open if developer forgets to specify CORS mode 08:45:51 francois: we can always fail closed in the future, but don't want to close now because we may find a way in the future to avoid the CORS requirement 08:46:40 dveditz: actually can't move to fail closed in the future 08:47:11 ... if we find a way to avoid CORS requirement because we do something else, we can make that case succeed w/o CORS mode 08:47:54 ... if we integrated into another place in the fetch, we could maybe do something else 08:49:41 francois: also, old browsers would fail closed, even if a new mechanism to enable it existed 08:52:18 bhill2: are there any plausible scenarios in which we could avoid CORS fetch? 08:52:24 francois: not really 08:54:22 https://github.com/w3c/webappsec/issues/317 is where most of the discussion took place 08:56:45 slightlyoff has joined #webappsec 08:59:40 bhill2: feel pretty comfortable saying we can't integrity-check an opaque response without leakage 09:02:20 where's the thread on github? 09:02:39 thanks 09:02:56 https://github.com/w3c/webappsec/issues/317#issuecomment-110844444 09:02:59 this comment 09:13:31 JonathanKingston: that everyone in this room needs some clarification is a good example of why this will be confusing and it should be changed 09:15:26 i/minor editorial nits 09:15:33 i/minor editorial nits/Topic: SRI/ 09:15:55 :) 09:44:19 rrsagent, draft minutes 09:44:19 I have made the request to generate http://www.w3.org/2015/07/13-webappsec-minutes.html bhill2 09:44:36 freddyb has left #webappsec 09:44:36 freddyb has joined #webappsec 09:46:52 TOPIC: Minutes approval 09:47:08 http://www.w3.org/2011/webappsec/draft-minutes/2015-06-29-webappsec-minutes.html 09:47:29 minutes approved by unanimous consent 09:47:41 rbarnes has joined #webappsec 09:49:09 TOPIC: CfC on non-normative changes to CORS REC 09:49:11 https://lists.w3.org/Archives/Public/public-webappsec/2015Jun/0094.html 09:51:32 unanimous consent to publish an edited recommendation as indicated 09:52:12 bhill: all of these are non-normative changes 09:54:18 Topic: Removing unsafe-redirect from CSP2 09:56:17 bhill2: mkwst's patch on potential leakage from different redirect depending on login state 09:56:30 dveditz: or where leaked path could reveal userid or security token 09:56:53 ... blocked paths; issue that it's still cross-origin leakage 09:57:09 slightlyoff: problem in service workers too 09:58:11 ... if you have an open redirect on your origin ... auto-xss 09:58:31 ... how much info is too much? the fact of a redirect? 09:58:50 ... it would be great if this group could make statements about what info about the presence of a redirect can be exposed 09:58:59 ... e.g. the fact of a redirect 09:59:08 rbarnes: any utility to scoping to cross-origin redirects? 09:59:11 fyi: this is the patch being discussed: https://github.com/w3c/webappsec/commit/7456cb77e504fa70991b3cc54c852e62ebc7a2cc 09:59:31 dveditz: if it's same origin, no problem reaching into the iframe 10:00:35 JonathanKingston: you can turn off redirects in fetch 10:01:16 slightlyoff: yes: follow, error, or manual 10:01:34 bhill2: nobody implemented unsafe-redirect, so ripping it out 10:02:07 ... but adding a CSP-active 10:04:14 dveditz: 'unsafe-inline' will break existing users of CSP and attackers will not set it 10:04:37 ... so we should fix reports to not report the violation, potentially even the origin 10:05:20 bhill2: but the original homakov exploit relied on onerror handling, whether resource loaded at all with CSP, not on reporting 10:07:54 slightlylate: response object could have 1 bit set indicating if a redirect was traversed 10:08:09 freddyb: just cross-origin or also same-origin? 10:10:24 rbarnes: what is the need for this? 10:11:16 slightlylate: large scale application composition or lack of global knowledge, may not know about flow of authority 10:11:35 dveditz: do SWs get any headers back? 10:11:52 slightlylate: for same-origin and CORS we can see almost everything, otherwise no 10:12:21 dveditz: with no-cache type directives, do we want SWs to cache? 10:12:38 slightlylate: we explicitly make this the programmer's program, and cache opaque responses opaquely 10:12:55 ... that's the next question I wanted to get to - if redirects are OK, what else is? 10:12:59 dveditz: caching, vary? 10:13:39 rbarnes: can we handle this better declaratively? initiator can declare if he expects it to be cross-origin redirected instead of asking 10:14:20 Zakim has left #webappsec 10:14:25 redirect-scope="same-origin" 10:20:16 bhill2: you could already force that information leak in CSP 10:22:01 by setting a CSP policy for a specific fetch type with a policy that only allows one domain, you could detect by the CSP-generated error state whether a cross-origin redirect occurred anyway 10:22:05 unsafe-allow-redirects=t.co 10:22:53 so if that information is already available in the platform, adding a bit to the API of a response to make it explicitly available is not introducing anything new 10:23:04 it's just syntactic sugar for an existing infoleak 10:24:43 bhill2: if surfacing this formally generates strong objections and good security reasons not to do it, should we change CSP? 10:25:01 ... to allow the initial resource the implicit authority to delegate 10:25:13 dveditz: that would be a horrible hole in CSP in my opinion, really don't want to do that 10:27:34 TOPIC: CSP Level 2 and inline styles 10:29:04 JonathanKingston: style-src without 'unsafe-inline' forbids setting of freeform text in style attribute but not setting individual attributes that affect the computed style 10:29:36 dveditz: this is by design, because individual properties have validators and prevent free-form setting of styling that might be more powerful 10:29:50 ... maybe we should add a better explanation to the spec 10:30:02 ... it was explained in long threads, but that may have not translated to our final text 10:30:45 JonathanKingston: this is broken everywhere, I've been advocating preventing setting of style in Ember and using individual attributes instead 10:30:57 ... but can't point to spec text that says why one is OK and the other is not 10:37:02 raised https://github.com/w3c/webappsec/issues/423 10:37:17 https://github.com/hillbrad/web-platform-tests/blob/7845ee1a94700b95aa9ef636aae66adae5e27efe/content-security-policy/blink-contrib/inline-style-allowed-while-cloning-objects.sub.html 10:55:45 https://bugzilla.mozilla.org/show_bug.cgi?id=883975 10:55:47 https://bugzilla.mozilla.org/show_bug.cgi?id=855326 11:06:18 I am, in theory, here. 11:06:38 Just need to find the entrance. :) 11:10:00 Found it! Probably! Waiting for an elevator. 11:34:21 rbarnes has joined #webappsec 11:42:28 present+ mkwst 11:42:47 [reconvene] 11:43:17 Topic: Mixed Content 11:43:50 mkwst: Mixed content is implmented in every major browser 11:44:02 ... substantial test suite 11:44:26 ... some failures around forms 11:45:20 ... CfC on-list 11:45:43 ... one thread on service workers 11:46:02 ... operations on an opaque blob 11:46:15 ... fetch from within a service worker 11:48:06 ... Brian saying: with new stuff, we shouldn't support insecure practices 11:49:11 ... Not sure we need to answer it all in the initial draft 11:49:24 dveditz: also some concerns about CSP and service workers 11:49:42 mkwst: service workers act as a network proxy 11:50:06 ... page should have the ability to govern what loads on the page, not what's on the network 11:50:38 slightlyoff: the governing policy for the service worker needs to be sent with the service worker 11:50:58 dveditz: the CSP of the sw may be different from any of the multiple pages that use the sw 11:52:21 mkwst: a constructed response is similar to a blob URL 11:54:00 mkwst: we should enable pages to set policy that disallows constructed responses 11:54:16 slightlyoff: where will that policy come from? 11:54:21 mkwst: from the page or the sw 11:56:24 mkwst: should the page have the ability to control the "washing" of requests / redirects through sws? 11:57:04 dveditz: if sw is serving multiple pages, it may want to obey CSPs, but not know what they are? 11:57:12 ... may be a good thing to hook on responses 11:57:27 bhill2: is there a security boundary that we could be enforcing? 11:59:36 mkwst: Mixed Content is asking: should the sw be bound by the same policy as the page? 11:59:47 ... seems like a different question from security policy 12:02:05 ... currently, no way for sws to make insecure requests 12:02:11 ... no problem if we don't change that. 12:02:38 ... Other question, whether deprecated TLS needs to be in Mix 12:02:46 ... Just rely on fetch. 12:02:58 ... I suggest that we push it to PR 12:03:27 bhill2: Mixed content checks fire before HSTS upgrades 12:04:46 ... 2 sides: mix first, since not all browsers support HSTS 12:05:02 ... but now IE has HSTS 12:05:18 ... and it may be more pain than benefit 12:05:46 ... so now more inclined to make things easy for devs to start transitioning 12:06:09 francois: also consider instead of blocking, opportunistic upgrades 12:06:35 ... keep the missing padlock, but try to improve 12:06:55 mkwst: relates to tanvi's question about upgrade-insecure and strict mode 12:07:19 ... the different forbes websites at http and https 12:08:34 slightlyoff: I asked the crawl incidence: 99.7% conincidence between http https 12:08:47 ... fuzzy, mostly based on text 12:09:56 mkwst: Adam Langley opposes changes the ordering of Mix - HSTS 12:10:10 ... we should talk more with the network folks 12:10:48 dveditz: another possible level, in strict-mode, do before; in non-strict mode, do HSTS first 12:11:01 mkwst: strict mode also disables user decisions 12:11:06 ... by blocking the request 12:14:11 ... intent is not to show the user option to turn on the insecure 12:14:59 bhill2: some of the auto-upgrade may be suitable for level 2 12:15:14 ... we'll have more options, e.g. automatic discovery 12:15:51 https://w3c.github.io/webappsec/specs/mixedcontent/#further-action 12:16:47 mkwst: how you choose not to load insecure resources is up to you 12:17:05 francois: what about potentially secure? 12:17:28 mkwst: language might need improvements between secure context / mixed content 12:17:39 ... Mix uses secure to mean HTTPS 12:20:37 [discussion of localhost] 12:20:54 mkwst: I'm loath to carve out exception 12:21:51 ... I don't like "install app locally and then need to talk to it from the open web" because of security considerations 12:22:12 ... versus let devs test their apps on localhost before installing on HTTPS servers 12:22:26 ... different treatment for RFC 1918 hosts @@ 12:22:46 ... loading RFC 1918 from the web 12:23:21 rbarnes: origin resolving to 1918 address, or the address itself? 12:23:24 mkwst: ideally, both 12:23:37 ... would have liked to block those 12:23:45 https://www.chromestatus.com/metrics/feature/popularity 12:23:50 ... but more widely used than I'd like 12:23:57 https://www.chromestatus.com/metrics/feature/timeline/popularity/530 12:24:03 ~0.6% of page views. 12:24:44 rbarnes: apps getting certs for local, then had to have the certs revoked 12:24:48 ... so it's a good thing to block 12:25:21 mkwst: it's reasonable to want to have a single definition 12:25:36 ... threat model of mix is attacker who can see what you're doing or interfere 12:25:46 ... not the local host 12:26:21 bhill2: you could also say Mix is a contract of tranquility of the secure state 12:26:35 ... violated by local resources even if no network attacker 12:28:39 bhill2: 3 issues 12:28:50 ... block local network resources? - more discussion 12:29:01 .... deprecated TLS. was listed at-risk 12:29:17 ... we should remove the refs that now go to undef termm 12:29:21 s/termm/term/ 12:30:34 ... and the service worker question 12:33:51 mkwst: EME issue 12:34:43 ... get back an opaque blob to pass to elsewhere 12:35:31 perhaps we just need EMEHR 12:35:39 ... we block XHR and fetch, because they leak information 12:36:16 ... if we could guarantee that it was just data being used, not executed, then we could do different things, possibly 12:36:30 ... I'm not entirely convinced 12:37:54 rbarnes: have the page declare that the data will be used in only one way 12:38:24 ... e.g. declare things browser accessible only 12:38:47 bhill2: I don't want to encourage people to put more edge cases into HTTP 12:39:32 mkwst: Agree. I've heard more requests for the localhost thing than anything else. 12:41:00 mkwst: editorial change on deprecation 12:41:09 ... not going to do anything with localhost or fetch 12:41:31 ... so group is more or less happy to push this out and come back if there are compelling use cases. 12:41:45 axel: what's your solution to web page talking to its associated location? 12:41:53 mkwst: there's not a current solution 12:41:57 ... we need a better one. 12:42:19 ... I'd suggest it needs at least 2 components: allow app to opt-in to communication 12:42:28 ... and the user has to allow access to local net. 12:42:43 ... and probably other things need to happen. 12:43:44 axel: I have an app I want to have used by many websites 12:43:56 ... earlier working blocked by mixed content 12:44:50 mkwst: apps installed locally have high privilege, and it's dangerous to expose that privilege to the open web 12:45:12 ... I think I agree there are good use cases for talking to something local 12:45:33 ... but simply exposing the interface to the web is a bad idea 12:46:03 slightlyoff: navigator connect. one of the hopes for sw is to let apps talk 12:46:20 ... navigator connect lets apps post-message 12:46:40 ... lets a sw register to provide services located at a URL 12:47:28 ... the whole thing ends up in the origin security model 12:47:36 ... a thin abstraction over RPC for the web 12:47:51 s/sw/service workers/G 12:48:13 ... hoping to use it as a bootstrap for launching APIs 12:48:53 ... make it easier to experiment 12:49:08 ... without leaving trails of old things 12:49:54 ... navigator.connect IPC bridge with short-term windows 12:50:15 ... more science, less guessing 12:55:04 mkwst: postmessage from secure to insecure happens on ~5% of pageviews 12:55:15 ... and from insecure to secure on ~3% 12:55:49 JonathanKingston: u2f? 12:55:56 mkwst: currently in chrome, it's an extension 12:57:58 ... I think it's unfortunate that we shipped in a way that requires extension 12:58:14 https://www.chromestatus.com/metrics/feature/timeline/popularity/419 <-- secure to insecure, https://www.chromestatus.com/metrics/feature/timeline/popularity/420 <-- insecure to secure. 12:59:45 jose-cdbtr has joined #webappsec 13:00:26 wseltzer: sorry missed that: https://fidoalliance.org/specifications/overview/ 13:01:35 theme for the w3c https call: https://en.wikipedia.org/wiki/Just_Do_It#/media/File:JUST_DO_IT._%28NIKE%29.gif 13:03:42 present +jose 13:04:44 Topic: HTTPS for w3.org 13:09:25 wseltzer: the numbers would be the ones listed here: https://wiki.mozilla.org/WeeklyUpdates except a differernt conference number 13:10:04 conference 95201# 13:10:51 and the # key after 13:12:59 jose-cdbtr: any luck? 13:13:05 we don't hear you 13:14:13 after the 92 did you hear an invitation to enter the conf number? 13:14:20 I think you needed 92# 13:15:30 possible... we're checking 13:16:45 rebooting our system 13:18:40 jose-cdbtr: are you saying anything? we can't hear you 13:19:37 yes, we can hear you 13:20:35 https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0099.html 13:23:24 jose-cdbtr: we hear it too. don't know the cause 13:23:25 wseltzer: thanks to webappsec for pushing w3c to upgrade to https and providing technologies to help do so 13:23:41 ... constraints are that w3c site is a huge mass of hand-written pages with lots of absolute links to http 13:23:56 ... want to enable secure connections to as much as can be securely accessed w/o going back to hand-tweak all those links 13:24:07 rbarnes has joined #webappsec 13:25:28 jose-cdbtr: we have multiple servers for different services 13:26:01 ... and previously used switch-SSL to switch requests from HTTPS to HTTP for resources we didn't offer in HTTPS 13:26:22 ... proposing to stop making that switch 13:26:48 ... Lots of historic content that we can't update 13:27:54 ... many pages written individually, by hand 13:28:11 mod_rewrite? 13:28:43 bhill2: are there things that you're aware of that are still broken where the browser could help upgrade more smoothly? 13:29:19 jose-cdbtr: some infinite loops with HSTS and redirects 13:30:47 mkwst: have you filed a bug against the browser which had this behavior? 13:31:18 jose-cdbtr: not yet 13:31:43 i mean, if your HSTS-enabled page redirects to http://, you're gonna have a bad time 13:34:17 bhill2: was the CSP reporting issue related to HTTPS upgrades or a different policy you were trying to set? 13:34:47 ... e.g. were theses reports from setting something like default-src: *, or were you trying to do another kind of policy? 13:34:58 ... sorry default-src https: 13:35:27 mkwst: sounds like current upgrade strategy is dependent on upgrade-insecure-requests 13:35:38 ... what will you do for browsers that don't support that 13:36:33 jose-cdbtr: we will support http for some resources that are public 13:38:13 mkwst: the header that is now HTTPS:1 will soon be renamed 13:38:31 ... it will allow distinguishing between browsers that support upgrade-insecure and those that don't 13:39:32 let this be a lesson to you all -- scheme-relative URIs! 13:40:24 rbarnes: but relative is weak. you never know what your context is :-P the lesson is clearly HTTPS links only 13:41:03 freddyb: well, if they'd planned for this in the first place... 13:42:17 sorry, s/http:/https:/g 13:42:17 rbarnes: is this because you want root? 13:43:05 jose-cdbtr: we don't want to break old tools that rely on http: 13:43:31 ... what will we do with DTDs and namespaces 13:44:30 mkwst: what do you mean tools that don't support HTTPS? 13:45:52 jose-cdbtr: we asked the TAG for advice 13:47:06 jose-cdbtr: this tool might be helpful for finding mixed content: https://github.com/bramus/mixed-content-scan 13:47:17 jose-cdbtr: please try the test searver, email systeam if you find errors 13:48:16 francois, freddyb: i see that upgrade-non-secure-requests has landed in Firefox. do we send a header to announce support? 13:49:18 mkwst: you might split, upgrade to HTTPS first, then HSTS 13:49:26 +1 to what mkwst suggested 13:49:42 rbarnes: dunno, can't find the bug off hand 13:53:22 https://bugzilla.mozilla.org/show_bug.cgi?id=1139297 13:54:55 Can I ask where the best place for bug reports on this platform is? 13:54:57 freddyb: Cmd-F "header" indicates probably not 13:55:02 sysreq@w3.org 14:46:16 Topic: Secure Context 14:46:32 mkwst: Neither Yan nor I has done much 14:46:39 ... lately 14:46:54 rbarnes; some editorial suggestions 14:46:58 mkwst: send a pull request 14:47:08 mkwst: ancient (still open) 2004 Mozilla bug to change our handling of data: urls https://bugzilla.mozilla.org/show_bug.cgi?id=255107 14:47:43 mkwst: do we need to guarantee that a context can't be abused, e.g Netflix shim on webcrypto 14:47:49 ... walking the ancestor tree 14:50:28 rbarnes: assume we have a unitary concept of secure, then we're worried about communication from secure to insecure 14:51:27 bhill2: we don't have a no write-down policy on the web today 14:51:41 ... we assume origins are authoritative 14:52:24 rbarnes: that suggests we can't solve mkwest's shim problem 14:52:32 bhill2: you could do a latch like COWL 14:53:06 bhill2: tomorrow, let's talk about our inconsistent notions of security 14:53:34 ... tranquility vs information flow contracts 14:55:59 mkwst: push-notification proxy for third-party origins 14:56:04 ... roost 14:56:20 ... if we want secure context to have meaning, should make it non-trivial to circumvent 14:57:45 mkwst: if you're using message ports as a capability token... 14:59:57 mkwst: some people asking for isolation 15:00:31 ... e.g., separate cookie jar, no communication with the open web 15:00:41 slightlyoff: I want storage isolation 15:00:50 ... local storage, cookie jar, cache separated 15:01:04 mkwst: like double keying 15:01:14 slightlyoff: yes. chrome apps already do this 15:01:25 ... allows everyone else to live without the ambient authority 15:01:54 dveditz: firefox OS apps have taken that approach 15:02:00 ... double-keyed, no pollution 15:02:10 ... now they're tacking the other way, because logins don't persist 15:02:25 mkwst: as a blanket mechanism, it seems problematic 15:02:32 ... as opt-in, seems good 15:04:00 mkwst: isolation writ large; second, what's sufficiently secure context; might be no write-down 15:04:18 ... you can't post-message to insecure contexts, perhaps 15:04:32 bhill2: how do we evolve to a web where everything is secure? 15:04:55 ... where that trust is on servers and browsers 15:05:26 mkwst: don't talk to insecure stuff 15:06:25 rbarnes: a sufficiently determined server could always route through for insecurity 15:06:33 bhill2: you can't prevent delegation 15:08:54 dveditz: would it make sense to change postmessage? 15:09:41 mkwst: conceptually, don't post to insecure things seems like a reasonable thing for a website to opt-into 15:09:52 ... is that necessary to get access to these APIs? 15:10:28 JonathanKingston: good for encouraging upgrade 15:11:06 mkwst: current spec walks the ancestor tree 15:11:18 ... apparently does the wrong thing in th ecase of workers 15:11:27 ... and nothing in the case of new windows 15:11:30