Note: We're also considering treating each file:// URL as its own site (see issue 780770).  That may suggest that we need to special case file:/// origins in the origin lock checks.  I'll take a closer look as we make progress on issue 780770.

It seems that we are observing the same error on ToT if we try to sign in into a simualted chromeos run (chrome --login-manager).

My args.gn:
target_os="chromeos"
is_component_build = true
is_debug = false

Then I run with
out/Default/chrome --login-manager  --user-data-dir=/tmp/chrome$RANDOM

I proceed to the sign-in screen and enter a username; after pressing Enter the renderer displaying gaia exits and I get
[77963:77963:1206/145849.678642:ERROR:render_process_host_impl.cc(4145)] Terminating render process for bad Mojo message: Received bad user message: Access denied for localStorage request                                                                                      
[77963:77963:1206/145849.678691:ERROR:bad_message.cc(23)] Terminating renderer for bad IPC message, reason 123

RE: #c2

This bug (kills for file:// URLs) has been present for a while.  I've just verified that the CrOS issue is a recent regression caused by r521838.  Let's track the new regression in a separate issue 792500 that I've just opened.  I'll go ahead and revert the CL causing the regression.

See issue 792413 for how these crashes look and how they affect Windows Canary 65.0.3286.0 as well.

Currently Blink commits  all of file:///dir/file, file://host.com/dir2/file2, file://bar.com/dir3/file3 as the same file:// origin.  This might be something we want to discuss and/or change in the future, but for now treating these URLs as the same origin is a fact of life.

We want web pages to have the same behavior (and to be able to synchronously script the same set of frames / URLs) with and without --site-per-process.  To avoid changing the behavior URLs that commit with the same origin in Blink need to have the same site_url in //content.  To achieve this, I plan to tweak SiteInstance::GetSiteForURL so that it returns site_url="file:" when given "file://host.com" as an argument:

diff --git a/content/browser/site_instance_impl.cc b/content/browser/site_instance_impl.cc
index 827e674ce71c..bdfc6fadec92 100644
--- a/content/browser/site_instance_impl.cc
+++ b/content/browser/site_instance_impl.cc
@@ -410,7 +410,7 @@ GURL SiteInstance::GetSiteForURL(BrowserContext* browser_context,
   }
 
   // If the url has a host, then determine the site.
-  if (!origin.host().empty()) {
+  if (!origin.host().empty() && origin.scheme() != url::kFileScheme) {
     // Only keep the scheme and registered domain of |origin|.
     std::string domain = net::registry_controlled_domains::GetDomainAndRegistry(
         origin.host(),
diff --git a/content/browser/site_instance_impl_unittest.cc b/content/browser/site_instance_impl_unittest.cc
index efcc82fe7515..b46b060f6ef7 100644
--- a/content/browser/site_instance_impl_unittest.cc
+++ b/content/browser/site_instance_impl_unittest.cc
@@ -332,10 +332,13 @@ TEST_F(SiteInstanceTest, GetSiteForURL) {
   EXPECT_FALSE(site_url.has_host());
 
   // Some file URLs have hosts in the path.
+  // For consistency with Blink (which maps *all* file: URLs into file://
+  // origin) such file URLs still need to map into file: site URL.
   test_url = GURL("file://server/path");
   site_url = SiteInstanceImpl::GetSiteForURL(nullptr, test_url);
-  EXPECT_EQ(GURL("file://server"), site_url);
-  EXPECT_EQ("server", site_url.host());
+  EXPECT_EQ(GURL("file:"), site_url);
+  EXPECT_EQ("file", site_url.scheme());
+  EXPECT_FALSE(site_url.has_host());

This issue blocks  issue 770239  - tightening of CanCommitOrigin, by comparing the committed origin with the current origin lock.  Today, when running ClientSideDetectionHostTest.TestPreClassificationCheckNoneHttpOrHttpsUrl from unit_tests, we lock the origin of the process to a site_url=file://host.com/ - after tightening CanCommitOrigin we would kill the renderer when it tries to commit an origin that doesn't match the origin lock - !CanCommitOrigin; origin = file://; site_url = file:///; policy->GetOriginLock(GetProcess()->GetID()) = file://host.com/

+mkwst@ as an FYI / to shout if my plan above has any bad interactions with the overall plans for file: URLs/origins (e.g. related to  issue 793074 ).  I think that my plan above (to get browser-side site_url to agree with renderer-side origin) is still desirable (at least in the short-term, until we start tweaking how renderer-side treats file: URLs).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/48097c48e97b6ce5240d7ce947bea63416fb53d4

commit 48097c48e97b6ce5240d7ce947bea63416fb53d4
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Fri Dec 15 00:23:38 2017

Site URL for file://<host>/... needs to match renderer-side origin.

The site URL is used in browser-side isolation enforcements and compared
against the origin requested by the renderer (e.g. when a renderer
tries to open localStorage for an origin, or [in the future -
https://crrev.com/c/769647] when a renderer wants to commit a navigation
with a specific origin).

Before this CL, browser-side isolation enforcement code would calculate
site URL for file: URLs as follows:
1. file:///home/lukasza/file.txt => site url = file:
2. file://localhost/home/lukasza/file.txt => site url = file://localhost/

Behavior before this CL was problematic, because the origin requested
by the renderer is the same in both cases above - this means that the
requested origin doesn't match the site URL in the 2nd case (and this
leads to renderer kills, like the one observed in
 https://crbug.com/776160 ).

This CL changes how site URL is calculated by the browser process.
After the change, the same site URL (file:) is used for both the cases
outlined above.  Because of this change, the browser-side and
renderer-side notion of the origin is kept in sync (and we avoid
renderer kills).

Bug:  776160 
Change-Id: I99ce397fede346b2278f053e0fa01e8e314741e2
Reviewed-on: https://chromium-review.googlesource.com/827550
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524255}
[modify] https://crrev.com/48097c48e97b6ce5240d7ce947bea63416fb53d4/content/browser/dom_storage/dom_storage_browsertest.cc
[modify] https://crrev.com/48097c48e97b6ce5240d7ce947bea63416fb53d4/content/browser/site_instance_impl.cc
[modify] https://crrev.com/48097c48e97b6ce5240d7ce947bea63416fb53d4/content/browser/site_instance_impl_unittest.cc

Commit 48097c48... initially landed in 65.0.3295.0.  I cannot repro the original problem in the 65.0.3295.0 canary on Mac (note that on Windows the first repro step won't work - navigating to file://localhost/ returns ERR_FILE_NOT_FOUND).