Re: KDE phoning home
On Thu, 04 Sep 2025 15:33:01 +0200, Martin Steigerwald wrote:
Thank you for your prompt reply.
> Hi.
>
> Thanks for your findings.
>
> Rob Brewer - 04.09.25, 15:14:19 CEST:
>> Over the last few days my desktop has been attempting to connect to
>> 77.235.60.43 port 443 (about 350 attempts a day) which have been
>> dropped at my firewall as the IP is included in AS60781 (Leaseweb)
>> which has been listed in a local blacklist as a source of spam.
>>
>> A google search on this address would appear to show that this address
>> is crash-reports.kde.org although this cannot be confirmed with whois.
>
> % host crash-reports.kde.org crash-reports.kde.org is an alias for
> phasia.kde.org.
> phasia.kde.org has address 77.235.60.43 phasia.kde.org mail is handled
> by 10 letterbox.kde.org.
>
OK, but it's a bit odd because there isn't an RDNS for that address
Host 43.60.235.77.in-addr.arpa. not found: 3(NXDOMAIN)
> % geoiplookup 77.235.60.43 GeoIP Country Edition: NL, Netherlands
>
Unfortunately Leaseweb have been blacklisted here for over 12 months for
spamming another mailing list I am subscribed to and I was not aware of
anything useful on their servers.
>> Investigating my logs would seem to show that the connection attempts
>> seem to be associated with drkonqi-sentry-postman.service - Submitting
>> pending crash events, although I am not aware of any crash events
>> occurring on this computer over the last few days.
>
> Not using Systemd here, so cannot really comment on that. Grepping the
> process list during a running Plasma session for "konqi" or "sentry"
> does not reveal any processes.
>
I wish I wasn't using systemd but its difficult to run Debian without it.
The drkonqi-sentry-postman.service would seem to be on a timer which runs
at startup and on the hour and presumably started by systemd, so unless
you check the running process on the hour you would probably be unlikely
to notice it.
> But it should be possible to disable or mask the service? It might be a
> user session related service and disabling or masking it might need a
> special syntax. With "systemctl status" you should be able to find out
> the location of that service file. Would be interesting to see what
> binary it launches ("Exec=") and what package it is from ("dpkg -S").
>
I'm a bit out of my depth with systemd and cannot find any controlling
service that can be disabled to turn off the connections which are
presumably encrypted to 77.235.60.43 (port 443).
> As far as I am aware the KDE policy on sending data is opt-in, not opt-
> out. Yes, as confirmed by their privacy policy¹:
>
> "Where this functionality exists, it will always operate on an opt-in
> basis and be disabled by default, with the ability to change your
> preferences at any time."
Well I don't recall having turned it on. Looking at the Crashed Process
Viewer I get daily reports from light-locker and kleopatra which I wasn't
aware of as these happen at startup and been happening for at least the
last 12 months.
>
> So I think it might be good to report this upstream as I doubt that
> Debian Qt/KDE team adapted the specific setup of that Systemd service.
> Or possibly do both: A Debian bug report and an upstream one.
It's odd that my latest upgrade to drkonqi was to 6.3.4-1 on 3/4/25 so it
maybe a systemd package that has been upgraded but the upgrade dates don't
seem to correspond to the date I started seeing these firewall logs.
I'll have to dig some more to find out which package to send a bug report.
>
> So or so I would not assume any bad intention here. From all I have seen
> so far, the KDE project people are quite serious about privacy
> protection.
>
> [1] https://kde.org/privacypolicy-apps/
>
> Best,
I would be very surprised if there were bad intentions but I would like
the ability to disable the reporting but it seems to be hardwired into kde
somewhere.
Maybe it is easier to remove the firewall rule temporally and let drkonqi
connect and maybe it would stop further attempts to do so.
Kind Regards
Rob
Reply to: