Re: Suborigin update

And we're back on the schedule for tomorrow, so we can discuss some of the
points there :-)
--Joel

On Sun, Nov 15, 2015 at 6:18 PM Joel Weinberger <jww@chromium.org> wrote:

> 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
>>
>