Re: Definition of browser vs. WebView

AFAIK a specification definition should not refer to specific technologies
like Android Webview anyway, so I do think it would be right to come up
with a definition that categorizes a browser built using a webview as a
browser, and not as a webview solely because of the technology choice.

Another approach is to focus on capabilities of webviews, but I think that
is still a pretty complicated route to go down. For example if we define a
webview as web content where the requests and responses can be intercepted,
you can also do that with a browser extension. So does that mean a web
browser with a browser extension intercepting requests becomes a webview?
If a browser is defined by its access to the user's cookies, then if you
switch to private browsing or a guest account, does that become a webview?
In both cases the answer is obviously not, which I think is a sign it will
be tricky to get a capabilities-based definition.

So unless the CG still disagrees, I think focusing on the UX or general
usage of the app is the right way to define it. My first definition based
on the URL bar was a first attempt at that and I think lines up with what
Niklas said about "browsing" being about "freely navigating the web".

Perhaps "freely navigating the web" is actually a better basis for a
definition, as it doesn't actually refer to any specific user interface
elements like a URL bar. Under a "free navigation of the web"
definition, Android Custom Tabs and SFSafariViewController would still
qualify as browsers, as there is no restriction on following links. The
categorization of a browser in kiosk mode would depend on if navigation is
restricted.

Or perhaps there is something else about the UX we could consider - maybe
it could be to do with back/forward buttons, bookmarks, downloads, a
resizable window, or something else? Personally I'm now leaning towards a
definition based on "freely navigating the web".

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

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