Questions Needing Answers

[Chris Palmer]

Hi all,

Thanks for coming to the meeting yesterday. I think we made some headway! Now let's make some more. :)

Here's my questions doc from the meeting, in email form:

Who Could/Would Use This?

• Banks, healthcare? (not early adopters though)

• Specific apps (mail, docs, sign-in, …) (likely)

• Social networks? (possibly not? They need composability)

• Authentication providers? (cross-origin OAuth pop-up troubles?)

• …?

Artur made the good point that if we could provide more than just defense against UXSS and Spectre, it could be more compelling to developers. However, just getting any process isolation is hard enough, and perhaps we should focus on a minimum viable product first.

Additionally, Emily asks:

High-level, I think we should clarify which of these 2 problems we're trying to solve (or neither, or both):

1. An opt-in to restrict just enough functionality so that other browsers can implement some form of site isolation
2. A useful isolation feature which happens to restrict enough functionality that other browsers can use it as a signal to opt in isolated sites into some form of site isolation

TODO short-term: CORB? window.open issues? From-Origin response header? (From-Origin request header, possibly?) Put these together, and see if they defend against Spectre, what we gain, what we still lack, et c.

Scope Of Isolation?

• Isolatee is site?

• Isolatee is origin?

• Isolatee is WebKit partition (eTLD+1, scheme not considered) (insufficient for Spectre defense)

• Affiliated domains/friend origins/et c.?

Possible Signalling Mechanisms?

• Header (would apply to entire isolatee after first seen? What about existing resource loads?)

• Well-known URL (would apply to entire isolatee)?

• Origin Manifest? (seems best, but is a dependency that must be resolved first — it is not finished yet)

Definition(s) Of Isolation?

• Separate process/address space (required)

• CORB, and safe-listed headers (required)

• Double-keyed cookies/storage?

• All cookies implicitly SameSite?

• Isolatee cannot be framed?

• Entry point/navigation restrictions?

• From-Origin header?

• …?

Lost Features?

• Isolatee cannot frame other sites/origins?

• No ability to write to document.domain?

• window.opener = null? Unless opener is same as isolatee?

• Cookies for authentication on top-level request if all cookies are strict SameSite

• …?

[Artur Janc]

On Wed, Apr 18, 2018 at 10:04 PM Chris Palmer <pal...@chromium.org> wrote:

Hi all,

Thanks for coming to the meeting yesterday. I think we made some headway! Now let's make some more. :)

Here's my questions doc from the meeting, in email form:

Who Could/Would Use This?

• Banks, healthcare? (not early adopters though)

• Specific apps (mail, docs, sign-in, …) (likely)

• Social networks? (possibly not? They need composability)

• Authentication providers? (cross-origin OAuth pop-up troubles?)

• …?

Artur made the good point that if we could provide more than just defense against UXSS and Spectre, it could be more compelling to developers. However, just getting any process isolation is hard enough, and perhaps we should focus on a minimum viable product first.

I want to touch on this point, because I'm not sure how much sense I made yesterday in the middle of the night, and this is potentially important :)

First of all, I fully agree with the goal of focusing on an MVP for the "on-by-default" aspect of browser Spectre mitigations. It would be great to see CORB deployed in most UAs soon, even if it doesn't protect all resources that might potentially be cross-origin blockable -- if it worked in all browsers only for HTML and JSON, it would already cover a significant chunk of sensitive content on the web. Pretty please make it happen.

Similarly, on the "browser internal" side of on-by-default Spectre mitigations, I'm pretty sure that browsers should first implement process isolation that covers common framing scenarios seen on the web, even if there are known situations where attacks might still happen. For example, almost every sensitive modern application sets X-Frame-Options: SAMEORIGIN, has HTTPOnly auth cookies (the lack of either one is a vulnerability), and has some degree of faith in the resources it iframes (malicious frames can execute many interesting attacks so developers tend to be careful when embedding external content, often putting it in a sandbox). If the initial iteration of process isolation narrows down the attack surface to only legitimately iframed resources, it will be a huge improvement over the status quo. Again, an MVP here sounds like just the right approach.

