That's great to hear, thank you for the explanation and for considering user privacy in the application design. Chromium makes me nervous from a privacy and security standpoint, I am actually the ppc64el maintainer for the Chromium codebase -- it's a complex beast that tries nearly every way imaginable by default to phone home back to Google, which is why I wasn't too happy to see it show up in recoll. :)
I haven't caught recoll making any unauthorized network requests, but then again I haven't used the new QWebEngine version because I don't use amd64 machines in any significant capacity (the newest one I have is from 2013, when you could still run libre firmware on the mainboards). It would definitely be interesting to see if QWebEngine is able to initiate network requests somehow. ----- Original Message ----- > From: "Jean-Francois Dockes" <[email protected]> > To: "Timothy Pearson" <[email protected]> > Cc: "1111324" <[email protected]> > Sent: Sunday, August 17, 2025 3:39:51 PM > Subject: Re: Bug#1111324: Acknowledgement ([regression] recollgui > uninstallable on ppc64el) > Several things: > - As the documents loaded by the preview are loaded from local files, I > don't think that the Javascript is allowed to fetch from the network. I > am no javascript or browser expert though. > - In order to prevent webkit or webengine (or anything inside the app > actually) from making network requests, recoll sets up the Qt app with a > bogus proxy (socks5 proxy on localhost with username recoll and no > password). This is a bit of a hack but I think that it should work in > case something does try to reach out. > - I just saw that there is an additional layer which could be set in the code > calling Qt Webengine, for intercepting all network requests. I'm going to > have a look at adding this as an additional protection layer. > > Because recoll is by nature processing a lot of user data, I try to make > sure that it initiates no external network traffic at all. > > I've not ever had any report to the contrary, but I'm quite ready to fix > issues in this area. > > > > Timothy Pearson writes: > > Understood, thank you for the explanation. That helps, and also brings up > > another question. > > > > On the debian/rules architecture selection, yes, this is supported. > > Something > > similar to: > > > > ifeq (ppc64el,$(DEB_HOST_ARCH)) > > # cmake without webengine > > else > > # cmake with webengine > > endif > > > > should work. > > > > However, the explanation of the renderers does bring up a privacy / security > > question. I would personally consider the lack of Javascript support a > > plus, > > in that it stops pingback or similar tracing / monitoring to third party > > servers. Loading up an entire Chromium instance without being able to turn > > off > > external access, disable Javascript execution, etc. seems like a major > > security > > and privacy risk. As an example of how I would expect to see this handled, > > VLC > > pops up a warning indicating that third party services will be able to see > > what > > media you are playing when you turn on metadata lookup -- it seems that if > > we're going to use QWebEngine for rendering, a similar popup should be > > displayed somewhere indicating that we're loading and executing the Web > > pages > > including all of the tracking and monitoring pingbacks. > > > > I bring up the privacy issues because I would be tempted to disable > > QWebEngine > > across all architectures on those grounds alone, but it's not my call. > > Building without QWebEngine on ppc64el would be enough to close this bug. > > > > Thanks! > > > > ----- Original Message ----- > > > From: "Jean-Francois Dockes" <[email protected]> > > > To: "Timothy Pearson" <[email protected]>, "1111324" > > > <[email protected]> > > > Sent: Sunday, August 17, 2025 3:22:09 AM > > > Subject: Re: Bug#1111324: Acknowledgement ([regression] recollgui > > > uninstallable > > > on ppc64el) > > > > > Recoll uses an HTML engine for displaying the result list and the preview > > > window. > > > > > > There are three possible engines: > > > - QTextBrowser, which is the Qt native HTML engine > > > - Qt Webkit > > > - Qt Webengine (chromium-based) > > > > > > Of the 3, Qt Webkit was by far the best for our usage, with a much better > > > API. > > > > > > Qt decided that they needed to switch to using the chromium version, > > > probably > > > because of > > > better Web "standards" support, mostly for people who actually use it for > > > implementing a > > > Web browser. > > > > > > Qt Webkit was externally maintained for Qt5. As far as I know, there is > > > no Qt6 > > > implementation, so there is no way ahead for it. > > > > > > QTextBrowser has only incomplete support for CSS styling (and no > > > Javascript > > > which is an > > > issue for some result list customisations). Attaching a preview of the > > > wikipedia > > > front > > > page with QTextBrowser (on the left), and QWebengine (right) for > > > illustration. > > > > > > For the moment, it is still possible to build with qt5 and libqt5webkit5, > > > which > > > is > > > probably the best current solution, but it has no future. > > > > > > Is it possible at all to use different rules for different architectures ? > > > Disabling the > > > "real" HTML engines only for architectures platforms which don't support > > > them > > > would > > > probably be the best approach going forward. > > > > > > jf > > > > > > > > > > > > > > > [image/png:recoll-wikipedia-preview.png]
