Re: [GNU-linux-libre] DSFG in perpetuity
On 04/02/2018 09:21 PM, Luke Shumaker wrote: > On Mon, 02 Apr 2018 18:53:25 -0400, > Luke wrote: >> Among the issues that stuck out to me were... >> - WideVine DRM support. >> https://github.com/qt/qtwebengine-chromium/tree/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/third_party/widevine/cdm > Is libwidevinecdm.so, or a way to download it, ending up in the build? > If not, this isn't a issue. I don't see the libwidevinecdm.so binary, > and I don't see any of the URLs where it can be downloaded. > > -- > Happy hacking, > ~ Luke Shumaker > > By default the support is there for the plugin, but the plugin itself does not appear in the build. As per the AUR: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qt5-webengine-widevine the plugin has to be downloaded separately, at which point it can be used. So not a major issue, so as long as the non-free plugin is not on the users system. This and the ability to have a -proprietary-codecs useflag are good improvements that the QT team has done. signature.asc Description: OpenPGP digital signature
Re: [GNU-linux-libre] DSFG in perpetuity
On Mon, 02 Apr 2018 18:53:25 -0400, Luke wrote: > Among the issues that stuck out to me were... > - WideVine DRM support. > https://github.com/qt/qtwebengine-chromium/tree/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/third_party/widevine/cdm Is libwidevinecdm.so, or a way to download it, ending up in the build? If not, this isn't a issue. I don't see the libwidevinecdm.so binary, and I don't see any of the URLs where it can be downloaded. -- Happy hacking, ~ Luke Shumaker
Re: [GNU-linux-libre] DSFG in perpetuity
On 04/01/2018 11:13 PM, Isaac David wrote: > Luke wrote : >> Users should be aware that QTWebengine is based on Chromium and >> therefore contains many of the same flaws. > > This assertion in particular raises some alarms. I don't > think that was ever established to be the case; and > insofar as the suspicion goes, both KDE and Qt developers > denied it[1][2] and even updated their documentation in > accordance to our concerns[3]. > > Is your view still that Qt Webengine poses a problem to > free distros, and if so, why? When I asked their development team whether or not they use ungoogled-chromium patches, they continued to say those patches do not apply to them as they used a "stripped down version". (e.g. they delete large parts of the /browser and /ui directories) I haven't done extensive review, but as of the date of the e-mail there was still some freedom issues and plenty of links to Google.com which could still be stripped out. List of good patches: https://github.com/Eloston/ungoogled-chromium/tree/master/resources/patches Compare to QTWebengine's (outdated) Chromium: https://github.com/qt/qtwebengine-chromium Among the issues that stuck out to me were... - WideVine DRM support. https://github.com/qt/qtwebengine-chromium/tree/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/third_party/widevine/cdm - Debian freedom patches not applied, e.g. files missing licenses: https://github.com/Eloston/ungoogled-chromium/blob/077e441e6654e4658de37c9d665e58f61b262961/resources/packaging/debian/buster/source/lintian-overrides https://github.com/qt/qtwebengine-chromium/blob/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/tools/trace/trace_data.js - There may still be connections made to Google API. https://github.com/qt/qtwebengine-chromium/search?p=2&q=%22www.googleapis.com%22&type=&utf8=%E2%9C%93 Having the /browser folder removed is certainly a good start, I'm just not convinced they completely resolved it in their fork. So far ungoogled-chromium is the only project I've compiled and ran with Wireshark that did not have random connections to Google.com while the browser is idling. signature.asc Description: OpenPGP digital signature
