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

[KRT Listmaster]

On 04/05/2018 03:01 PM, Luke wrote:
> 
> Per QT Docs, as long as QTLocation is not compiled then Google APIs for
> Geolocation should not execute.
> https://wiki.qt.io/QtWebEngine/Features#HTML5_Geolocation

Ah, ok, that makes sense.  So, I browsed to http://browserleaks.com/geo/

in Falkon, and I did see some Google API activity happening in the
background that seemed as if the QtLocation is still compiled into this
version, at least.  Bummer

> 
> Also Per QT, Google OAth shouldn't execute so as long as the Google API
> key is not included in the software.
> http://blog.qt.io/blog/2017/01/25/connecting-qt-application-google-services-using-oauth-2-0/
> (The same is true for Mozilla Firefox in both cases)
> 
> 

I'm not sure if this is as easy to test as the other, because I don't
even have a google account to be authorized with. But if the Geolocation
feature is a hint, then I'd assume this is still turned on as well, at
least in this package, by default.

So, how would one go about testing OAuth?  Would I need to have a google
account to test with?  And if I can log into something like
openstreetmaps.org using my Google account info, is that OAuth, or am I
oversimplifying things?

And the solution for privacy-minded folks then would be to either avoid
QtWebEngine entirely, or else compile your own with these turned off at
compile time?  Seems like a hassle

thanks for helping me explore,

- krt

-- 
This email account is used for list management only.
https://strangetimes.observer/

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

[KRT Listmaster]

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,
>>
>> -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:
> https://github.com/qt/qtwebengine-chromium/search?p=2=%22www.googleapis.com%22==%E2%9C%93
> 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:
> https://git.hyperbola.info:50100/packages/extra.git/tree/iceweasel-hardened-preferences/iceweasel-branding.js#n1009
> 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
started monitoring.

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 adblo

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

[KRT Listmaster]

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,

-krt


-- 
This email account is used for list management only.
https://strangetimes.observer/

Re: [GNU-linux-libre] Freeslack website

[KRT Listmaster]

Disclaimer:  I find this a particularly interesting conversation, and I
am posing genuine questions and thoughts that come to mind.  I am not
trying to ruffle any feathers or step on any toes.  With that in mind...

On 03/23/2018 11:51 AM, Ivan Zaigralin wrote:
> I'd like to register my dislike of the subjective approach to the name 
> similarity issue as well. Not that it doesn't work. I think it works OK, 
> because this is not a particularly big deal to begin with. FreeSlack project, 
> for example, has always been flexible in that respect, as in, fully 
> cooperative. But it would be better to have an objective criterion, like for 
> example:
> 
> Cannot use nonfree distro name or trademark as a substring in a free distro 
> name.
> 
> A rule like this would prevent "Slackware Libre", but not "FreeSlack". But 
> more crucially, it would be fair, and no one would ever feel like an 
> individual reviewer at FSF is yanking their chain just for the fun of it. 
> 

There's a obvious limit to how far this goes.  If this general concept
is pushed to it's logical extreme, then we'd have to drop the GNU-prefix
from everything as well.  Because, doesn't the U stand for... Unix?

I started thinking about what a cool name for FreeSlack (which could be
seen as a general term taken from project management theory [1]) would
be if Freenix was rejected for some reason, and FXP wasn't accepted
either.

A couple of joke names came to mind, and I finally settled on:

§NH - which stands for §NH is Not Hyperbola

and was my way of avoiding

§NS , short for §NS is Not Slackware

and, only then I started to wonder if the negation makes things okay.

and then it all clicked into place.

GNU would fail this same criterion if proposed today.  Just a thought.

;-)

- krt

[1]
https://www.coursera.org/learn/scope-time-management-cost/lecture/Gsh3x/free-slack

-- 
This email account is used for list management only.
https://strangetimes.observer/

Re: [GNU-linux-libre] Freeslack website

[KRT Listmaster]

On 03/23/2018 02:12 AM, Henry Jensen wrote:
> Hi,
> 
> I just visited the website of freeslack and noted there is a link to
> Eric Hameleers website right on the front page. On his website he does
> prominently offer and links to several third-party packages, including
> complete proprietary software, such as Adobe Flash Player.
> 
> Since this website is mentioned in a positive way on freeslack.net
> one may be tempted to install this non-free software. I suggest to
> remove this link.
> 
> Regards,
> 
> Henry
> 

That's a good point, thanks for pointing it out, it might indeed be
worth removing.  Questions:  should this criterion be applied across the
board?  How does this differ from say, the PureOS website[1] having a
link to the Purism website[2] in the footer, which mentions plenty of
non-free software, including a tutorial on how to enable their own
non-free repo[3].  Just curious

thanks,

- krt

[1] https://pureos.net/
[2] https://puri.sm/
[3]
https://puri.sm/posts/purism-patches-meltdown-and-spectre-variant-2-both-included-in-all-new-librem-laptops/


-- 
This email account is used for list management only.
https://strangetimes.observer/

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[KRT Listmaster]

On 08/06/2017 10:37 AM, Jason Self wrote:
> Henry Jensen  wrote ..
> 
>> The link to the freeslack project shouldn't be a problem, since
>> the page at https://www.gnu.org/distros/common-distros.html links
>> to the very same project.
> 
> There is no reference to FreeSlack on that page, only Slackware.
> 
> But even if we consider Slackware, what is being said also be
> considered: That page is discussing why Slackware is not acceptable
> for adding as an FSF-endorsed distro.
> 
> In comparison, the text I'm referring to is an out-and-out referral to
> go *use* it if someone wants a 64-bit version: "If you are looking for
> a libre Slackware x86_64 variant you are welcome to use the x86_64
> slack-n-free repo and have a look at the FreeSlack project."
> 
> In one case, the statement (on gnu.org) is about why Slackware is not
> acceptable. The other is a statement to go use it if they want 64-bit.
> These are not the same. An FSF-endorsed distro shouldn't steer people
> to using ones that are not.

This is a misunderstanding, I think.  There is an indirect reference
(via a weblink) at the end of the Slackware section on the gnu.org when
it says

"There is an unofficial list of nonfree software in Slackware.",

the words "unofficial list" link to

http://freeslack.net/

which has evolved beyond a mere list and is now a fully installable
distro.  So, when ConnochaetOS suggests using "it", they mean FreeSlack,
which has every intention of being a fully-libre distro with
downloadable and installable iso files while adhering to the GNU-FSDG [1].

The link to the same project website (which cross-suggests ConnochaetOS
for 32-bit users) is just worded poorly on the gnu.org page.  Neither is
suggesting the use of Slackware proper.  However, both links ARE
referring to a fully-libre software project, regardless of current
FSF-endosement status.

- KRT

[1] https://freeslack.net/dokuwiki/doku.php?id=project_goals

-- 
This email account is used for list management only.