Re: Definition of browser vs. WebView

This discussion took an unexpected direction from my original question
in the last meeting but I like this and would like to add some late
night thoughts.

In light of these new questions and comments I came up with the cheesy
punchline: Whether something is considered a browser or a WebView
depends not on what it is, but on how it is used.

If you have a closer look at the actual words this might become more
obvious:

A browser let's the user freely navigate the web as the word "Browsing"
is defined:
- to look at a lot of things rather than looking for one particular
thing
- to look through a book, newspaper, website, etc. without reading
everything
(from
<https://www.oxfordlearnersdictionaries.com/definition/english/browse_2>)

WebView means a view that shows web content which is embedded in a
native app. The native app embedding the WebView has lot's of control
over what content the user sees and how they can interact with the WWW. 
That should cover both types of WebViews mentioned before and the
original definition of the hidden URL bar. Additionally app developers
can apply additional settings like allow lists or disabling JavaScript,
CSS etc. that make browsing the web impossible and make their WebView
instances just a HTML renderer for local content.

This also means if you use let's say WebView2 on Windows to build you
own custom browser It's no longer considered a WebView because your
whole app becomes a browser. Therefore all apps on iOS that use
WKWebView to build a browser experience should be considered a browser.
This makes me wonder if their user agent says WKWebView or is customized
to be similar to browsers using their own engine.



On May 7, 2025, Josh Kadis <josh@kadisco.com> wrote:
> I was just writing something along these lines, thanks Tim.. From my
> perspective implementing both the web and native aspects of webviews
> in iOS, the in-app browser SFSafariViewController is nearly identical
> to a regular web browser. The only difference is whether the URL field
> hidden and prefilled by the app or is exposed to the user.


> On Wed, May 7, 2025 at 11:50 AM Tim Cappalli
> <timcappalli@cloudauth.dev> wrote:
> > Great discussion!
> >
> >  
> >
> > Should the type of WebView also be part of the discussion? In the
> > context of authentication-related APIs, we typically classify them
> > into “system webviews” and “embedded webviews”.
> >
> >  
> >
> > Embedded WebViews (ex: WKWebView) run in the context of the calling
> > app when binding to other services (e.g. a passkey for WebAuthn
> > would use the app’s context, not necessarily the web context), they
> > don’t have access to any system level cookies or state, and the
> > calling app can modify the request and response.
> >
> >  
> >
> > System WebViews (ex: Custom Tabs, ASWebAuthenticationSession) use
> > traditional browser context (e..g. runs in the web context, not the
> > calling app), typically have access to system level cookies and
> > state, and the calling app cannot modify the request or response.
> >
> >  
> >
> > Some examples of how passkeys work with these two different types of
> > webviews: Android
> > <https://passkeys.dev/docs/reference/android/#webviews> | macOS
> > <https://passkeys.dev/docs/reference/macos/#webviews>.
> >
> >  
> >
> > tim
> >
> >  
> >
> > From: Ben Wiser <bewise@google.com <mailto:bewise@google.com>>
> > Date: Wednesday, May 7, 2025 at 06:57
> > To: Ashley Gullen <ashley@scirra.com <mailto:ashley@scirra.com>>
> > Cc: Mike Taylor <miketaylr@google.com
> > <mailto:miketaylr@google.com>>, public-webview@w3.org
> > <mailto:public-webview@w3.org> <public-webview@w3.org
> > <mailto:public-webview@w3.org>>
> > Subject: Re: Definition of browser vs. WebView
> >
>