Describing compromised renderer threat model for the DevTools frontend.

Bug: 1015882
Change-Id: I4cd7d39808c4e2ac6df1d159fe91da8803f5209d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2216598Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#772424}

docs/security/compromised-renderers.md

@@ -388,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.).