[Dev] [Qtwebengine] QTWebengine compliance with FSDG

Allan Sandfeld Jensen allan.jensen at qt.io
Tue Jan 24 13:48:24 GMT 2017

On Tuesday 24 January 2017, Luke wrote:
> 1) Was any attempt made to remove Google specific code from Chromium
> prior to preparing QTWebengine?
> - If not, could ungoogled-chromium patches be applied to your code?[3]
Yes, we remove a large amount of code from Chromium. Note in particular we are 
using the Chromium content API, not the Chromium browser implementation, which 
means we are a step lower that most Chromium forks. 

> By default, Chromium has many lines of code that make internet queries
> to Google. Building it using the default settings essentially puts your
> browser into the cloud. As mentioned in the GNU.org article "Who does
> that server really serve?"[4], free software is only free when you are
> in control. Any use of Google API, Google Sync, Google Hangouts, and
> Google OK, does not classify as free software.

None of that code is included or works at the moment, we might want to enable 
some of it optionally at some point, but at the moment everything that relies 
on Google or reports back to Google has not only been disabled, but have been 
striped from sources.

> 2) Is any form of proprietary code such as Adobe pepperflash, webvine
> DRM[5], or proprietary codecs included? If so, can they be removed or
> disabled with a compile time option?
They are not part of the opensource Chromium project, we support the plugins 
if they are found on the system or you ship them with your QtWebEngine using 
application, but we do not ship them.

> 3) Is it possible to compile QTWebengine with specific chrome://flags?[6]
> Due to privacy and security concerns of Geolocation API, and GamePad
> API, among others, we would like to have the ability to disable these
> settings for our distribution.
Many of those are exported through our QWebEngineSettings, and others are not 
yet implemented. Geolocation and camera sharing is implemented but requires 
the QtWebEngine using application to approve access (we assume it will ask the 
user when appropriate).

> 4) Was any work done to fix outstanding proxy leaks in Chromium, which
> ignore system proxy settings?[7]
We use Qt proxy settings if set, otherwise fall back to the Chromium proxy 
implementation which should follow system settings. If I read the bug correct 
you linked, it is about ignoring system settings, and was rejected. Do I read 
that correct?

Best Regards
`Allan Jensen
The Qt Company
Rudower Chausse 13, 12489 D-Berlin

More information about the Dev mailing list