However, when it comes to the complementary opt-in mechanism that we want to provide to developers to allow them to protect resources not covered by CORB, it is very different. We really need to make sure to build something that developers can, and want to, deploy in their applications  -- otherwise, there is not much point to building the mechanism in the first place. I see this as a case where solving a larger problem ("protect my webapp from infoleaks based on my resources being unexpectedly embedded across origins") may be easier than solving a smaller one ("protect my webapp from Spectre"), for two reasons:

1. Web developers intuitively grasp the concept of request provenance ("my application is the only consumer of its authenticated JSON, images, and text/foo responses; I'll modify it so it can load them, but no-one else"), in part because it's core to the web platform (ekhm, Referer), and in part because they've already had to deal with it for CORS. However, they have no idea about Spectre, and will not know why the magic header or two lines of server-side code that we ask them to add to their apps will protect them from speculative side channel attacks. Since the job of the opt-in mechanism is actually to protect application responses from being exposed across origins -- which is understandable to developers -- we should make the protection match this mental model, rather than focus on a specific attack.

2. The amount of effort to deploy any of the opt-in Spectre mitigations in applications which most benefit from them, i.e. the sensitive, often complex ones, is going to be high. This means that developers will need to justify why doing this is more valuable than other security work. If the mechanism protects not just from Spectre -- the impact of which is probably not yet clear-cut to most developers -- but from several known vulnerability classes that are endemic to the web and familiar to web security folks (XSSI, cross-origin timings such as XS-Search, CSRF), it becomes a much stronger selling point for adopting it.

I think in practice the distinction between "mitigate Spectre" vs. "mitigate cross-origin leaks in general" is less than we might think because the mechanisms we're considering (From-Origin, and a request header identifying the source of the request aka Sec-Site) seem both fairly simple and capable of addressing the more general information leak case. But I wanted to mention this explicitly because, if nothing else, it may influence how we're thinking about these features.

--
You received this message because you are subscribed to the Google Groups "isolation-policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isolation-poli...@chromium.org.
To post to this group, send email to isolatio...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/isolation-policy/CAOuvq23%2BYqsStrZO95psavLHge16H%2BH07PCGxqJn_V0%3DSmb1Eg%40mail.gmail.com.

[Ryosuke Niwa]

Hi Chris,

Thanks for the summary.

Could someone also send us a list of URLs you've encountered the problem when A.com opens B.com with A.com's iframe? You mentioned Facebook used to access subframes directly but what were other websites own which you observed this problem?

We'd like to see if those websites are still broken or not.

- R. Niwa

[Charlie Reis]

Sure, I'll look up some of the bugs we hit in the past with hosted apps and OAuth and share some notes.

Charlie

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/isolation-policy/8C97836B-98D4-4E9A-9B6A-4D96A1931F40%40apple.com.

[Nika Layzell]

On Wed, Apr 18, 2018 at 4:03 PM, Chris Palmer <pal...@chromium.org> wrote:

Hi all,

Thanks for coming to the meeting yesterday. I think we made some headway! Now let's make some more. :)

Thanks for having us! I've put my personal thoughts on a few of the questions you asked in-line here.

 

Here's my questions doc from the meeting, in email form:

Who Could/Would Use This?

• Banks, healthcare? (not early adopters though)

• Specific apps (mail, docs, sign-in, …) (likely)

• Social networks? (possibly not? They need composability)

• Authentication providers? (cross-origin OAuth pop-up troubles?)

• …?

Artur made the good point that if we could provide more than just defense against UXSS and Spectre, it could be more compelling to developers. However, just getting any process isolation is hard enough, and perhaps we should focus on a minimum viable product first.

Additionally, Emily asks:

High-level, I think we should clarify which of these 2 problems we're trying to solve (or neither, or both):

1. An opt-in to restrict just enough functionality so that other browsers can implement some form of site isolation
2. A useful isolation feature which happens to restrict enough functionality that other browsers can use it as a signal to opt in isolated sites into some form of site isolation

