> With webviews however, that model doesn't make much sense: the embedder is controlling the webview and frequently needs to apply or enrich the embedded view.
This isn't necessarily the case - it's certainly often been the assumption, but I don't think maintaining status quo here is a self-evident good.
Common case: I click a link in an email client / social media feed and it opens in a webview controlled by that app. It's a 3rd-party link either sent to me by an email contact, or posted by some private individual using the social media platform: it's not necessarily owned/controlled by the developer of the app, and as a user, I have no strong desire for the app to have direct access to that content.
The iframe comparison fits quite well in my mind, and most of the concerns / ideals hold true.
How do you restrict one use case and not another? If a restriction is opt-in in a standard it's not useful.
With webviews however, that model doesn't make much sense: the embedder is controlling the webview and frequently needs to apply or enrich the embedded view. Browsers (which by and large maintain these webview APIs) have no incentive to stray from the web model of security though: they have no use for it themselves and it creates new vectors for security breaches in them. So I wonder how much a community group can affect.
[1] I build a browser for devs which uses webviews, https://polypane.app