I checked again, and as far as I can see, JS is blocked from making external requests by the cross origin policy. Image fetches were blocked by the bogus proxy, but I'm not quite sure that this is 100% so I added another layer (a QWebEngineUrlRequestInterceptor) to block anything but the initial page load.
I don't think that the webengine preview poses a security or privacy risk in the current version, and even less on the next one. The qt5+webkit configuration is probably even better but it probably has no way forward. So I think that a default of building with webengine with an exception for platforms which don't support it is the best approach. Timothy Pearson writes: > 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]
