[Top][All Lists]

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

Re: [GNU-linux-libre] DSFG in perpetuity

From: Luke
Subject: Re: [GNU-linux-libre] DSFG in perpetuity
Date: Wed, 4 Apr 2018 18:39:39 -0400
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101, Thunderbird/52.2.1

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 *
> and *, 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,
> -krt
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!

reply via email to

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