[Qtwebengine] QTWebengine compliance with FSDG
Allan Sandfeld Jensen
allan.jensen at qt.io
Tue Jan 24 14:48:24 CET 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?
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?", 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, 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?
> 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?
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
The Qt Company
Rudower Chausse 13, 12489 D-Berlin
More information about the QtWebEngine