Re: Suborigin update

First of all, it appears I may have my dates mixed up, and I don't think
we'll be discussing Suborigins at tomorrow's meeting. But I'm still glad we
have this conversation going :-)

Many comments to respond to, so I'll try to go through them. Jas's comments
first. Thanks for the points! I meant to cover a few of them, and I just
didn't think of it.

   - Re: Workers and Service Workers- Workers from a Suborigin will be
   treated as belonging to the Suborigin tuple, not the Origin tuple. Our
   proposal for SWs for now is special. Namely, Suborigins cannot install
   them, and SWs installed by an Origin can still intercept requests/responses
   to/from the Suborigin, but we'll definitely need input from an SW expert to
   solidify this.
   - Re: X-Frame-Options: We haven't explicitly discussed this, so I'm
   certainly open to suggestions. My offhand suggestion would be to apply any
   X-Frame-Options to an Origin tuple to all Suborigin tuples with match
   scheme/host/port. This seems simplest for backwards compatibility.
   - Re: document.domain: I believe we discussed simply disabling the
   setting of document.domain from a Suborigin, but again, this was more
   offhand discussion than anything.

To Anne's comment on localStorage: I certainly think that disabling
localStorage is a sensible place to start, although it's not hard to
imagine many applications needing it to be useful.

To Dev's comment on cookies:
I like the suggestion of an unsafe-cookie as a mandatory v1 opt-in, since,
I agree, there are other setups that can be useful in the future. Can you,
perhaps, help us outline precisely the set of requirements around cookie
setting and reading that you think would be reasonable? I believe from
Artur's perspective, he *does* want readable cookies, but I'll have to let
him speak for himself on this one, since offhand, it does sound like
sending the cookies without a readable document.cookie makes sense.

To Dev's comments on preflights:
I think you're right that we should probably only do it for complex
requests. Yes, it's a big hammer for XHR and Fetch, but unfortunately we
couldn't think of a better way to do it. Since Suborigins are defined upon
response, we can't actually know if a request is safe to make unless the
server tells us it is safe to make. Thus, we need to do a preflight to get
back the Suborigin information for that request.

>From the app's perspective, it has to assume that the browser is *not*
running in a Suborigin enabled browser, since who knows which browsers will
support it. However, the idea should be that if they always send Suborigin
headers they should get the Suborigin separation *if* they browser supports
it.

Dev, can you clarify your question about '*' responses and withCredentials?
I don't quite follow it.
--Joel

On Sat, Nov 14, 2015 at 1:26 PM Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> > - 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.
>
> Would a cookie set by top level domain be readable though? That's what
> was I was really not ok with and that is also not par with current
> sub-domain behavior.
>
> Additionally, I like the current sub-domain behavior has been a
> forever source of pain and so extending it doesn't sound like a great
> idea.
>
> I can understand this being a requirement though. I am just not a fan
> of making it the default. Allowing it through some 'unsafe-cookie'
> sort of opt-in (an opt-in we make mandatory in v1) seems more
> reasonable to me.
>
>
> > 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).
>
> This seems a big hammer. While secure, the perf impact of pre-flight
> is terrible and applications go out of their way with some horrible
> hacks to avoid it. At the least, why not inherit existing behavior:
> preflight only for complex requests?
>
> Also, how will * response work? Will the request be sent with a
> cookie? Does the app set request.withCredentials to false? How would
> the app know whether it is running in a browser with subOrigin support
> and needs to set that flag?
>
> > Importantly, the app
> > will need to have the cookie because otherwise you'd stop being logged in
> > and it would suck for usability.
>
> I am still confused why the app needs document.cookie though. The
> cookie is sent with the request.
>
> ~dev
>