# What's going on with KDE web browser's engines ?

## Ashie

Updating World, dev-qt/qtwebengine takes more than the rest of KDE combined to compile. /dev-qt/qtwebkit a close second. I don't recall Webkit being anywhere that big package in the older days..

Also, qtwebengine appears (by the contents) to have what looks like the entire Chromium web browser contained inside, even though it does not actually install Chromium on the system. Is this thing even clean of anything Google spying related ?

Where are the good lightweight, and supposedly not containig load of code straight from Google (open source alright, but have this big volume of code been audited at all ?), web engines like Webkit of a few years ago ?

----------

## fedeliallalinea

 *https://wiki.qt.io/QtWebEngine wrote:*   

> Qt WebEngine integrates Chromium's fast moving web capabilities into Qt. 

 

EDIT: chromium engine is a fork of webkit

----------

## Ashie

The reasoning is the web page rendering functionality, but it very obviously pulls in a whole lot of other stuff. Fork of some existing code base that overall works well, and gets upgraded functionality, does not suddenly grow up tenfold in size (unless we are talking about systemd)

It's not the compile time, but the actual addition of obviously whole lot of code that i have no idea what it does, but probably most of it is not related to rendering HTML, that bugs me :

I don't see how this benefits KDE-native web browsers that use the engine. Webkit based browsers are good for not being bloated (in contrast to Mozilla, Chrome, etc). This is lost

I don't see what guarantees that it does not retain some sort of information exchange with Google. See how much stuff Ungoogled Chromium did clean out of Chromium (and they are still a work in progress), yet if qtwebengine uses Chromium code base, it means that any of that stuff that is not just in the top level GUI application Chromium itself, gets pulled into qtwebengine

----------

## fedeliallalinea

 *https://wiki.qt.io/QtWebEngine wrote:*   

> Relationship to Chromium
> 
> Qt WebEngine uses code from the Chromium project. However, it is not containing all of Chrome/Chromium:
> 
>  Binary files are stripped out
> ...

 

----------

## Ashie

This is quoting Qt, but it does not necessarily mean that it is right..

Point : Projects like Ungoogled Chromium put big efforts, which yet are a work in progress, to strip everything Google related out of Chromium (this includes the top level Chromium application itself, which is not in qtWebEngine, but the Google stuff they rip out is all over the entire Chromium). Qt dropped qtWebkit to cut down on development efforts and use the existing Chromium code base for convenience. How exactly can they provide what they claim, if providing it takes effort which they don't commit ?

----------

## fedeliallalinea

 *Ashie wrote:*   

> This is quoting Qt, but it does not necessarily mean that it is right..

 

There are sources you can looking. You looked also kernel source? You are sure that in kernel there are no tracking code?

All open source program may have malicious codes if you don't trust the developers and if you haven't personally looked the code.

----------

## Ashie

The kernel is not an example for codebase that have been explicitly built to track etc, and then picked up, "cleaned" and included in another project. It had been built incrementally in its own right, with no goals to track anyone, there are no grounds to mistrust any specific commit ever done to it, and the incremental development means that there was adequate opportunity to review each increment

The inclusion of Chromium, a project which size is way beyond Qt developers' ability to audit (as demonstrated by the reasoning behind moving to it), as part of Qt, very much stands out in this sense

----------

## fedeliallalinea

 *Ashie wrote:*   

> The kernel is not an example for codebase that have been explicitly built to track etc, and then picked up, "cleaned" and included in another project. It had been built incrementally in its own right, with no goals to track anyone, there are no grounds to mistrust any specific commit ever done to it, and the incremental development means that there was adequate opportunity to review each increment

 

Chromium engine code (blink) did not come out of nowhere, this is a fork of webkit that which in turn is a fork of KHTM/KJS (old kde project).

----------

## Ashie

1. QtWebEngine includes extensive parts of Chromium, not just Blink, and those have not come from qtWebkit

2. The point that Chromium had been built to track, does not imply whether the tracking code could be located in a new module written from scratch, or added into a module that originated from qtWebkit (and did not originally have this functionality). In either case the result would be a module somewhere in qtWebEngine that tracks

3. Google tracking aside, there is the thing with the web engine becoming bloated compared to what it had been before. Adding a few new features isn't what would make a component like web engine grow in size by an order of magnitude. If Blink is the actually beneficial part, why is Chromium, and not just Blink, taken into qtWebEngine ?

----------

## fedeliallalinea

