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]

Reply via email to