Interesting. As someone using webviews extensively[1], the main issue is that the "iframe" model of security many operate on makes sense on the web, but not in native apps. When it comes to embedding third party content with iframes, you essentially want two-way security and privacy. The embedder can't change things in the embedded and vice versa.
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.
> When it comes to embedding third party content with iframes, you essentially want two-way security and privacy. The embedder can't change things in the embedded and vice versa.
> 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.
OP was using that use case as their example, but this is about standardisation so it needs to fit a range of use cases, most importantly the common ones.
How do you restrict one use case and not another? If a restriction is opt-in in a standard it's not useful.
This reminds me, back when I used to do app security, one of the issues with webviews was that some apps would hide much of the UI that users are used to seeing in browsers to make security decisions. So if an attacker could, via some vulnerability, redirect the site being viewed in the webview to one of their choosing, the user wouldn't be any the wiser.
I think it would generally be better if webviews, by default, have restricted navigation, and the developer has to deliberately whitelist domains they wish to view in it. Rather than having to write a navigation delegate or similar to implement their own whitelist, which most developers won't bother with.
The VPN software we used was configured one day to start presenting web view for oauth sign-in with no announcements this would change. The view had no navigation bar. Could not right click and get properties. No way to verify that what was loaded was secure or valid. Whether any of that could be trusted is additional question, but yes, some presentations of web views are terrible.
Because many developers are lazy and rather hardcode their ways into a specific browser instead of Web standards, which WebViews also require to pay attention to.
In 2000 we were already delivering software using Webviews like MSHTML or KHTML.
For context, Instagram, TikTok and Facebook embedded browsers have bigger shares of market than many major browsers. A LOT of web is being consumed in those WebViews. There is also WeChat that is an entire universe of WebViews.
And those players can certainly develop their own WebView formats for their mobile apps. There's no need to change public WebView standards for their needs.
I wonder if this will actually happen, since most webviews are closed source and the work of big corporations? Maybe people like the Electron maintainers can get involved.
I would imagine many of the controlling maintainers are GitHub/Microsoft employees. GitHub created it. Microsoft owns GitHub and has important software built upon Electron.
sounds more like for maintainers from tauri. deno/rust/websymboly capacitorjs PWA group seems got the stuff right in this webview directions than monolitic electron. If we must go the chrome route, then NWJS would also be more preferred than Electron.
The major issue is that there is no cross-platform webview currently.
The main candidate is the official webview shipped on windows, but it is currently lacking linux support
https://github.com/MicrosoftEdge/WebView2Feedback/issues/645...
Linux webviews like e.g. tauri are shit, they use webkit wich leads to platform specific bugs and limitations vs the tauri on windows and more importantly webkit is the new IE, it lacks so many features it's pathetic and has major performance issues, e.g. https://www.phoronix.com/scan.php?page=news_item&px=WebKit-W...
Why can't linux distros get an official chromium webview is beyond me, and those are the same shills that continuously rant about Electron bloat..
Sure there is. JavaFX ships a WebView component (literally called that) which runs on every platform including embedded. It's WebKit-based. You don't like WebKit but at every point in the web's history there were some browsers with more features or fewer bugs than others. If you're writing web apps then you're meant to run on more than one rendering engine.
At any rate there's also JCEF, again for JVM apps.
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