Re: Definition of browser vs. WebView

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>
> *Date: *Wednesday, May 7, 2025 at 06:57
> *To: *Ashley Gullen <ashley@scirra.com>
> *Cc: *Mike Taylor <miketaylr@google.com>, public-webview@w3.org <
> public-webview@w3.org>
> *Subject: *Re: Definition of browser vs. WebView
>
> Thanks so much for kicking off this thread Ashley! (And sorry for making
> you take the lead of this 😅)
>
>
>
> I do suspect that the edge cases of experience around the UX will bring in
> more complications like the kiosk mode. My understanding of CTs is also
> that they are the same process and memory space of the regular browser
> process being used. I wonder if the definition of a WebView is less about
> Browser / WebView and more about WebView being a separate dimension? For
> example, if I build a thin web browser using a popular WebView library
> (thin meaning I add very little UX and the WebView is doing most of the
> work), it doesn't seem like that library necessarily stops being a WebView?
>
>
>
> On Wed, May 7, 2025 at 10:54 AM Ashley Gullen <ashley@scirra.com> wrote:
>
> This proposed specification definition of a webview doesn't rely on the UA
> string. I just meant it's a basis on which we could start to attempt to
> come up with webview statistics based on UA strings seen in the wild (a
> separate discussion at our last meeting where the question came up). Any
> statistics drawn from UA strings are always going to be imperfect, but it's
> all we have to go on for statistics purposes, so we will have to make do.
>
>
>
> Chrome in kiosk mode is an interesting case I hadn't thought of - under
> this definition it would count as a webview, and I don't think that's
> unreasonable, as again it's much like a Cordova app where the content you
> see is restricted. I suppose you could argue it's a third mode - just a
> special setting for a browser - but I'm not sure how useful it would be to
> go down that path, especially if we end up with a fourth, fifth mode etc.
> Personally I think an oversimplified definition is better than an
> overcomplicated one.
>
>
>
> In my view iframes are part of web content and so would never be
> categorized as a webview by themselves - perhaps the definition could be
> amended to clarify that though. Perhaps something like "if the app
> embedding web content allows entering a URL, then it is a browser". Really
> the intent is to describe the way the top level frame is embedded.
>
>
>
> Ashley
>
>
>
>
>
>
>
> On Tue, 6 May 2025 at 17:46, Mike Taylor <miketaylr@google.com> wrote:
>
> On 5/6/25 8:54 AM, Ashley Gullen wrote:
>
> Hi all,
>
>
>
> At our last WebView CG meeting I volunteered to help work on the
> definition of a browser vs. webview, which quickly led to my promotion to
> lead on the topic, so... here we go!
>
>
>
> I've had a think and I want to come up with a simple definition that can
> easily be used to determine whether something is a webview, without
> referencing specific technologies (e.g. the Android Webview). I think this
> might be a good definition:
>
>    - If the user can enter their own URL to navigate to, then it is a web
>    browser.
>    - If the user cannot enter their own URL to navigate to, then it is a
>    webview.
>
> So based on this definition:
>
>    - Naturally the major browsers like Chrome, Safari and Firefox are web
>    browsers, as you can enter your own URL to navigate to.
>    - Web content embedded in apps, such as Cordova apps, count as a
>    webview as there is no user interface to enter your own URL to navigate to.
>    These use cases involve showing a fixed selection of web content determined
>    by the app developer, and may well block navigating to the open web for
>    security reasons.
>    - If an app embeds a webview, but adds a user interface to allow users
>    to enter their own URL to navigate to, then it qualifies as a web browser.
>    I think someone mentioned the DuckDuckGo browser does this, and assuming it
>    has a URL bar, then it is a browser under this definition
>    - In-app browsers like Android Custom Tabs and SFSafariViewController
>    qualify as webviews, since (as far as I can tell) the user cannot edit the
>    URL in this mode to browse to a different website. Despite having many of
>    the features of a web browser, it works like showing the same content in a
>    dismissable webview (which AFAIK is in fact often what apps did prior to
>    the introduction of in-app browsers), so I feel like this is still an
>    appropriate categorisation. Where the in-app browser provides an option to
>    open the viewed page in the actual browser app (e.g. 'Open in Chrome
>    browser' on Android), under this definition it will switch the user from a
>    webview to a browser, as in the browser they can then edit the URL.
>
> It should be easy to tell with this definition: basically if you can type
> in a URL, it's a browser, otherwise it's a webview.
>
>
>
> This should then be a basis on which to categorise things like usage stats
> for browsers vs. webviews. The user agent string does not reliably tell you
> if there is an editable URL bar, but it gives us a basis from which to
> categorise the different user agent strings that are observed in the wild,
> such as DuckDuckGo Browser (browser) and Facebook in-app browser (webview).
>
> Categorizing "webview or not" via UA string seems like it falls apart in a
> scenario like "Chrome opened in kiosk mode", or any app using
> `setUserAgentString()` (or similar).
>
> Another thought: if the goal here to for traffic usage, do you consider
> traffic coming from iframes to be browser traffic, or webview traffic
> (given that users can't enter a URL into iframes).
>
>
>
> Any thoughts?
>
>
>
> Ashley
>
>