Re: Definition of browser vs. WebView

This thread went quiet for a week so at Ben's suggestion I filed an issue
here summarising the discussion and proposing a definition:
https://github.com/WebView-CG/usage-and-challenges/issues/49


On Fri, 9 May 2025 at 09:08, Ashley Gullen <ashley@scirra.com> wrote:

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