Thanks for filing!  What would be your use case for excluding a particular site from site isolation?  For isolating specific sites, one would typically want to list sites that need to be protected the most (e.g., Google's enterprise policy would want to include google.com rather than exclude it), so I'm curious whether you want to opt certain sites out because you somehow know they won't benefit from site isolation, they are too slow/buggy with it, or something else?

I also suspect exceptions won't accomplish what you're looking for in many cases (e.g., if you're using it to work around functional issues with out-of-process iframes).

As an example, suppose you isolate everything but foo.example.com.  Chrome will still create out-of-process iframes if some other isolated site (e.g., example2.com, or even example.com itself) contains an iframe to foo.example.com, because those sites aren't allowed to share a process with the non-isolated sites from the exception list.

Hi Alex.

I manage our security and policies at our firm, so from 30 years of experience, I just know that an exception will need to be made at some point.  I almost needed one today.

In late December and early January we applied all of the patches for meltdown and spectre.  Along with the patches, we also applied the Site Isolation policy for Chrome.

Today I was asked to disable the site isolation policy so that we could test a problem we were having with one of our cloud service websites.  Fortunately, Site Isolation was not the issue, so I was able to re-enable the policy.

Had the problem actually been caused by the site isolation policy, I would have been left  with no choice but to disable for all sites.  As you stated, this isn’t really the security stance that is optimal.  This is an example where an exception would be needed... continue with isolation for all sites, except the one that is causing trouble.

The opposite policy for Origins wouldn’t be effective either because we would need to add hundreds or thousands of domains to that policy, and simply omit the single site that has problems with Site Isolation.  That would be too difficult to manage.  The Origins policy is great for enabling one site at a time for testing and developing your own corporate web services, but not really something that can be used for managing an entire enterprise across multiple cities.

It’s possible that I’m misunderstanding how the origins policy functions, but I think the ultimate goal is have site isolation enabled for all sites as an enterprise default, but then be permitted to exclude a mission critical site that might not function properly with the site isolation policy enabled.

I guess I would like to see site isolation treated the same way as extensions in an enterprise - all extensions blocked, until properly vetted and added to the chrome white list policy of allowed extensions.  To me it makes sense to have site isolation behave the same way - Cross site scripting, memory usage, and processes are all sandboxed via Site Isolation by default via the policy, but a specific site or two can be excluded until they can update their code.

As you stated, the exceptions additions would be used only for rare or specific circumstances where that site doesn’t function properly with Site Isolation enabled.  As it stands now, if there is a problem with any particular site, I have no way to exclude it, so I would be forced to disable Site Isolation entirely to address the problem with that single site.

Using the other origins policy would be too broad to manage.  I could add MS, google, apple, and our corporate domain to the origins policy to enable Site Isolation, but then the thousands of other domains that our end users access will not be protected by the site isolation feature.

So that’s why I was asking for this feature.  Does my explanation of a use case make sense?

Sent from my iPad

Yes.  Your explanation here is valid.  As you stated, you would need to add all components to the exception, such as adding both example.com and example2.com to exclude all frames from site isolation.

I suppose I’m approaching this from an administrator standpoint... I would like to have site isolation enabled for all domains (known and unknown) as an enterprise default, but then have the ability to exclude one or more domains as needed should a problem arise.

I responded to the other email as well and gave some use case examples.  I had to turn off the policy today to test a problematic site.  Fortunately site isolation was not the cause of the issue, so I was able to re-enable the policy.  If it was the cause of the malfunction, I would have been forced to leave the site isolation policy disabled for all sites.  This is where an exceptions policy would be beneficial.

Using the Origins policy to enable for specific sites would be too broad to manage in an enterprise.  We could easily add our domains to that policy, but that wouldn’t do anything for other sites that end users visit, such as their personal banking site.  We would want site isolation to be enabled for that as well, even though it’s not an enterprise resource that we’re protecting.

So that’s why I thought it would make sense to allow exceptions to global site isolation policy instead of using the origins policy to enable site isolation only for the specific sites added.

You guys are awesome and make the best browser in the world, so I’ll defer to your better judgement... I was just providing a suggestion based on my 30 years of experience with managing corporate networks and security policies... the ability to have an exception to the global policy makes sense, because inevitably, there will be a need for an exception at some point.  One could argue that the best course of action would be to stop using the effected/insecure site, but that’s not always an option as an immediate solution.  The exceptions would be an immediate solution to that service (while you research a replacement), and it wouldn’t require you to disable site isolation for other sites that don’t have an issue.  Current site isolation policies don’t allow for that level of granularity.

I hope my input helps to make a better product for all.  As most places, when we roll out Win10 later this year, Chrome will be the default browser and not IE or Edge.  Due to that, I thought it would a good idea to share with you my concerns about this policy not have an exclusions section should we run into a problematic site or domain.

Thanks for taking the time to review my request, and keep up the great work!

Sent from my iPad

Thanks for the detailed replies!

We're still discussing how to approach this, but there would be some tricky issues to address.  It seems like we could take one of two approaches:

1) Listing a site as an exception means we would not try to give it a dedicated process.
As mentioned, this has the downside that it does not guarantee that the site will not end up with out-of-process iframes or appear in an out-of-process iframe, which is the most likely source of functional problems right now.  Administrators would also need to list any sites it embeds (including cross-site ads, videos, maps, etc) which might otherwise require dedicated processes of their own, and vice versa if the exception site is ever embedded in other sites' pages.  This may be temporarily useful in some cases, but I suspect it would be hard for administrators to enumerate this list and understand the implications.  Additionally, we're rushing to get the known issues fixed as quickly as possible anyway to eliminate the need for exceptions.

2) Listing a site as an exception means we would prevent it from having out-of-process iframes.
This would be simpler to specify for administrators, but it would require degrading the security guarantees of other sites that normally expect to have dedicated processes.  For example, if a Google Map were embedded in a site on the exception list and thus had no out-of-process iframe, then the Site Isolation protection would no longer apply to google.com.  This would also be quite a bit harder to build.

It's possible we may still want to pursue one of these options, but right now we're focusing on fixing the known issues to make it possible to enable everywhere without concern.  I'll post an update once we get a chance to discuss further.  Thanks again for your input and reasoning!

 Issue 807460  has been merged into this issue.

I opened  Issue 807460  (which was merged into this Issue) and afterwards had an epiphany as I was trying to explain to my peers what I initially perceived as a Blacklist of domains to use Site Isolation on.

As explained in the discussion thread on this issue, the intention is to provide a list of web domains that _need_ extra protection; and to use Site Isolation to put a better fence around a finite list of web domains that need their data protected.

I would recommend updating the "How To Configure" section of http://www.chromium.org/Home/chromium-security/site-isolation to better explain the reason behind "Isolating Certain Sites" - because the significance of the current statement "we recommend including any site that you log into on the list" was overlooked.

Thank you!
 

Comment 7: Thanks for the suggestion!  I've updated http://www.chromium.org/Home/chromium-security/site-isolation#TOC-2-Isolating-Certain-Sites accordingly.

 Issue 819074  has been merged into this issue.

Thanks again for the comments and feedback on this issue.  We've launched Site Isolation for all desktop users in Chrome 67 (https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html), including isolation of all sites (--site-per-process).  At this point, we're interested in fixing any incompatibilities as they arise, rather than adding ways to disable.

Given that and the challenges in comment 5 about how to define an exception, I'm going to close this issue.  Please do file bugs if you encounter issues with Site Isolation on web sites, and we'll try to get them fixed.  Thanks!