18:53:41 <RRSAgent> RRSAgent has joined #webappsec
18:53:41 <RRSAgent> logging to http://www.w3.org/2015/07/27-webappsec-irc
18:53:43 <trackbot> RRSAgent, make logs world
18:53:43 <Zakim> Zakim has joined #webappsec
18:53:45 <trackbot> Zakim, this will be WASWG
18:53:45 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
18:53:46 <trackbot> Meeting: Web Application Security Working Group Teleconference
18:53:46 <trackbot> Date: 27 July 2015
18:54:50 <wseltzer> wseltzer has changed the topic to: WebAppSec 27 July: https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0160.html
18:54:54 <wseltzer> agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0160.html
18:55:06 <wseltzer> chairs: bhill2, dveditz
18:55:45 <JonathanKingston> JonathanKingston has joined #webappsec
18:57:38 <terri> I wish webex had an obvious way to test audio before the meeting starts
18:57:53 <terri> but I'm glad it let me in 5 minutes early so I could test
18:59:06 <wseltzer> [without the zakim identification, we need to present+ when joining the call]
18:59:09 <wseltzer> present+ wseltzer
18:59:55 <rbarnes> rbarnes has joined #webappsec
19:00:36 <JonathanKingston> present+ JonathanKingston
19:00:39 <jww> jww has joined #webappsec
19:00:47 <terri> present+ terri
19:00:49 <estark> estark has joined #webappsec
19:01:17 <dveditz> present+ dveditz
19:01:25 <dveditz> (although I'm not sure the phone connection worked)
19:01:45 <dveditz> thx wseltzer, guess it's working
19:02:22 <dveditz> mkwst: are you using phone or the webex app?
19:02:22 <gmaone> gmaone has joined #webappsec
19:02:28 <tanvi> tanvi has joined #webappsec
19:02:51 <jww> I'm dialed in over the phone; is there anything I need to do to associate my IRC id with the number?
19:02:59 <jww> like we used to with Zakim
19:03:11 <mkwst> present+ mkwst
19:03:15 <dveditz> jww: I don't think there is
19:03:24 <dveditz> that's why "present+" for Zakim
19:03:30 <jww> present+ jww
19:03:35 <tanvi> trying to figure out how to dial in
19:04:11 <estark> present+ estark
19:04:24 <tanvi> present+ tanvi
19:04:25 <wseltzer> present+ Crispin, Dave
19:04:36 <gmaone> present+ gioma1
19:04:48 <gmaone> present+ gmaone
19:06:03 <dveditz> Zakim, who is here?
19:06:03 <Zakim> sorry, dveditz, I don't know what conference this is
19:06:05 <Zakim> On IRC I see tanvi, gmaone, estark, jww, rbarnes, JonathanKingston, Zakim, RRSAgent, dveditz, francois, renoirb, timeless, Josh_Soref, mkwst, tobie, slightlyoff, freddyb, trackbot,
19:06:05 <Zakim> ... terri, mounir, wseltzer
19:06:16 <JonathanKingston> I'm call in however not tried speaking :D
19:06:22 <rbarnes> wseltzer: i am on webex, will dial in in a few min
19:07:02 <francois> present +francois
19:07:10 <wseltzer> regrets+ bhill2
19:07:22 <wseltzer> dveditz: no minutes from last time yet
19:07:31 <wseltzer> ... on the agenda, suborigin namespaces concept
19:07:32 <JonathanKingston> Was CSP pinning not on the topic spreadsheet?
19:08:05 <wseltzer> @@: should we talk about SRI failing open vs failing closed?
19:08:08 <mkwst> JonathanKingston: We (briefly) discussed pinning in Berlin, right?
19:08:37 <wseltzer> ... I think decsion from Berlin was to bring it back on the list
19:08:49 <wseltzer> ... resulting in the suggestion to add CORS attribute automatically
19:09:00 <JonathanKingston> mkwst: super brief I guess, I don't have anything to add just asking as it was on the previous agenda :D
19:09:23 <wseltzer> dveditz: we shouldn't decide on a call on which it was not announced
19:09:48 <wseltzer> @@: we've had conversation on the list for a while; some of those people on the cal
19:10:07 <wseltzer> ... we could decide on the call, announce on the list, and if people don't object, it's the decision
19:10:38 <wseltzer> dveditz: but we usually announce agenda items in advance. on the other hand, this is minor
19:10:55 <wseltzer> ... add to agenda. Anything else?
19:11:03 <wseltzer> agenda+ SRI fail open or closed
19:11:04 <dveditz> TOPIC: sub-origin namespaces
19:11:30 <wseltzer> dveditz: sub-origin namespaces and per-page sub-origins concept
19:11:56 <wseltzer> jww: per-page sub-origin concept is logical extension
19:12:17 <wseltzer> jww: Quick overview, then update on status, discussion
19:12:34 <wseltzer> ... basic idea, provide mechanism for sites to separate content from application
19:12:47 <wseltzer> ... while still serving both from same logical orgin (scheme/host/port)
19:12:57 <wseltzer> ... First question people ase, why do we need this?
19:13:09 <wseltzer> ... Practically, that's often difficult for real-world applications.
19:13:32 <wseltzer> ... google.com/maps google.com/finance are both logically separate apps, hosted on the same domain
19:13:40 <wseltzer> ... it would be nice to be able to separate them
19:13:46 <rbarnes> wseltzer: i am now on the voip audio
19:13:51 <wseltzer> ... Next question: why not sandboxes?
19:14:03 <wseltzer> present+ rbarnes
19:14:13 <rbarnes> yeah, my question is "why not domains"
19:14:21 <wseltzer> jww: you can't have frmes in the sandbox
19:14:29 <wseltzer> ... you might want to share some state with the parent origin
19:14:31 <rbarnes> is this a problem for domains other than google.com?
19:14:43 <wseltzer> ... sub-origin is like "name sandboxes"
19:14:56 <wseltzer> ... original proposal: server would serve sub-origin name
19:15:03 <wseltzer> ... default policy, restrict everything
19:15:18 <wseltzer> ... mechanism yet-to-be determined to turn things on, geo, cookies, etc.
19:15:30 <wseltzer> ... another goal, users should not really deal with suborigins
19:15:37 <wseltzer> ... so geoloc permission hard to separate
19:15:58 <wseltzer> ... as we started looking, proof of concept, code in github
19:16:17 <wseltzer> ... then concluded this was almost certainly too restrictive to be useful
19:16:23 <wseltzer> ... What's the threat model?
19:16:30 <wseltzer> ... XSS attacker that can take over an origin.
19:16:45 <wseltzer> ... at foo.com /app1 and /app2
19:17:11 <wseltzer> ... you want attack that takes over /app1 not to be able to directly access content at /app2
19:17:32 <wseltzer> ... working internally at Google to find logical restrictions from app perspective
19:17:40 <wseltzer> ... especially for retro-fitting.
19:17:56 <wseltzer> ... Lowest-hanging fruit: CORS restrictions across sub-origins, figure out hte rest later.
19:18:23 <wseltzer> ... if we treat each sub-origin as requiring CORS, that would handle lots of cases
19:18:51 <wseltzer> ... in testing, treat requests from sub-origin as cross-origin
19:19:14 <wseltzer> ... some issues: how does it serialize, what goes to the server
19:19:27 <wseltzer> ... Wanted to present before we went much further. Thoughts?
19:19:36 <rbarnes> q+
19:19:48 <wseltzer> ack rbarnes
19:19:52 <devd> devd has joined #webappsec
19:20:07 <wseltzer> rbarnes: In what sense are these origins "sub"? inheriting anything from parent, or logically separate?
19:20:22 <wseltzer> jww: there is a relationship between subs and parent
19:20:47 <wseltzer> ... logical separation; there will be some state that should be shared
19:21:18 <rbarnes> it's origins all the way down!
19:21:48 <wseltzer> jww: in my dream land, there are per-sub-origin options, but that would be up to the developer
19:21:54 <wseltzer> rbarnes: can you comment more on use cases?
19:22:34 <wseltzer> jww: started with specific Google apps; I've used other apps that look logically separate but hosted at same origin
19:22:42 <wseltzer> devd: At dropbox, we'd love to use that
19:23:12 <wseltzer> ... separating by origins is less good, because the origin is what users trust
19:23:24 <JonathanKingston> q+
19:23:29 <terri> q+
19:23:33 <wseltzer> ... like to separate off applications
19:23:56 <wseltzer> rbarnes: seems the current proposal propagates the origin down the URL
19:24:14 <wseltzer> ... no binding between the resource being accessed and the sub-origin
19:24:53 <wseltzer> ... e.g example.com/app1 and example.com/app2 . looks as though I could send app1 for both
19:25:07 <wseltzer> jww: we didn't want to tie directly to full URL
19:25:46 <wseltzer> ... we don't know a priori where the separation should occur
19:26:07 <wseltzer> ... the server is the authoritative source of namespace, via header
19:26:09 <wseltzer> q?
19:26:09 <dveditz> q?
19:26:17 <dveditz> ack JonathanKingston
19:26:24 <wseltzer> ack JonathanKingston
19:26:47 <wseltzer> JonathanKingston: could this help with apex domains?
19:26:54 <wseltzer> ... without any subdomain?
19:27:24 <wseltzer> jww: per-page, based on request
19:27:42 <wseltzer> ... to the same request URL, you coudl come back with different sub-origins
19:27:57 <wseltzer> @@: browser can't make any origin decisions until it gets response from server?
19:28:07 <wseltzer> jww: yes, that's been a challenge in design
19:28:18 <wseltzer> ... all requests from suborigin are treated as CORS
19:28:27 <wseltzer> ... trying to figure out if that's acceptable
19:28:49 <wseltzer> ... but later, need to do the pre-flight, etc. to determine if it's actually different
19:28:53 <dveditz> s/@@/dveditz/
19:28:55 <wseltzer> s/CORS/CORS-enabled/
19:29:20 <wseltzer> JonathanKingston: I've got some worries around top-level cookies
19:29:22 <dveditz> ack terri
19:29:37 <wseltzer> terri: can you talk about the complexity? what it means to have multiple origins?
19:29:57 <wseltzer> ... how big this can explode
19:30:10 <wseltzer> jww: great implementor question
19:30:50 <wseltzer> ... open question
19:31:05 <wseltzer> terri: we might need to understand that better before making everything a CORS request
19:31:14 <wseltzer> devd: do we have alternatives?
19:31:16 <bhill2> bhill2 has joined #webappsec
19:31:53 <wseltzer> jww: Anne vK had suggested we need that to happen everywhere (check origins on response)
19:32:02 <wseltzer> devd: can we reduce preflight requirements? performance hit
19:32:40 <wseltzer> ... if it's same main origin, can we remove pre-flight, make access control on response
19:32:46 <wseltzer> jww: I'll look into it
19:32:50 <wseltzer> q?
19:33:21 <wseltzer> devd: how would this play with, e.g. service workers?
19:33:35 <wseltzer> ... those rely pretty heavily on origin boundaries
19:33:52 <wseltzer> jww: you really don't want a suborigin to register a service worker
19:34:20 <wseltzer> ... but ok for the top-level to have superpowers, e.g. initiate sw that could serve to suborigins
19:34:33 <wseltzer> ... design goal of suborigins, to make the webserver the authoritative source
19:34:45 <wseltzer> ... one of the key invariants, a document can't enter a suborigin
19:34:53 <wseltzer> ... sw are "local representative" of the server
19:35:01 <wseltzer> ... so logical to control the suborigins
19:35:23 <wseltzer> devd: if a suborigin tries to register a sw, what happens?
19:35:26 <wseltzer> jww: it would fail
19:36:04 <wseltzer> devd: I'd try to enable them; apps might want their own sws
19:36:36 <wseltzer> jww: I can also imagine a world in whcih sws can be suborigin bound
19:37:06 <wseltzer> ... more complex
19:37:20 <wseltzer> devd: how do local storage, cookies APIs work?
19:37:31 <wseltzer> jww: only restriction CORS, service worker registratoin
19:37:37 <wseltzer> ... regular APIs acceptable
19:37:55 <wseltzer> ... since one of the big use cases is retrofitting
19:38:05 <wseltzer> ... but I'd like to have a world where you can start turning off and on APIs
19:38:08 <rbarnes> q+
19:38:21 <wseltzer> devd: we have to restrict beyond XHR, eg. accessing iframes
19:38:23 <wseltzer> jww: yes.
19:38:27 <rbarnes> q-
19:38:52 <wseltzer> ... the other major restriction is from js object perspective, suborigin is an additional part of the origin check re crossing document boundaries from js
19:38:59 <wseltzer> devd: woudl be great to go through APIs
19:39:21 <wseltzer> ... CSRF cookie enough to do anything
19:39:35 <wseltzer> ... have you gone through these APIs to assess risk?
19:40:05 <wseltzer> jww: we did one pass; considering threat of XSS attacker who takes over one app
19:40:14 <wseltzer> ... trying to get content on behalf of the user.
19:40:24 <wseltzer> ... does not include CSRF
19:40:42 <wseltzer> devd: but sharing actions could be dangerous
19:41:47 <wseltzer> ... can you give list of APIs, and we'll help review?
19:41:58 <dveditz> q+
19:42:17 <wseltzer> terri: that sounds like something we'd want to document at CR
19:42:32 <wseltzer> dveditz:
19:43:00 <wseltzer> dveditz: how does suborigin concept compare with "web app" concept from WebApps WG?
19:43:14 <wseltzer> jww: I'm not yet familiar with that proposal
19:43:41 <wseltzer> dveditz: there seem to be large areas of overlap, and we wouldn't want to do both unless they're distinct
19:43:46 <wseltzer> jww: which document?
19:44:06 <terri> It's not manifest, unless something's been added recently
19:44:14 <wseltzer> dveditz: Jonas was talking about double-keying
19:44:25 <wseltzer> ... not sure which document
19:44:54 <wseltzer> devd: WebAppSec is best equipped to create primitives
19:45:10 <wseltzer> ... and security boundaries
19:45:33 <wseltzer> terri: when we were talking about security boundaries at TPAC, WebApps was interested in having WebAppSec do that
19:46:32 <wseltzer> dveditz: value in creating primitives, and alos in talking about the higher-level concept we're trying to model
19:46:42 <dveditz> s/dveditz/mkwst
19:46:52 <wseltzer> devd: for me it's very useful, modeling boundaries within app
19:47:10 <dveditz> s/dveditz/mkwst/
19:47:20 <wseltzer> ... application concept seems broader than security boundaries
19:47:34 <wseltzer> q?
19:47:40 <dveditz> ack dveditz
19:48:13 <wseltzer> dveditz: what's next? are you going to extend your per-page developers design doc, or write the spec?
19:48:14 <gmaone> q+
19:48:19 <wseltzer> jww: depends on feedback
19:48:42 <wseltzer> ... dev's point re making sure we're restricting the right things
19:48:56 <wseltzer> ... a little bit more prototype, then spec
19:49:06 <wseltzer> devd: prototyping on app side, developers using it
19:49:23 <wseltzer> jww: I'm working with engineers too
19:49:41 <wseltzer> ... it would be extraordinarily helpful if anyone external wants to help
19:50:07 <wseltzer> q?
19:50:29 <wseltzer> rbarnes: I'm a bit concerned that hierarchy will be confusing
19:50:41 <wseltzer> ... so separate origins
19:51:07 <wseltzer> ... rather than the origin + sub-origins
19:51:07 <rbarnes> 0, 1, many :)
19:51:35 <wseltzer> jww: I'm not sure that it can't get worse
19:52:24 <wseltzer> devd: I'd be sad if we didn't make new primitives cleaner than document.domain
19:52:51 <wseltzer> ack gmaone
19:53:16 <wseltzer> gmaone: I share concern aboout not knowing in advance what will be the final destination of the request
19:53:36 <wseltzer> ... consider noscript
19:54:07 <wseltzer> ... concerned from security and implementation perspective
19:54:09 <dveditz> rbarnes: that would be terrible, would allow a super-domain to attack a child
19:54:22 <dveditz> (assuming they couldn't mess with dns anyway)
19:54:56 <rbarnes> dveditz: but the alternative is to have another axis along which origins can extend, which is also gross
19:55:01 <dveditz> yes
19:55:02 <wseltzer> jww: a fundamental issue, you don't know until you get the response that it's cross-origin
19:55:42 <rbarnes> dveditz: if you're a child domain, the parent can always screw you
19:55:49 <rbarnes> nature of hierarchy
19:56:27 <wseltzer> Topic: SRI Fail Open or Closed
19:56:46 <wseltzer> @@: discussion on github issue
19:56:54 <wseltzer> ... no one has expressed desire for fail-open
19:56:57 <jww> Here's the post-Berlin thread: https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0118.html
19:57:37 <wseltzer> ... AvK had suggested that anything with integrity defaults ot cross-origin: anonymous
19:57:56 <wseltzer> ... do we go with implicit attribute or fail closed and force devs to add it?
19:58:13 <wseltzer> @@2: I think editors agreed it should not include anonyumous implicitly
19:58:20 <wseltzer> ... not universal consensus, but editors
19:58:24 <JonathanKingston> https://github.com/w3c/webappsec/issues/317
19:58:39 <wseltzer> @@: I think so, perhaps Freddy has warmed to anonymous
20:01:45 <wseltzer> mkwst: this is probably a breaking change
20:02:17 <dveditz> s/@@/francois/
20:02:44 <dveditz> @@2 was jww?
20:03:16 <wseltzer> dveditz: This suggests the ml thread is not yet resolved
20:03:24 <wseltzer> ... please respark that thread.
20:03:39 <wseltzer> ... Discuss on-list and put on agenda for next call.
20:03:42 <JonathanKingston> +1 thanks
20:03:56 <wseltzer> [adjourned]
20:04:07 <wseltzer> trackbot, end teleconf
20:04:07 <trackbot> Zakim, list attendees
20:04:07 <Zakim> sorry, trackbot, I don't know what conference this is
20:04:15 <trackbot> RRSAgent, please draft minutes
20:04:15 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/27-webappsec-minutes.html trackbot
20:04:16 <trackbot> RRSAgent, bye
20:04:16 <RRSAgent> I see no action items
20:04:18 <wseltzer> rrsagent, make logs public