I'm inclined to push for #2 over #1 because it will let us justify the limitations to developers & give a more compelling reason for developers to opt-in to our changes than a simple Spectre mitigation will (especially considering that there aren't super public live attacks against browsers currently for Spectre). It might be useful if we could get this to be almost like a web "strict mode"/"https" which we evangelize as good practice, and doesn't prevent useful patterns on the web, it would be excellent for adoption.

That perspective unfortunately likely won't help banks/healthcare due to the early adopter problems, but we weren't likely to get them to change anything anyway.

 

TODO short-term: CORB? window.open issues? From-Origin response header? (From-Origin request header, possibly?) Put these together, and see if they defend against Spectre, what we gain, what we still lack, et c.

I think what we want to do in the short term pre-isolation is probably:

1. Test, standardize, and deploy some form of improved cross-origin resource blocking across browsers.

2. Determine the scope of what the From-Origin response header represents, and what restrictions it places on a network load when that load is for a document.

  - This will likely be guided by both what webpages are able to accept as a compromise, and what is needed for browsers to implement the changes quickly.

  - We need to decide what happens when both CORS and From-Origin are used. For example, if a load of a document would be allowed if it was a cors load, but From-Origin is set, do we allow the load? Does From-Origin override CORS?

    - I'm inclined to think that we want to handle From-Origin for resources by:

      a) If the load uses CORS, ignore the From-Origin header.

      b) If the load is no-cors, and the From-Origin header's requirements are violated, treat the load as though it uses CORS (which will probably cause it not to be delivered).

        - not sure how this would interact with some features of cors. Would have to look into this more.

      c) If the load is no-cors and the From-Origin header's requirements are not violated, allow it as today.

 

Scope Of Isolation?

• Isolatee is site?

• Isolatee is origin?

• Isolatee is WebKit partition (eTLD+1, scheme not considered) (insufficient for Spectre defense)

• Affiliated domains/friend origins/et c.?

I think the level of isolation which we want to push for is probably something along the lines of:

A document's "site" is derived from that document's "origin". The "site" key the 2-tuple of:

  (scheme, eTLD+1)

 

Two documents with different "site" values may never communicate with one another synchronously.

Two documents are never loaded in the same process unless they are related (can hold references to one another) and have the same site. (Gecko calls this a "DocGroup" 'cause we're creative)

For the purposes of From-Origin: the value "same" corresponds to the requesting document, and all ancestor origins, having a identical origin to the requested resource. The value "same-site" corresponds to the requesting document, and all ancestor origins, having an identical site to the requested resource.

-- I think that this is the right choice to make for now, as it handles 'document.domain' (unlike origin), while still preventing http <-> https attacks (unlike just eTLD+1).

Possible Signalling Mechanisms?

• Header (would apply to entire isolatee after first seen? What about existing resource loads?)

I don't think we want to apply this to an entire isolatee, but rather to a single load. I think having persistence on the browser side due to this is confusing. That being said, we should probably all emit diagnostic messages if one resource is loaded with this header set, but another resource is not.