If you're worried, you can remove qtwebengine that isn't strictly mandatory for plasma (but for some kde-apps yes), in my system

```
dev-python/PyQt5-5.10.1-r1 (webengine ? >=dev-qt/qtwebengine-5.9.4:5[widgets?])

kde-apps/kdepim-runtime-18.08.2 (>=dev-qt/qtwebengine-5.9.4:5[widgets])

kde-apps/kmail-18.08.2 (>=dev-qt/qtwebengine-5.9.4:5[widgets])

kde-apps/kontact-18.08.2 (>=dev-qt/qtwebengine-5.9.4:5[widgets])

kde-apps/libkgapi-18.08.2 (>=dev-qt/qtwebengine-5.9.4:5[widgets])

kde-apps/libksieve-18.08.2 (>=dev-qt/qtwebengine-5.9.4:5[widgets])

kde-apps/messagelib-18.08.2 (>=dev-qt/qtwebengine-5.9.4:5[widgets])

kde-misc/kmarkdownwebview-0.5.3 (!webkit ? >=dev-qt/qtwebengine-5.9.4:5[widgets])

kde-plasma/kdeplasma-addons-5.14.2 (webengine ? >=dev-qt/qtwebengine-5.11.1:5)
```

----------

## Ashie

I am interested in actually understanding how is safety maintained and ensured in core components of my desktop environment, rather than a one-case solution (that might also stop being viable anytime, if e.g. an essential component of Plasma adds qtWebEngine as a dependency at some point in the future) of the "don't use stuff" type

Also, i am looking for a KDE native web browser that uses a lightweight, yet capable (sufficiently for most websites) web engine. This is because i want an efficient in system resource use browser, and don't want "emerge World" to take excessive time to complete because of one package that takes more than half of the overall time. Otter is great but i do want something that stays up to date, atleast security wise (i could care less about every last HTML5 feature being implemented, i just pull out Firefox for the few websites that actually need it)

----------

## fedeliallalinea

 *Ashie wrote:*   

> Also, i am looking for a KDE native web browser that uses a lightweight, yet capable (sufficiently for most websites) web engine. This is because i want an efficient in system resource use browser, and don't want "emerge World" to take excessive time to complete because of one package that takes more than half of the overall time. Otter is great but i do want something that stays up to date, atleast security wise (i could care less about every last HTML5 feature being implemented, i just pull out Firefox for the few websites that actually need it)

 

Like kde-apps/konqueror without webengine use flag?

----------

## dmpogo

Ashie,

You ask very good questions, I'd like to know the answers to as well.

----------

## Ashie

 *fedeliallalinea wrote:*   

>  *Ashie wrote:*   Also, i am looking for a KDE native web browser that uses a lightweight, yet capable (sufficiently for most websites) web engine. This is because i want an efficient in system resource use browser, and don't want "emerge World" to take excessive time to complete because of one package that takes more than half of the overall time. Otter is great but i do want something that stays up to date, atleast security wise (i could care less about every last HTML5 feature being implemented, i just pull out Firefox for the few websites that actually need it) 
> 
> Like kde-apps/konqueror without webengine use flag?

 

Sorta, but how well is KHTML maintained and how safe it is from getting kicked out for the same reasons as qtWebkit, leaving only qtWebEngine option ?

----------

## dmpogo

 *Ashie wrote:*   

>  *fedeliallalinea wrote:*    *Ashie wrote:*   Also, i am looking for a KDE native web browser that uses a lightweight, yet capable (sufficiently for most websites) web engine. This is because i want an efficient in system resource use browser, and don't want "emerge World" to take excessive time to complete because of one package that takes more than half of the overall time. Otter is great but i do want something that stays up to date, atleast security wise (i could care less about every last HTML5 feature being implemented, i just pull out Firefox for the few websites that actually need it) 
> 
> Like kde-apps/konqueror without webengine use flag? 
> 
> Sorta, but how well is KHTML maintained and how safe it is from getting kicked out for the same reasons as qtWebkit, leaving only qtWebEngine option ?

 

Konqueror without webengine USE flag uses qtwebkit, which is still in the tree.   After reading this thread I tried it yesterday, and results were fairly miserable.  The end was konqueror just plain crashing after 5 min of use, on me hitting back button at one stage.

----------

## Ashie

The question applies to qtWebkit as well. If qtWebkit is not maintained it 1. can be kicked out of the tree anytime on a whim 2. is not patched in case of security holes discovered

----------

