BASELINE: Update Chromium to 85.0.4183.14085-based

Change-Id: Iaa42f4680837c57725b1344f108c0196741f6057
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>

4 files changed, 59 insertions, 10 deletions

diff --git a/chromium/docs/security/OWNERS b/chromium/docs/security/OWNERS
index e30cc23542f..1ea372401d2 100644
--- a/chromium/docs/security/OWNERS
+++ b/chromium/docs/security/OWNERS
@@ -6,6 +6,7 @@ felt@chromium.org
 mmoroz@chromium.org
 nasko@chromium.org
 meacer@chromium.org
+mkwst@chromium.org
 palmer@chromium.org
 parisa@chromium.org
 rsesek@chromium.org
diff --git a/chromium/docs/security/compromised-renderers.md b/chromium/docs/security/compromised-renderers.md
index 6733e1384e6..5b21ec9ebb6 100644
--- a/chromium/docs/security/compromised-renderers.md
+++ b/chromium/docs/security/compromised-renderers.md
@@ -245,9 +245,13 @@ Compromised renderers shouldn't be able to poison the JavaScript code cache
 used by scripts executed in cross-site execution contexts.
 
 Protection techniques:
-- Partitioning the code cache by Network Isolation Key (NIK).
-- Using `CanAccessDataForOrigin` in
+- Validating origins sent in IPCs from a renderer process by using
+  `CanAccessDataForOrigin` in
   `CodeCacheHostImpl::DidGenerateCacheableMetadataInCacheStorage`.
+- Using trustworthy, browser-side origin lock while writing to and fetching from
+  the code cache by using `ChildProcessSecurityPolicyImpl::GetOriginLock` in
+  `GetSecondaryKeyForCodeCache` in
+  `//content/browser/renderer_host/code_cache_host_impl.cc`
 
 
 ## Cross-Origin-Resource-Policy response header
@@ -384,3 +388,24 @@ below.
   processes on Android (for example affecting protections of CORB, CORP,
   Sec-Fetch-Site and in the future SameSite cookies and Origin
   protections).  See also https://crbug.com/891872.
+
+
+## Renderer processes hosting DevTools frontend
+
+If an attacker could take control over the DevTools frontend then the attacker
+would gain access to all the cookies, storage, etc. of any origin within the
+page and would be able to execute arbitrary scripts in any frame of the page.
+This means that treating the DevTools renderer as untrustworthy wouldn't in
+practice offer additional protection for the same-origin-policy.
+
+Because of the above:
+
+- Chrome ensures that the DevTools frontend is always hosted in a renderer
+  process separate from renderers hosting web origins.
+- Chrome assumes that the DevTools frontend is always trustworthy
+  (i.e. never compromised, or under direct control of an attacker).
+  For example, when the DevTools process asks to initiate a HTTP request on
+  behalf of https://example.com, the browser process trusts the DevTools
+  renderer to claim authority to initiate requests of behalf of this origin
+  (e.g. attach SameSite cookies, send appropriate Sec-Fetch-Site request header,
+  etc.).
diff --git a/chromium/docs/security/sheriff.md b/chromium/docs/security/sheriff.md
index 897fa7a5cd9..c4418c980fe 100644
--- a/chromium/docs/security/sheriff.md
+++ b/chromium/docs/security/sheriff.md
@@ -248,11 +248,12 @@ the assessment? Be especially on the lookout for Highs that are really
 Criticals, and Lows that are really Mediums (make sure to account for process
 types and sandbox boundaries).
 
-For V8 issues, it can be hard to identify the correct security severity. If
-you're not sure, please take your best guess, and add the
-`Security_Needs_Attention-Severity` label alongside the regular
-`Security_Severity-*` label. If you do this, the V8 team will check the
-severity later and change it if necessary.
+For V8 issues, it can be hard to identify the correct security severity.
+Always set the severity to High unless there's strong evidence of an obvious
+mitigation. Please add the `Security_Needs_Attention-Severity` label alongside
+the regular `Security_Severity-*` label. If the bug is not exploitable, or is
+mitigated, the V8 team will reduce the security severity (to avoid unnecessary
+risk of merging the bug into stable branches).
 
 #### Step 3. [Label, label, label](security-labels.md).
 
diff --git a/chromium/docs/security/side-channel-threat-model.md b/chromium/docs/security/side-channel-threat-model.md
index 05f34b035bf..888baad3ce9 100644
--- a/chromium/docs/security/side-channel-threat-model.md
+++ b/chromium/docs/security/side-channel-threat-model.md
@@ -341,12 +341,34 @@ clocks, and we want the OWP to be able to support them.
 
 ### Gating Access To APIs That Enable Exploitation
 
+We want to support a powerful web, though we recognize that some kinds of APIs
+a powerful web requires are more likely than others to facilitate exploitation,
+either because they can be used as very high-resolution timers
+(`SharedArrayBuffer`), or because they provide powerful introspection
+capabilities (`performance.measureMemory`). We can mitigate the risks these APIs
+pose by exposing them only in contexts that have opted-into a set of
+restrictions that limits access to cross-origin data.
+
+In particular, [`Cross-Origin-Opener-Policy` (COOP) and
+`Cross-Origin-Embedder-Policy` (COEP)](https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit)
+seem promising. Together, these mechanisms change web-facing behavior to enable
+origin-level process isolation, and ensure that cross-origin subresources will
+flow into a given process only if they opt-into that usage. These properties
+give us a higher degree of confidence that otherwise dangerous APIs can be
+exposed safely, as any attack they enable would only gain access to same-origin
+data, or data that explicitly asserted that it accepted the risk of exposure.
+
+Both COOP and COEP are enabled as of M83, and we [plan to require both before
+enabling APIs like `SharedArrayBuffer`](https://groups.google.com/a/chromium.org/d/msg/blink-dev/_0MEXs6TJhg/F0UduPfpAQAJ).
+Other browsers seem likely to do the same.
+
+#### Other Gating Mechanisms
+
 **Note:** This section explores ideas but we are not currently planning on
 implementing anything along these lines.
 
-Although we want to support applications that necessarily need access to
-features that enable exploitation, such as `SharedArrayBuffer`, we don’t
-necessarily need to make the features available unconditionally. For example, a
+Looking beyond developer opt-ins such as COOP and COEP, we might be able to find
+other ways of limiting the scope of APIs to reduce their risk. For example, a
 third-party `iframe` that is trying to exploit Spectre is very different than a
 WebAssembly game, in the top-level frame, that the person is actively playing
 (and issuing many gestures to). We could programmatically detect engagement and