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.

[1] I build a browser for devs which uses webviews, https://polypane.app

> 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 referring to the use case where webviews extend your native mobile app functionality.

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.

Your app looks really handy. Good work.

Looks like this has already been created, back in March?

Here's their charter: https://github.com/WebView-CG/charter/blob/main/charter.md

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.

> No way to verify that what was loaded was secure or valid.

Signed software from your VPN provider isn't enough?

What type of attack, theoretical or otherwise, are you avoiding?

An Oauth request loads an external website. A Network-Level attacker anywhere on the path might try to send the request elsewhere.

"WebView" in software should be preferred over electron, but why it's not the case today?

Because it is bloated, more complicated, and require an insane amount of preparation to get started in a cross-platform fashion, specially for windows: https://docs.microsoft.com/en-us/microsoft-edge/webview2/get...

Then you understand why nobody wants to deal with that stuff and choose lowest common denominator (electron)

Just look at what you have to do to get started with WebView2 on windows

Hopefully this community group will lead to a better story for webviews in desktop software

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.

Very interesting. As one of the maintainer of Cordova I am looking forward to see what happens there.

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.

Almost all of the major WebView implementations I can think of are open source:

• WKWebView (iOS, macOS): https://github.com/WebKit/webkit/blob/main/Source/WebKit/UIP...

• Android WebView: https://android.googlesource.com/platform/frameworks/base/+/...

• Mozilla GeckoView: https://github.com/mozilla/gecko-dev/tree/master/mobile/andr...

• Chromium Embedded Framework (CEF): https://bitbucket.org/chromiumembedded/cef/src/master/

The main ones that aren't open source are the Windows WebView and WebView2 components.

WKWebView is open source but apple can always decide to change APIs and break apps. Happened before with their tracking prevention.

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.

yeah tauri is some progress and flutter webview is also is ok if you only care about ios and android but its not enough.

https://github.com/tauri-apps/tauri

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..

> The main candidate is the official webview shipped on windows

Why is that one ‘official’ or the main candidate?

> they use webkit wich leads to platform specific bugs

Doesn’t the Microsoft one have platform-specific bugs as well?

Why should there be one?

It is like telling there should only exist one browser.

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.

https://github.com/JetBrains/jcef

It embeds Chromium.

Isn't this exactly what Qt WebEngine does?

Can QT webengine be used in a standalone or RPC manner? If so tauri should use it

Features are listed here:

https://doc.qt.io/qt-6.2/qtwebengine-features.html

There is an API and python bindings. Falkon and qutebrowser (possibly others) use it for their browser engine. It uses Chromium code underneath.

> It uses Chromium code underneath.

Now if just Qt for WebAssembly[1] would support it we could go full circle...

[1]: https://doc.qt.io/qt-6/wasm.html

We're already there unfortunately. :(

Sounds like a fun evening experiment, how many levels deep of webception can one go?

You can run windows 95 on a browser and then a browser on that windows, and then run chromium wasmified so yeah we can go pretty deep