Seems related to  issue 809614  and tsepez's work in https://chromium-review.googlesource.com/c/chromium/src/+/915182?  I know jschuh@ had some thoughts on this as well.

For looking into it eons ago, my recollection is that it's in general hard to do, because of a few things (from memory):
1- Flash accesses shared resources (e.g. file system) without explicit locks (just relies on locking inside the Flash process).
2- It also has a cross-instance communication mechanisms, that isn't strictly isolated by origin (https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/LocalConnection.html). IIRC in Pepper Flash it's implemented via a fully in-process mechanism, which would need to evolve to cross-process.
3- somewhat tangentially, for better or worse, Flash's network access policy is not same-origin policy + CORS, but their own mechanism. It's not necessarily a deal breaker to isolate plugin processes, but it would limit the upside.

Not sure whether or not it's possible to break #2 nowadays. I suspect #3 is likely to be needed.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

I want to expand on #3 raised by piman@ in #c3 - the upside/benefits of Site Isolation for Flash seem limited. 
 Currently all network requests from a plugin process are proxied by a renderer process that hosts the plugin.  This means that (even in absence of exploits that lead to arbitrary code execution in plugin or renderer processes) a malicious renderer can use Spectre to read cross-site secrets as they are proxied to the Flash process (and before Flash has a chance to apply its CORS-like crossdomain.xml policy).  This would be true even if we had Site Isolation for Flash.

One way to address this problem would be to have a separate URLLoaderFactory for plugins - one that doesn't proxy data through a renderer process.  This seems complex - see issue 855171 and notes in the attached doc.  This also doesn't protect against Flash exploits that give an attacker ability to execute arbitrary native code within the Flash plugin process.

Another way to address this problem (including the problem of compromised Flash plugin process) would be to teach CORB (Cross-Origin Read Blocking) about Flash's flavour of CORS, but

1) this is also quite complex:

    - This requires to make CORB stateful (i.e. remember the effects of previously seen policy responses).
    - Some enforcements depend on information not available to CORB (i.e. not available outside of the Flash plugin process) - e.g. see "certificate" element
    - The crossdomain.xml-like policy can be provided from any URL, with any Content-Type (see permitted-cross-domain-policies=all VS by-content-type VS by-ftp-filename VS master-only VS none).  In practice we've observed the policy served with a generic application/xml type from some banking sites.  This requires sniffing to passively detect the policy responses.

2) security risk of Flash will go down over time:
   - Flash already requires click-to-play and can be further restricted via enterprise policies (e.g. PluginsBlockedForUrls)
   - Flash deprecation is coming soon - according to https://www.chromium.org/flash-roadmap:
       - Flash will be disabled by default in Chrome 76 / around July 2019
       - Flash support will be removed in Chrome 87 - around December 2020

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

commit 7d706632fc05eea8322a682428ae8903586ba4ba
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Mon Aug 20 15:42:56 2018

Update Flash-related aspects of the Site Isolation threat model.

Bug: 816318,  874515 
Change-Id: I8d165ec355036f8c190bb21e1c50ee8f9b6a4d5a
Reviewed-on: https://chromium-review.googlesource.com/1176389
Reviewed-by: Chris Palmer <palmer@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584459}
[modify] https://crrev.com/7d706632fc05eea8322a682428ae8903586ba4ba/docs/security/side-channel-threat-model.md