SV_MEETING_TITLE -- 21 Sep 2016

mkwest: would like to talk about a few isolation proposals that have come up lately
... have some goals on the Chrome team for this kind of thing
... Moz does to, not sure those are the same goals
... what are we talking about here?
... many devs are building important, security-critical apps that they would like to be on the web
... muchos advantages of being on the web
... some applications, the web is v scary
... one app, at Google, Chrome app… as opposed to a web site
... bc afraid of being on the web
... other entities can talk to you, not good
... bug in the browser can allow evil.com to read state from your origin
... [something] allows deployment on Google's servers
... deploy as a Chrome app as opposed to web app, gave isolation properties
... forced process isolation, impossible to accomplish direct communication
... navigation from the web to this app is impossible, CSRF is no longer a threat
... impossible to get a window handle to this app
... can open, but can't post-message, send-message, look through frames
... app opens a window, don't get a window opener back to the app
... this seems like a failure of the web
... shouldn't force building of a native app
... @estark on Chrome team have been kicking around
... some ways to apply isolation to the web
... in ways that are compat with web, and of the web
... document here

<mkwst> https://mikewest.github.io/isolation/explainer.html#isolation

mkwest: idea is to spell out a threat model
... kinds of isolation that are relevant that we'd like to provide
... not complete, but a good start to the convo
... doc walks through threat model, policy options to allow web sites to implement isolation
... and spells out the attacks this can protect against
... a few ways this can go further
... valuable to have a communication barrier
... i.e., cutting off handle to windows
... also navigation into those windows blocked
... proposal last year Entry Point Regulation

<mkwst> http://www.collinjackson.com/research/papers/appisolation.pdf

mkwest: based on:
... ^^^
... spells out a similar idea in terms of threat model and iso techniques
... inspired site isolation effort in Chrome
... allow sites to force separate processes
... massive arch effort in Chrome
... will be live in Chrome 55
... want to get to a place where every site i a different process
... need to figure out how sites can signal to a browser that they are importnat and should be a separate process
... i.e., don't expose me to universal CSRF

annevk: Moz mostly interested in running a document in it's own process
... there is a sig. number of 32-bit computers out there
... allocating large buffers can run into address exhaustion problem
... ran into it with Unity (?) who wants to get more games on the web
... they don't want double-keying
... but separate processes
... add some flag, [?]

mkwest: talk about containers project

annevk: containers is browser-in-a-browser idea
... paper just linked to
... open a new container tag, won't be logged into FB anymore, for example
... everything has a container key (an extra key) added
... separate connection pool, etc.

mkwest: user-facing feature
... part of inspiration here was to take the user-facing feature and make it a dev feature
... something here would be pretty valuable

<mkwst> https://mikewest.github.io/origin-policy/

mkwest: may tie this to another proposal origin policy

Leonardo: DPUB...
... we don't want one book/document to influence another book/doc
... don't want sharing of local storage

mkwest: that's an interesting use-case
... probably better served by sub-origin
... multiple books on a single origin… book1.books.com book2.books.com

<anssik> https://w3c.github.io/webappsec-suborigins/

Leonardo: don't understand the diff between iso and sub-origins

mkwest: iso proposes to isolate an origin entirely
... we have SOP
... evil.com can't get example.com's storage, but can open, post messages, etc.

dbaron: to summarize: this is about making the restritions of SOP stronger
... suborigins is about dividing the origins more finely

mkwest: my goal is that we want to make sure folks don't have to build Chrome apps
... what do folks want to do?

mikeo'neil: what about the origin policy?

mkwest: idea about origin policy is to set properties for an origin instead of a resource
... can set a CSP for a document, but doesn't have any impact on the origin itself
... other headers, HSTS, have origin-wide impact delivered by a resource

<wseltzer> mkwst: think of a manifest for an origin

mkwest: origin policy defines a manifest for an origin
... and a set of headers pinned to the origin
... lives in a WK location
... e.g., go to example.com… here's the document, go get this manifest file (synchronous request)
... think this should be good with h2 and PUSH
... make rq, parse manifest

<wseltzer> https://mikewest.github.io/origin-policy/

<wseltzer> mkwst: this is origin-based, not resource-specific

<wseltzer> ... should probably update the navigation proposed

<wseltzer> Dom: synchronous? like XHR?

<wseltzer> mkwst: async, but blocks navigation

<wseltzer> ... navigation does not complete until you get a response

