diff options
Diffstat (limited to 'chromium/docs/security/side-channel-threat-model.md')
| -rw-r--r-- | chromium/docs/security/side-channel-threat-model.md | 28 |
1 files changed, 25 insertions, 3 deletions
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 |