Update documentation for <webview> site isolation.

Various places in our documentation currently reference the lack of
site isolation in <webview> tags.  Update all such places now that
site isolation for <webview> is available.

Bug: 1267977
Change-Id: I50094307c63fc621b96e5833274035f2a9694739
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4385895
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1126059}

docs/process_model_and_site_isolation.md

@@ -171,7 +171,7 @@ logged in via an OAuth provider, or encountered a Cross-Origin-Opener-Policy
 ### No Site Isolation
 
 _Used on: Low-memory Chrome for Android (<2 GB RAM), Android WebView, Chrome for
-iOS, Chrome Apps `<webview>`._
+iOS._
 
 On some platforms, Site Isolation is not available, due to implementation or
 resource constraints.
@@ -185,8 +185,6 @@ resource constraints.
   out-of-process iframes.
 * Chrome for iOS uses WebKit, which does not currently have support for
   out-of-process iframes or Site Isolation.
-* The `<webview>` tag in Chrome Apps does not yet support Site Isolation.  See
-  bug [1267977](https://crbug.com/1267977).
 
 
 ### Origin Isolation
@@ -422,11 +420,10 @@ affect invariants or how features are designed.
     This implementation currently relies on hosted apps.
 * **GuestView**: The Chrome Apps `<webview>` tag and similar cases like
     MimeHandlerView and ExtensionOptionsGuest embed one WebContents within
-    another. These may use a different process model, such as `<webview>` not
-    yet supporting Site Isolation. (See bug
-    [1267977](https://crbug.com/1267977).) Note that Chrome Apps allow
-    `<webview>` tags to load normal web pages and the app's own `data:` or
-    `chrome-extension://` URLs, but not URLs from other extensions or apps.
+    another. All of these cases use strict site isolation for content they
+    embed. Note that Chrome Apps allow `<webview>` tags to load normal web pages
+    and the app's own `data:` or `chrome-extension://` URLs, but not URLs from
+    other extensions or apps.
 * **Sandboxed iframes**: Documents with the sandbox attribute and without
     `allow-same-origin` (either iframes or popups) may be same-site with their
     parent or opener but use an opaque origin. Chromium currently keeps these

docs/security/compromised-renderers.md

@@ -61,8 +61,6 @@ from each other and from other sites.
 **Known gaps in protection**:
 - No form of Site Isolation is active in Android WebView.
   See also https://crbug.com/769449.
-- No form of Site Isolation is active in content hosted within
-  `<webview>` HTML tags.  See also https://crbug.com/614463.
 - Frames with `<iframe sandbox>` attribute are not isolated
   from their non-opaque precursor origin.
   See also https://crbug.com/510122.

docs/security/side-channel-threat-model.md

@@ -212,28 +212,6 @@ exploits will be effective at scale.
 Even so,
 [we might want to consider teaching CORB about Flash flavour of CORS](https://crbug.com/816318).
 
-##### All Frames In A `<webview>` Run In The Same Process
-
-[`<webview>`s run in a separate renderer
-process](https://developer.chrome.com/apps/tags/webview), but that single
-process hosts all frames in the `<webview>` (even with Strict Site Isolation
-enabled elsewhere in Chrome). Extra work is needed to fix this.
-
-Mitigating factors:
-
-* `<webview>` is available only to Web UI and Chrome Apps (which are deprecated
-  outside of Chrome OS).
-* `<webview>` contents are in a separate storage partition (separate from the
-  normal profile and from the Chrome App using the `<webview>` tag). The Chrome
-  App is also in an additional separate storage partition.
-
-Chrome WebUI pages must not, and Chrome Apps should not, use `<webview>` for
-hosting arbitrary web pages. They must only allow a single trustworthy page or
-set of pages. The user already has to trust the Chrome App to do the right thing
-(there is no Omnibox, for example) and only take the user to safe sites. If we
-can’t enforce this programmatically, we may consider enforcing it through code
-review.
-
 ##### Android `WebView`
 
 Android `WebView`s run in their own process as of Android O, so the hosting

docs/webui_explainer.md

@@ -1181,8 +1181,7 @@ avoid making the policy more permissive than strictly necessary.
 
 Alternatively, a `<webview>` tag can be used, which runs in a separate
 StoragePartition, a separate frame tree, and restricts postMessage communication
-by default. However, `<webview>` does not support Site Isolation and
-therefore it is not advisable to use for any sensitive content.
+by default. Note that `<webview>` is only available on desktop platforms.
 
 ## JavaScript Error Reporting