If From-Origin has an impact on the abilities of a document, we might want to allow using <meta> tags to specify From-Origin so long as they are early enough in the document (like charset? It's pretty gross so perhaps not.) I don't know how difficult this would be to implement for other browsers. It may improve adoption if control over headers is not required.

 

• Well-known URL (would apply to entire isolatee)?

We probably can't do this as aggressively as we can with an opt-in solution. If we want to opt some sites in I think we want to think of different restrictions for those sites.

 

• Origin Manifest? (seems best, but is a dependency that must be resolved first — it is not finished yet)

I'm disinclined to put a dependency on Origin Manifest to make this work happen. I'd prefer to at least enable it another way.

 

Definition(s) Of Isolation?

Are we talking about Isolate-Me here or just From-Origin? Some of the questions here don't feel related to the From-Origin header, and rather seem to represent some sort of persistent information about an origin.

I believe that implementing a full per-origin persistent isolation policy might produce unnecessary burdens on teams while they work on implementing site isolation, so I think I'd prefer to stick with the From-Origin proposal for now. This also requires much more spec work than a simple From-Origin header. I'll reply to some of the ideas below as though they were for From-Origin, despite these sections seeming like they're about a persistent whole-origin Isolation proposal.

• Separate process/address space (required)

• CORB, and safe-listed headers (required)

• Double-keyed cookies/storage?

I think that tying this to From-Origin will limit the ability for websites to adopt the changes so I'm inclined to say no. It may be valuable for a full Isolation proposal, but I don't think such a proposal is a viable solution to spectre given how difficult it may be for sites to adopt it.

• All cookies implicitly SameSite?

I think we can probably get away with having cookies set by loading a From-Origin resource being implicitly SameSite. I don't see the immediate value however.

• Isolatee cannot be framed?

• Entry point/navigation restrictions?

• From-Origin header?

• …?

Lost Features?

• Isolatee cannot frame other sites/origins?

I think doing this for From-Origin will prevent people from using the header. Even if it makes things more safe I think we should avoid it. People will have to be careful to not frame sites they don't trust until we get OOP iframes across browsers, but that seems like an acceptable tradeoff.

 

• No ability to write to document.domain?

I think this is probably acceptable if we make From-Origin a website "strict mode"., but it will also get in the way of people using the header.

That being said, it may encourage people who only care about Chrome (which unfortunately do exist) to use the header anyway, as it will improve security even in browsers with full site isolation. 

If we have domain disabled, we can modify the definition of a "site" to reflect that.

 

• window.opener = null? Unless opener is same as isolatee?

I think there are too many uses for cross-origin window.opener (such as OAuth), so we won't be able to get away with this. We can potentially get away with a more restrictive version of what you're allowed to do across dissimilar-origin toplevel browsing contexts though.

 

• Cookies for authentication on top-level request if all cookies are strict SameSite

I'm not sure what this buys us?

• …?

--
You received this message because you are subscribed to the Google Groups "isolation-policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isolation-policy+unsubscribe@chromium.org.

[Artur Janc]

I'd like to +1 this comment and the ones below. Bundling any auxiliary restrictions (on framing, window.opener, etc.) into the mechanisms we see as opt-in protections against cross-origin resource loading would make it harder for developers to adopt them. It would mean refactoring unrelated parts of the application and lead to things breaking in non-obvious ways, and may require removing functionality important for many applications.

One particular concern for From-Origin is that if one UA ships a stricter set of restrictions than others (e.g. to prevent cross-origin framing), applications which cannot meet this requirement will not be able to use From-Origin even in other supporting browsers, because this would break users of the stricter UA. This would be a bad outcome, which we really should avoid.

The auxiliary restrictions may all be valuable, and in some cases necessary to protect the application (though if they depend on each browser's process separation model, it's hard to explain this to developers), and I'm not at all opposed to building them -- the notion of a "strict mode" sounds like a reasonable idea. But let's please decouple this from From-Origin and other resource loading protections.

 

 

• No ability to write to document.domain?

I think this is probably acceptable if we make From-Origin a website "strict mode"., but it will also get in the way of people using the header.

That being said, it may encourage people who only care about Chrome (which unfortunately do exist) to use the header anyway, as it will improve security even in browsers with full site isolation. 

If we have domain disabled, we can modify the definition of a "site" to reflect that.

 

• window.opener = null? Unless opener is same as isolatee?

I think there are too many uses for cross-origin window.opener (such as OAuth), so we won't be able to get away with this. We can potentially get away with a more restrictive version of what you're allowed to do across dissimilar-origin toplevel browsing contexts though.

 

• Cookies for authentication on top-level request if all cookies are strict SameSite

I'm not sure what this buys us?

• …?

--
You received this message because you are subscribed to the Google Groups "isolation-policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isolation-poli...@chromium.org.

To post to this group, send email to isolatio...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/isolation-policy/CAOuvq23%2BYqsStrZO95psavLHge16H%2BH07PCGxqJn_V0%3DSmb1Eg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "isolation-policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isolation-poli...@chromium.org.

To post to this group, send email to isolatio...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/isolation-policy/CAKN_%3DPJinN8BNX5UuEBes-LiJ1r1fqP2EGMhJg1-QtpprefTgA%40mail.gmail.com.

[Charlie Reis]

Forking this thread to discuss the OAuth cases, now that I'm back from traveling. Here's a brief history showing the cases we ran into.

Since about 2010 or so, Chrome has had a "hosted app" mechanism as part of our extension system.  Web developers can upload a simple manifest to the Chrome Web Store including a URL pattern.  If users install the hosted app, Chrome will use a special process for those URLs when they are visited at the top level.  This has some similarities to what we're discussing with From-Origin, though it doesn't block such URLs from being loaded in subframes of other sites, etc.

We ran into problems with hosted apps and Facebook Connect login popups in https://crbug.com/59285, where a large number of sites that used Facebook for login ended up with broken login popups if they were installed as hosted apps.  (There's examples of the sites in the bug if you're curious, but the links are pretty old.)  As explained in comment 29, Chrome would swap to a different (non-hosted-app) process for the top-level Facebook popup.  At the time, Facebook's login flow would navigate back to the original site in the popup and then call a function in window.opener, which was now same-origin with the popup.  We weren't preserving window.opener across process swaps at the time, so window.opener was null and the popup never closed or completed the login flow.

We added a short-term workaround to keep cross-origin popups in the hosted app process, and we removed the workaround after adding support for window.opener after process swaps in https://crbug.com/65953.

However, Facebook changed its login flow in 2011 to send a postMessage from the Facebook popup back to the original site (via window.opener), without navigating to the original site in the popup.  We put the workaround back (keeping Facebook in the hosted app's process) and then added cross-process postMessage support in https://crbug.com/99202.

Unfortunately, Facebook had changed its login flow again, and the Facebook popup was now doing a same-origin script call back to the Facebook iframe within the original site.  The iframe would then postMessage its parent with the result.  This wouldn't work without out-of-process iframes, so we had to rely on the workaround to keep both the Facebook iframe and popup in the same process as the hosted app.  (That workaround is still in place in Chrome, unless Site Isolation is turned on-- in that case we can put the Facebook iframe in an OOPIF.)

Some of these issues came up more recently as well, when we launched isolation of https://accounts.google.com in December.  In https://crbug.com/796912, we found that this isolation broke OAuth sites where a page on site A had an iframe on site B, which opened a popup to site B (in the same process).  The popup navigated to site C, which was an OAuth login on https://accounts.google.com and thus cross-process.  Then it navigated back to site B in the popup.  As explained in comment 11, we were keeping site B's pages in the process with page A at first, but we didn't go back to the process with page A when site C navigated to site B.  We fixed this by comparing the destination URL against the origin of the opener (i.e., B) to see if it needed rejoin that process.  It's a bit of a heuristic but works well enough in practice, and the bug goes away with full Site Isolation since all the B pages are in a B process.  For reference, there was a similar case in https://crbug.com/807184.

Overall, we basically ended up with a model where hosted app processes were a little "sticky."  We try to aggressively swap from a normal web process to a hosted app process on top-level navigations, but we leave cross-origin popups inside the hosted app process to avoid disrupting OAuth cases.  This might be useful for a short-term opt-in approach for Spectre defenses as well, assuming sites don't use window.open to navigate to potentially malicious pages that would share their process.

Note that the reverse direction does matter as well-- if the OAuth provider is the only one that has a hosted app (or opt-in Spectre protection), then we would aggressively swap to a protected process when it's opened as a popup from within a normal page.  That could again break scripting between an iframe and popup.  Of course, I'm not sure how sites like OAuth providers can opt-in to this protection anyway, since they embedded as iframes within a wide variety of sites.

Strawman proposal: OAuth sites could use frame-ancestors or XFO to ensure that they are only iframed by sites they have some agreement with, and which have opted into Spectre protections of their own?  Then we never have a case of "normal process tries to open protected OAuth popup," and we can keep the OAuth popup in the existing protected process.

Anyway, hope that helps with some of the context, things to test, and considerations for the design.

Charlie

[Chris Palmer]

So, is our best next move to revive From-Origin?

With the implicit understanding?, or an explicit addition?, along the lines of, "if the resource has the From-Origin response header and is a top-level document, the UA MAY provide further isolation, such process isolation blah blah, et c."?

[Ryosuke Niwa]

On Apr 20, 2018, at 3:27 PM, Chris Palmer <pal...@chromium.org> wrote:

So, is our best next move to revive From-Origin?

With the implicit understanding?, or an explicit addition?, along the lines of, "if the resource has the From-Origin response header and is a top-level document, the UA MAY provide further isolation, such process isolation blah blah, et c.”?

I don’t think it makes sense to call out implementation fails such as process isolation in the standards.  e.g. some browser vendors may opt to never implement process isolation and implement VM level mitigations.  e.g. there are some hardwares in which process isolations aren’t necessary to protect against Spectre.

- R. Niwa

[Ryosuke Niwa]

Thanks for the detailed description!

--
You received this message because you are subscribed to the Google Groups "isolation-policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isolation-poli...@chromium.org.
To post to this group, send email to isolatio...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/isolation-policy/CAH%2B8MBYgmYoc9uJP-qO8qoYStTXu7NgbMCY7VfyN7Mw7zoup6w%40mail.gmail.com.

[Chris Palmer]

On Fri, Apr 20, 2018 at 3:29 PM Ryosuke Niwa <rn...@apple.com> wrote:

I don’t think it makes sense to call out implementation fails such as process isolation in the standards.  e.g. some browser vendors may opt to never implement process isolation and implement VM level mitigations.  e.g. there are some hardwares in which process isolations aren’t necessary to protect against Spectre.

Sure. That's why I say "MAY" and "such as".

Is reviving From-Origin a good next step, though?

[Ryosuke Niwa]

Yes. We’d like to get From-Origin standardized.

- R. Niwa

[Artur Janc]

On Sat, Apr 21, 2018 at 12:27 AM Chris Palmer <pal...@chromium.org> wrote:

So, is our best next move to revive From-Origin?

With the implicit understanding?, or an explicit addition?, along the lines of, "if the resource has the From-Origin response header and is a top-level document, the UA MAY provide further isolation, such process isolation blah blah, et c."?

If this is going to be completely invisible to developers then treating the presence of From-Origin on the top-level document as a request for the UA to be put in a separate process sounds good. However, if process isolation is likely to affect any web-visible behavior or run into issues similar to what Charlie mentioned on the forked thread, then I would seriously recommend having a separate switch -- which might also allow developers to opt into more restrictions like banning document.domain assignments -- or otherwise adopting From-Origin will be more difficult. 

The second switch would also be useful in a world where we have both a response and a request header (From-Origin & Sec-Site or something along those lines) because applications using information from the request header to protect their resources would be able to explicitly express their preference to be in a separate process.

 

[Chris Palmer]

Can we achieve this by adding an option to From-Origin, or is it better to have a whole new header?

[Artur Janc]

On Thu, Apr 26, 2018 at 8:52 AM Chris Palmer <pal...@chromium.org> wrote: 

Can we achieve this by adding an option to From-Origin, or is it better to have a whole new header?

I think the answer is "yes" to both of your questions ;-) 

Adding the ability to specify an "isolation preference" and/or options to From-Origin would likely work, but it would be slightly awkward for two reasons:

1. If an application is using another mechanism to protect its resources from being loaded cross-origin (e.g. the Sec-Site header or a SameSite cookie), then the developer will need to have identical logic in both places, or otherwise From-Origin might block the UA from reading a response that would be allowed by the other mechanism. For example, if a developer requires the presence of a SameSite cookie to return data from a given endpoint, if she sets a site-wide "From-Origin: same; [options]" header then the response will be blocked if requested from another origin on the same site. This could potentially be solved by something like "From-Origin: *; [isolation-options-here]" which would be a no-op when it comes to resource loading, but signal the isolation preference.

2. If we go with the hypothetical "From-Origin: [resource-loading-allowlist]; [isolation-options-here]" approach, then the header has a different meaning depending on the type of response it applies to. For resources, the part of the header that matters is the allowlist; for documents, the only part that would make sense are the isolation options (I'm assuming that something like breaking document.domain assignments would need to be specified on the document itself). If the header now means two different things in two different contexts, and a different half of its value is ignored on every load, then it's probably a case for splitting it up.

That said, I'm sure there are important considerations here that I'm ignorant of, and that smarter people who actually work on browsers might have more informed opinions ;-)