Re: Definition of browser vs. WebView

To add to this, it would be good to check with the existing guidelines in
the market. For example, I know that on Apple platforms "browser" apps can
unlock extra webview capabilities. I wonder if we could learn something
from their practice.

On Thu, May 8, 2025 at 11:11 AM Maxim Tsoy <maks.tsoy@gmail.com> wrote:

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


-- 
Best regards,
Maxim Tsoy