<wseltzer> ... the resource you're requesting has response headers that assert sthg about manifest

<wseltzer> ... that tells browser to get manifest (from cache, from push, from server)

<wseltzer> ... apply it to response befor you return from navigation/fetch

<wseltzer> ... I think it would be ok to apply to subresources, but room to argue

<wseltzer> Dom: that's the kind of reassurance was looking for

<wseltzer> bz: I have a page iwth a bunch of imges. One gets the header, does it block the other images?

<wseltzer> ... I think that will cause interop problems

<wseltzer> mkwst: goal, that this is something origin asserts when you nav to the homepage

<wseltzer> ... compare HSTS

<wseltzer> bz: failure modes if you don't apply STS might be worse

<wseltzer> mkwst: open to discussion

<wseltzer> ... something in the response causes policy to be applied

<wseltzer> .. might be ext resource

<wseltzer> leonardo: suborigins?

<wseltzer> mkwst: yet to be determined

<wseltzer> ... Subdomains are separate origins.

<wseltzer> annevk: when are you shipping this?

<wseltzer> mkwst: it's lots of work. I hope Moz can get there quickly from containers

<wseltzer> ... not shipping tomorrow

<wseltzer> AdrianHB: Can a server ask a browser if it supports?

<wseltzer> ... e.g. very important bank wants to know or tell you to dl the app

<wseltzer> mkwst: not yet. possibly header

<wseltzer> mkwst: I think it's the case htat there are browsers that can't do process separatation; and chrome isn't going to guarantee process separation

<wseltzer> mkwst: defense in depth

<wseltzer> ... this doesn't substitute for CSRF protection

<wseltzer> ... EPR didn't go far because people didn't like its relation to linkability on the web

<wseltzer> ... hope this proposal has more support because server rather than UA-forcing

<wseltzer> ... possibilities, make this a new element in foreign fetch

<wseltzer> ... trying to respond to needs and keep webby properties

<wseltzer> bz: how do you provide protections in such a way that they're useful if not everyone is on a freshly minted browser

<wseltzer> mkwst: couch it in properties we already have, e.g. x-frame-options, but can't block headers

<wseltzer> ... maybe isolation proposal just becomes a collection of small things

<wseltzer> bz: assuming you don't want to mint a new protocol

<wseltzer> mkwst: that's worse, would completely break compatibility

<wseltzer> @@: restrictions on navigations? post different from get?

<wseltzer> mkwst: they're both dangerous. servers clearly don't consider get idempotent

<wseltzer> ... if we leave it up to the server, via preflights or foreign fetch

<wseltzer> ... or limited declarative policy, but wouldn't treat get/post differently

<wseltzer> annevk: even post needs to be implemented retry-safe

<wseltzer> bz: can't the server always return an error page?

<wseltzer> ... what do they want to know that they don't know now to make that decision?

<wseltzer> mkwst: origin headers not sent, form posts in firefox, e.g.

<wseltzer> annevk: we basically need a new origin header

<wseltzer> ... because the current one is mostly used for CORS

<wseltzer> mkwst: cases where origin info is missing

<wseltzer> ... foreign fetch might give what they need

<wseltzer> annevk: foreign fetch isn't quite settled yet

<wseltzer> ... Apple has different cookie storage policy

<wseltzer> mkwst: hard to know what it means for suborigins and cookies

<wseltzer> ... one idea: subkey cookies

<wseltzer> ... what does that do to OAUTH flows

<wseltzer> ... killing auth makes it difficult for google to use

<wseltzer> @@: app manifest

<wseltzer> mkwst: might well be possible to merge them

<wseltzer> ... a few design differences

<wseltzer> bz: fail open, closed, or up to the server

<wseltzer> ... foreign fetch fails open

<wseltzer> ... origin header, leaves to server

<wseltzer> ... which do we want here?

<wseltzer> mkwst: several new features, we've said are optional on the client

<wseltzer> AdrianHB: If I can ask you to spawn new processes, that's an attack vector

<wseltzer> annevk: at what level do you need to know it doesn't work

<wseltzer> mkwst: possible where in the process that service worker comes in

<wseltzer> mkwst: you don't necessarily know at request time whether you have a process free

<wseltzer> ... private repo, I'll probably move it to WICG

<wseltzer> ... discuss in webappsec

<wseltzer> ... issues in the github repo

- DRAFT -

SV_MEETING_TITLE

21 Sep 2016

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output