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

Ashie · n00b Joined: 09 Apr 2016 Posts: 54

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 · Posted: Tue Oct 30, 2018 7:19 am Post subject:

Ashie · n00b Joined: 09 Apr 2016 Posts: 54

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 · Posted: Tue Oct 30, 2018 8:46 am Post subject:

Ashie · n00b Joined: 09 Apr 2016 Posts: 54

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 · Posted: Tue Oct 30, 2018 9:42 am Post subject:

Ashie · n00b Joined: 09 Apr 2016 Posts: 54

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 · Posted: Tue Oct 30, 2018 11:14 am Post subject:

Ashie · n00b Joined: 09 Apr 2016 Posts: 54

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 · Posted: Tue Oct 30, 2018 3:50 pm Post subject:

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

Ashie · n00b Joined: 09 Apr 2016 Posts: 54

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 · Posted: Tue Oct 30, 2018 5:23 pm Post subject:

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3468 Location: Canada

Ashie,

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

Ashie · n00b Joined: 09 Apr 2016 Posts: 54

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3468 Location: Canada

Ashie · n00b Joined: 09 Apr 2016 Posts: 54

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