SUMMARY Currently, a location request for example by the night color applets is silently answered by using gpsd or mozillas geolocation service. In case of the latter one, all (not hidden, no "_nomap") SSIDs are sent to mozilla. It should be apparent to the user that a thirt-party request is made and that the SSIDs are transmitted. I also doubt that the lines in the privacy policy are correct here: > As a general rule, software produced by the KDE Community does not collect, transmit or otherwise transfer information from end-users devices except as a result of an explicit user action. … > In some instances, our software may also provide the option for periodic automated checks, such as to check for new email or system software updates. Where these periodic automatic checks do exist, the option will be provided to disable them and only the minimum information needed to perform the periodic check will be transmitted. I propose that before any geolocation request is handled (wether answered by gpsd or mozilla) a notification should be made to the user wether to accept the request or deny it, with the option to trust this app (which will allow it to request locations without confirmation). Specifially, this notification should contain that mozilla's geolocation is used (including sending SSID names) and a link to their privacy policy. Also a option to disable the mozilla geolocation (and only use gpsd) would be a good idea. (I could find anything in plasmaengineexplorer)
I don't think the dataengine is the right level for this. It needs to be in the UI of the relevant calling code. Am I right your report is about the night colour KCM not being explicit enough?
(In reply to David Edmundson from comment #1) > I don't think the dataengine is the right level for this. > > It needs to be in the UI of the relevant calling code. > > Am I right your report is about the night colour KCM not being explicit > enough? Yes, it is originally about the night color applet. But don't you agree that a uniform notification about location request would be a good idea? It will be impossible to be as strict as android (the application could call gpsd/mozilla geo directly), but it would be apparent to the user that application xy requested the location.
*** Bug 418128 has been marked as a duplicate of this bug. ***
I found this bug report via Reddit while trying to figure out why KDE wasn't getting my location automatically under "Night Color" settings. What are the dependencies for "detect location" to work?
(In reply to David Edmundson from comment #1) > I don't think the dataengine is the right level for this. > > It needs to be in the UI of the relevant calling code. > > Am I right your report is about the night colour KCM not being explicit > enough? Since he marked my older report as a duplicate: It is about sending unauthorized requests without asking user's consent prior to it. I don't see how this could be considered acceptable behaviour, sending requests to 3d party sites w/o - asking whether it is ok at all - explaining what purpose it serves - what feature triggered it - what kind of data is sent (and why) For my part I was able to get rid of it by playing around haphazardly -- learning that it is related to the Night color applet does not really help, since I never knowingly used it nor would I have wanted it -- nor do I understand why that functionality is forced upon me without the slightest regard to my wishes. Adding insult to injury by sending personal data without consent or information certainly does not improve things.
I can add a UI in the night color applet.
I think it should be the task of the program invoking the dataengine location request to ask the user for consent to submit the data. For the nightcolor applet, this means either a) ask the user initially (via a notification/popup; but probably bad to be overwhelmed by a popup right after installation), when starting first time, wether they want to use the auto-geolocation (and send their surrounding Wifi SSIDs) or wether they want to specify the location manually (may be make this step easier by entering zip code/clicking on map?). It is crucial for privacy, to have a proper, informed decisison of consent. b) Have a reasonable default option, which gets the location close enough for the nightcolor applet (without using external services). It doesn't have to be super exact, and maybe an educated guess based on the country specified in the settings or the timezone would be appropiate (being off by 20 minutes wouldn't be too bad, but being of by 2 hours would).
Having the user explicitly choose and approve a method when the feature is turned on can be done in a non-intrusive way. At this point the issue is me finding the relevant information to display to the user...
Proposed solution: By default, no geolocation is attempted. If user selects "Manual location" and clicks "Detect location", geolocation starts. If user selects "Current location", geolocation starts (and then keeps happening regularly). User is informed that the location will keep being updated in the background. (IMO the act of selecting these is deliberate enough that we don't need prompts after user has selected them) I've done the implementation. If this is an acceptable solution, I can make an MR.
*** Bug 441355 has been marked as a duplicate of this bug. ***
Given that the feature is off by default and turning it on requires a deliberate action, I think all we need to do is notify the user what's going to happen if they select an option that requires geolocation. A simple label below the combobox may be enough. The reason why I didn't add this already was because I wanted to be able to provide a "Show More..." link that took the user to a detailed technical indication of what was going on (which geolocation service, whether any personal information would be sent, how often it would be updated, etc).
Alright. In the meantime I'll submit the MR to fix the sub-problem described in the duplicate: geolocation is attempted whenever the Display and Monitor KCM is opened, even if Night Color is off and/or its automatic location isn't chosen.
Don't let me discourage you from submitting an MR to fully fix this in your own estimation if you think your approach works too. I wasn't trying to discourage you. :) We can always add more technical details later.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1016
Git commit bad72c931e95bfb325ece391e0ffc6e0153d9d51 by Nate Graham, on behalf of Bharadwaj Raju. Committed on 23/08/2021 at 18:07. Pushed by ngraham into branch 'master'. [kcms/nightcolor] Inform user when geolocating, and only do it when needed Related: bug 441355 FIXED-IN: 5.23 M +24 -11 kcms/nightcolor/package/contents/ui/LocationsFixedView.qml M +37 -4 kcms/nightcolor/package/contents/ui/main.qml https://invent.kde.org/plasma/plasma-workspace/commit/bad72c931e95bfb325ece391e0ffc6e0153d9d51