Re: Definition of browser vs. WebView

Thanks for starting this discussion! I share the feeling that the
definition can not be expressed in purely technical terms. We've touched
upon that in the [old threads](
https://github.com/WebView-CG/usage-and-challenges/issues/41).
My sense is that there's an intuitive idea of a "web browser", something
that most users have in mind when they search for a "browser" app in an app
store.
I wonder if the eventual definition of a browser should consist of 2 parts:
1. a general description in terms of UX (e.g. allowing to browse arbitrary
links, consuming 3rd-party content, acting as a user agent, and managing
security and privacy for the user). The goal of this part is to capture the
intuitive notion of a "full" browser.
2. a more technical section clarifying for the specific cases such as
MiniApps, EPUB readers, etc. This part can change over time as new types of
apps emerge.



On Wed, May 7, 2025 at 11:37 PM Niklas Merz <niklasmerz@apache.org> wrote:

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

-- 
Best regards,
Maxim Tsoy