Suborigin update

Hi WebAppSec folks. I believe we're scheduled to discuss Suborigins in part
of our next meeting on Monday. Before that, I wanted to give you a small
update to get you up to speed.

I've been working with Mike West and Artur from Google Security to
understand some real use cases for Suborigins. The design we've been
working on of late is, more or less, to treat Suborigins as much as
possible as a separate origin from the top level origin, with a few notable
exceptions and opt-outs. Here they are (pretty much taken from Artur):

- document.cookie is necessary for applications to keep working without
requiring users to sign into every part of your website separately.
Security-wise it's on par with existing behavior (cookies being shared
between subdomains) so we believe it's a reasonable default. That having
been said, I wouldn't be surprised based on comments from Dev that we'll
eventually want to build an opt-out to give a Suborigins a unique cookie
jar.

- XHR/Fetch and postMessage: These two are likely to generate the biggest
challenge for existing applications and we want to allow applications to
adopt Suborigins without making significant client-side changes (ideally,
no client-side changes at all). You should be able to put your application
in a suborigin by adding the Suborigin header, and possibly whitelisting
your suborigin to access endpoints you currently request with XHR, and get
almost all of the benefit of (sub)origin separation when it comes to XSS.

In the case of XHR/Fetch, our solution is to send a CORS preflight for all
XHR/Fetch calls from a Suborigin, and we'll add a Suborigin header. Then
we'll require that the response has an Access-Control-Allow-Suborigin
header that lists the requesting Suborigin (or, alternatively, a '*'
response to Access-Control-Allow-Origin).

For postMessage, we'll, by default, serialize the Suborigin into the
event.origin field. We'll also provide a separate event.suborigin field to
more easily check that value. However, if that's problematic for some
applications, we'll provide a directive, such as
'unsafe-postMessage-serializatiion' that will leave the event.origin field
on receipt as a regular origin, without the Suborigin serialized into it,
leaving it to check the event.suborigin field on its own.

- localStorage: Every Suborigin gets a fresh localStorage jar. If that's
problematic, can consider a 'unsafe-share-localStorage' directive.

As a strawman example to explain these decisions, imagine an application
Foo hosted at https://www.google.com/foo (which uses XHR, possibly has some
XPC with postMessage, etc). It's self-contained in that its XHRs are sent
only to its own endpoints (namely only to Foo's own servers), and
postMessage is usually sent to other pages in the same app. This XHR and
postMessage design would allow it to maintain its current deployment with
really only changes to the server, and very few changes to the app itself.
Importantly, the app will need to have the cookie because otherwise you'd
stop being logged in and it would suck for usability.

Let us know what you think, and we can discuss on Monday.
--Joel