[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU-linux-libre] DSFG in perpetuity
Re: [GNU-linux-libre] DSFG in perpetuity
Wed, 4 Apr 2018 21:53:13 -0600
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Icedove/52.7.0
On 04/04/2018 04:39 PM, Luke wrote:
> On 04/04/2018 11:58 AM, KRT Listmaster wrote:
>> On 04/03/2018 05:18 PM, Luke wrote:
>>> I have not used QTWebengine in over a year and never ran a leak test. -
>>> If someone has the time to do this and verify there are no freedom
>>> issues, they can be removed from the conclusion as you mentioned.
>> I've been monitoring QupZilla 2.0.1 (with the built-in adblocker turned
>> off) using Qt5 5.7.1 and QtWebEngine 5.6.1 through Wireshark 2.4.5 and I
>> see absolutely no outgoing requests that aren't due to NTP or handshakes
>> with my LAN router. With this configuration, there are no domains or IP
>> addresses that I cannot account for based on background system connectivity.
>> Even with the latest IceCat, I see plenty of requests to *.mozilla.com
>> and *.mozaws.com, for example.
>> Almost every functional browser I've tried has at least a few outgoing
>> requests. However, during the past hour of solid monitoring with
>> QupZilla idling and no other applications open, there is nothing
>> happening in WireShark at all that isn't system related, much to my
>> pleasant surprise.
>> I will try some newer versions of Qt5 as well as a newer version of
>> QupZilla just to see if there are any differences. However, from my
>> preliminary investigations, I would be willing to say that QtWebEngine
>> (5.6.1) does not, by itself, make outgoing requests while idling.
>> Is there anything more specific I should be looking for? Other behavior
>> besides idling, for example? There were some requests from QupZilla
>> before I turned of the native adblocker, so I eliminated that to focus
>> only on the QtWebEngine.
> Thanks for testing!
> Keep in mind that QTWebengine can be compiled/configured a variety of ways.
> You'll want try to trigger these parts of code:
> GeoLocation/GDrive/Gaia/GoogleNow/etc. This will likely vary depending
> on the front-end you're using. Projects using the engine can be
> configured to not execute this code, which is how it should be.
> Testing Faclon could be a good next step as Henry mentioned.
> Re: IceCat... They've not removed several background preferences, but
> that is another issue outside the scope of this thread. It's important
> to test all applications for such leaks if you're in an environment
> where not having an IP leak is essential.
> You can view the comments here for reference:
> Any additional testing/research you can do is good for the free software
> movement, and appreciated!
Thank you for pointing me towards Falkon. I didn't see that in relation
to my current distro (Slackware-based), so I spun up a virtual machine
and installed the latest Manjaro iso, and quickly installed both
Wireshark 2.5.1 and Falkon 3.0.0 (based on QtWebEngine 5.10.1) and
I had to turn off the built-in adblocker again, same reason as before,
and I also turned off an unrelated NetworkManager connectivity ping to
archlinux.org that was confusing me at first.
After setting Falkon to start up on a blank page, I restarted the
Wireshark monitor and restarted Falkon. Literally, for the last hour,
the ONLY requests I'm seeing at all are ICMPv6 router requests (probably
related to the VM) about once every 15 minutes, even without the browser
open. From Falkon, I see nothing, it's total crickets.
I spent some time fiddling around in the preferences menu, but that
triggered no requests at all. I eventually went to a website that I
control that I know has no external requests, and I let it sit there for
another hour. All I saw there were keepalive requests that specific
domain and nothing else.
I gotta say, even the latest Falkon built on QtWebEngine 5.10.1 seems to
not make any outgoing requests while idling at all. The only reason I
mentioned IceCat before was just to point out "Yep, I am catching idling
browser requests, even from browsers that I use and trust regularly, so
this Wireshark thing really works...". I wasn't trying to pick on
IceCat at all, quite the contrary. Just using it as a reference
browser, for comparison.
I might not have time right away to start rebuilding Qt5 from source
with different flags (it's a huge package, takes forever on my systems).
I think the point of this exercise was to evaluate a stock browser
based on QtWebEngine without having to tweak it too much (just turned
off the adblocker is all), and see what outgoing requests were being
made, if any. Contrast this with an idling Chromium, which spewed out
countless google.com and gstatic.com requests on an ongoing basis, for
example. It seems that whatever googliness that is baked into Chromium
has indeed really been stripped out of QtWebEngine as the developers
suggest. I don't see any evidence to the contrary.
Are there any relatively simple ways of checking for the other request
triggers you mentioned beyond recompiling Qt5 with different flags? The
stock build seems fairly clean to me.
This email account is used for list management only.
- Re: [GNU-linux-libre] DSFG in perpetuity, (continued)
- Re: [GNU-linux-libre] DSFG in perpetuity, Luke, 2018/04/02
- Re: [GNU-linux-libre] DSFG in perpetuity, Luke Shumaker, 2018/04/02
- Re: [GNU-linux-libre] DSFG in perpetuity, Isaac David, 2018/04/03
- Re: [GNU-linux-libre] DSFG in perpetuity, Luke, 2018/04/03
- Re: [GNU-linux-libre] DSFG in perpetuity, KRT Listmaster, 2018/04/04
- Re: [GNU-linux-libre] DSFG in perpetuity, Henry Jensen, 2018/04/04
- Re: [GNU-linux-libre] DSFG in perpetuity, Luke, 2018/04/04
- Re: [GNU-linux-libre] DSFG in perpetuity,
KRT Listmaster <=
- Re: [GNU-linux-libre] DSFG in perpetuity, Luke, 2018/04/05
- Re: [GNU-linux-libre] DSFG in perpetuity, KRT Listmaster, 2018/04/05
- Re: [GNU-linux-libre] DSFG in perpetuity, bill-auger, 2018/04/06
- Re: [GNU-linux-libre] DSFG in perpetuity, Adonay Felipe Nogueira, 2018/04/06
- Re: [GNU-linux-libre] DSFG in perpetuity, Donald Robertson, 2018/04/06
- Re: [GNU-linux-libre] DSFG in perpetuity, Sam Geeraerts, 2018/04/08
- Re: [GNU-linux-libre] DSFG in perpetuity, bill-auger, 2018/04/08