libreplanet-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreplanet-discuss] [Dev] QTWebengine is nonfree


From: Luke
Subject: Re: [libreplanet-discuss] [Dev] QTWebengine is nonfree
Date: Sun, 8 Jan 2017 20:20:03 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101, Thunderbird/38.5.1

On 01/08/2017 07:05 PM, Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

This sounds like a big problem, but it might not be hard to fix.

Could someone give me additional information?

  > Hi guys, since Chromium is blacklisted as nonfree software [0] we have a
  > serious issue. KDE is migrating their apps to QTWebEngine which contains
  > Chromium as the embed engine inside it. [1]

What does "embed engine" mean?
What jobs does it need to do?

Is it possible to use Iridium instead of Chromium?

Can you tell me the names and addreses of a few people in KDE that
it would be useful to discuss this with?



> What does "embed engine" mean?
To "embed the engine" in this context = running another program inside your own. The code to do it for QT is as simple as:

---
import QtQuick 2.1
import QtWebEngine 1.0

WebEngineView {
    url: "htttp://www.ics.com"
}
----

It allows developers to quickly create GUI programs that contain the entire Chromium platform (more than just a web-engine, since Chrome is also developing ChromeOS), without actually having to do any of the work usually required for a backend web engine. This makes for pretty programs with different layouts, all using the same web engine. To quote one of the QT development websites...

"As the build includes Google Chromium, which has over 9,000 source files, it will take some time to complete. My build took about forty-five minutes to compile the software on a standard quad-core CPU laptop....

In summary, QtWebEngine is planned to replace QtWebKit as the web-rendering engine for Qt. It will likely be included as part of the Qt 5.4 release. While QtWebKit will continue to be available for binary compatibility, new development will focus on QtWebEngine. I encourage you to take a look at it and consider using it in your Qt applications."
(http://www.ics.com/blog/building-qtwebengine)

It's essentially the same as Internet Explorer was doing in times past for Visual C++. Users can drag and drop widgets to create "pseudo-browsers", all powered by the same embedded engine. That is why there were (and are) so many non-free browsers. There are in reality only a few free web-engines, and many re-branded "browsers" that mere put shiny new graphics on old engines. (https://en.wikipedia.org/wiki/Trident_%28layout_engine%29#Use_cases)
(https://en.wikipedia.org/wiki/Comparison_of_web_browser_engines)


> What jobs does it need to do?
What a web-engine/layout engine needs to do is quite complex. It is difficult to describe in one e-mail, but the best article I could find is from a Mozilla developer. I am including the highlight of the article below:

"Let’s talk terminology. A browser engine is the portion of a web browser that works “under the hood” to fetch a web page from the internet, and translate its contents into forms you can read, watch, hear, etc. Blink, Gecko, WebKit, and Trident are browser engines. In contrast, the the browser’s own UI—tabs, toolbar, menu and such—is called the chrome. Firefox and SeaMonkey are two browsers with different chrome but the same Gecko engine.

A browser engine includes many sub-components: an HTTP client, an HTML parser, a CSS parser, a _javascript_ engine (itself composed of parsers, interpreters, and compilers), and much more. Those components involved in parsing web formats like HTML and CSS and translating them into what you see on-screen are sometimes called the layout engine or rendering engine."
(https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html)

The above complexity is also why no one wants to do it, they just depend on others to do that work for them and then "embed an engine" into their pseudo-browsers and other programs for rapid development.

> Is it possible to use Iridium instead of Chromium?

Unfortunately, Iridium has merely used a few inox-patchsets and GUI branding to the Chromium engine. In addition to not blocking non-free addons, it does not solve the non-free license issues, per outstanding bug ticket:  https://github.com/iridium-browser/iridium-browser/issues/93

Another project, ungoogled-chromium goes much further, and yet still admits defeat. Here is the state of Ungoogled-Chromium:

----
In addition to features from Debian, Inox patchset, and Iridium Browser:


  • Replace many web domains in the source code with non-existent alternatives ending in qjz9zk (known as domain substitution)
  • Strip binaries from the source code (known as source cleaning)
    • This includes all pre-built executables, shared libraries, and other forms of machine code. They are substituted with system or user-provided equivalents, or built from source.
    • However a few data files (e.g. *_page_model.bin that define page models for the DOM Distiller) are left in as they do not contain machine code and are needed for building.
  • Disable functionality specific to Google domains (e.g. Google Host Detector, Google URL Tracker, Google Cloud Messaging, Google Hotwording, etc.)
  • Add Omnibox search provider "No Search" to allow disabling of searching
  • Disable automatic formatting of URLs in Omnibox (e.g. stripping http://, hiding certain parameters)
  • Disable _javascript_ dialog boxes from showing when a page closes (onbeforeunload events)
    • Bypasses the annoying dialog boxes that spawn when a page is being closed
  • Added menu item under "More tools" to clear the HTTP authentication cache on-demand
  • Force all pop-ups into tabs
  • Disable Safe Browsing
  • Disable WebRTC
    • This will be configurable in the future.
  • Disable intranet redirect detector
    • Prevents unnecessary invalid DNS requests to the DNS server.
    • This breaks captive portal detection, but captive portals still work.
  • Add more URL schemes allowed for saving
    • Note that this generally works only for the MHTML option, since an MHTML page is generated from the rendered page and not the original cached page like the HTML option.
  • (Iridium Browser feature change) Prevent URLs with the trk: scheme from connecting to the Internet
    • Also prevents any URLs with the top-level domain qjz9zk (as used in domain substitution) from attempting a connection.
  • (Iridium and Inox feature change) Prevent pinging of IPv6 address when detecting the availability of IPv6
  • Support for building Debian and Ubuntu packages
    • Creates a separate package chrome-sandbox for the SUID sandbox
      • Not necessary to install if the kernel option unprivileged_userns_clone is enabled
  • Windows support with these changes:
    • Build wow_helper.exe from source instead of using the pre-built version
    • Build swapimport.exe from source instead of downloading it from Google (requires customized syzygy source code)
    • Build yasm.exe from source instead of using the pre-built version
    • Use user-provided building utilities instead of the ones bundled with Chromium (currently gperf and bison)
    • Do not set the Zone Identifier on downloaded files (which is a hassle to unset)

DISCLAIMER: Although it is the top priority to eliminate bugs and privacy-invading code, there will be those that slip by due to the fast-paced growth and evolution of the Chromium project.
----

Per Ungoogled-Chromium bug ticket #117:
"
I don't know if any fork of Chromium complies with the free software guidelines. If you are using Debian or Ubuntu, I adapt all of Debian's changes to ungoogled-chromium. I've also stripped almost all of the binary blobs through source cleaner (all of the machine code is gone; some data in binary form for page distillation and international components for unicode)."

"Closing as wontfix since this is impractical to accomplish without rewriting larger portions of source code to use free software. There simply isn't enough manpower."
(https://github.com/Eloston/ungoogled-chromium/issues/117)

> Can you tell me the names and addreses of a few people in KDE that,it would be useful to discuss this with?
Unfortunately, I don't know of anyone in KDE or QT, but they should definitely be made aware of this issue if they are not already. It present serious freedom concerns. Perhaps some one else can help with this information and reaching out to them?

Luke
Parabola GNU/Linux-libre Packager
https://parabola.nu

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]