GNOME Bugzilla – Bug 762559
location: Ask user only once
Last modified: 2018-06-26 12:44:55 UTC
If app's location access is disabled by another entity (control-center), we don't want to simply delete the app's permission data from the store. We only want to do that when user is consulted and they decided to not grant access to the application.
Created attachment 322165 [details] [review] location: Only delete app permissions if user consulted
Actually I have to put in a few other fixes/improvements (at least one :)
Created attachment 322400 [details] [review] location: Only ask user once Let's make it really simple and ask user interactively, once. This simplies things for: * Privacy panel of gnome-control-center as it doesn't have to filter applications. * Apps: If they are denied access, they can simply point users to privacy panel of gnome-control-center since they can be sure location access for the app can be enabled in there. Also it's less annoying to user. Before this patch, if they denied access to application, they have to keep doing that at least each time they launch the application.
Review of attachment 322400 [details] [review]: > simplies simplifies > they have to keep they had to keep Rest looks fine to me.
Created attachment 322756 [details] [review] location: Only ask user once Let's make it really simple and ask user interactively, once. This simplifies things for: * Privacy panel of gnome-control-center as it doesn't have to filter applications. * Apps: If they are denied access, they can simply point users to privacy panel of gnome-control-center since they can be sure location access for the app can be enabled in there. Also it's less annoying to user. Before this patch, if they denied access to application, they had to keep doing that at least each time they launch the application.
Created attachment 322765 [details] [review] location: Only ask user once Let's make it really simple and ask user interactively, once. This simplifies things for: * Privacy panel of gnome-control-center as it doesn't have to filter applications. * Apps: If they are denied access, they can simply point users to privacy panel of gnome-control-center since they can be sure location access for the app can be enabled in there. Also it's less annoying to user. Before this patch, if they denied access to application, they had to keep doing that at least each time they launched the application.
(In reply to Zeeshan Ali (Khattak) from comment #3) ... > Let's make it really simple and ask user interactively, once. This > simplies things for: > > * Privacy panel of gnome-control-center as it doesn't have to filter > applications. > > * Apps: If they are denied access, they can simply point users to > privacy panel of gnome-control-center since they can be sure location > access for the app can be enabled in there. Note that this would require changing the behaviour in Maps, which we only recently changed (see bug 762594). I have to say, I'm not very happy about decisions like this being made at this stage in the release cycle. > Also it's less annoying to user. Before this patch, if they denied > access to application, they have to keep doing that at least each time > they launch the application. It's less annoying, but it also means that users lose the ability to try an app out without granting permanent access. If this change is made, we'll probably need to change the text in the shell dialog to indicate that granting access is permanent, and that access can be managed from the privacy settings.
(In reply to Allan Day from comment #7) > (In reply to Zeeshan Ali (Khattak) from comment #3) > ... > > Let's make it really simple and ask user interactively, once. This > > simplies things for: > > > > * Privacy panel of gnome-control-center as it doesn't have to filter > > applications. > > > > * Apps: If they are denied access, they can simply point users to > > privacy panel of gnome-control-center since they can be sure location > > access for the app can be enabled in there. > > Note that this would require changing the behaviour in Maps, which we only > recently changed (see bug 762594). Not really. Actually it will help Maps keep it's current behaviour since if access is denied, showing the link to privacy panel will always been correct. OTOH keeping the 3-times behaviour, apps currently have no idea if user interactively denied access or just blocked the app permanently through the privacy panel (and therefore they should provide a link to privacy panel). I'll have to do quite a bit of work in Geoclue/shell etc to let the apps know why the access was denied and I'm not sure apps should have access to this detail. > I have to say, I'm not very happy about decisions like this being made at > this stage in the release cycle. I don't think it's a big change at all. Instead of asking 3 times, we just ask once. It's extremely unlikely to break anything cause the behaviour being changed is itself extremely new. > > Also it's less annoying to user. Before this patch, if they denied > > access to application, they have to keep doing that at least each time > > they launch the application. > > It's less annoying, but it also means that users lose the ability to try an > app out without granting permanent access. Not really, they can change their preferences from privacy panel. If privacy panel settings (bug#761245) don't make it through to 3.20, I'll also be pulling back the gnome-shell changes. > If this change is made, we'll probably need to change the text in the shell > dialog to indicate that granting access is permanent, and that access can be > managed from the privacy settings. Sure!
So a note from Maps here. Right now we do not handle this well. We only show the link to privacy panel if the gsetting for location service is off. And that gsetting is gone now? There is patch suggestion do show privacy panel when we get ACCESS_DENIED from geoclue. But it is not merged. And currently segfaults... So no... Maps does not work well with the current behavior or with the new suggested here. Sorry :) I was caught off-guard with these changes.
(In reply to Zeeshan Ali (Khattak) from comment #8) > (In reply to Allan Day from comment #7) > > (In reply to Zeeshan Ali (Khattak) from comment #3) > > ... > > > Let's make it really simple and ask user interactively, once. ... > > Note that this would require changing the behaviour in Maps, which we only > > recently changed (see bug 762594). > > Not really. Actually it will help Maps keep it's current behaviour Can you explain? Currently Maps requests access if it has been denied in the past and the find location button is pressed. In this bug you are proposing that apps point the user to the privacy settings instead of requesting access again. Which behaviour do you want Maps to have for 3.20? ... > > > Also it's less annoying to user. Before this patch, if they denied > > > access to application, they have to keep doing that at least each time > > > they launch the application. > > > > It's less annoying, but it also means that users lose the ability to try an > > app out without granting permanent access. > > Not really, they can change their preferences from privacy panel. Some users might do that, but a lot won't go digging in their settings to turn off access. > > If this change is made, we'll probably need to change the text in the shell > > dialog to indicate that granting access is permanent, and that access can be > > managed from the privacy settings. > > Sure! OK, so should I be working on new mockups?
(In reply to Jonas Danielsson from comment #9) > So a note from Maps here. > > Right now we do not handle this well. We only show the link to privacy panel > if the gsetting for location service is off. And that gsetting is gone now? The setting is not gone, no. I explained this to you. Apart from the global settings, we now have per-app settings (or rather we will have). > There is patch suggestion do show privacy panel when we get ACCESS_DENIED > from geoclue. But it is not merged. And currently segfaults... > > So no... Maps does not work well with the current behavior or with the new > suggested here. Sorry :) I was caught off-guard with these changes. Yes, i know that there is a disruption for Maps but there is less of a disruption, if you can simply assume that showing "privacy panel" button is relevant if you are denied access. I'll look into your crash again today.
(In reply to Allan Day from comment #10) > (In reply to Zeeshan Ali (Khattak) from comment #8) > > (In reply to Allan Day from comment #7) > > > (In reply to Zeeshan Ali (Khattak) from comment #3) > > > ... > > > > Let's make it really simple and ask user interactively, once. > ... > > > Note that this would require changing the behaviour in Maps, which we only > > > recently changed (see bug 762594). > > > > Not really. Actually it will help Maps keep it's current behaviour > > Can you explain? Currently Maps requests access if it has been denied in the > past and the find location button is pressed. In this bug you are proposing > that apps point the user to the privacy settings instead of requesting > access again. I'm not sure that is correct. AFAIK Maps does not currently (at least 3.18) ask for access again if it's been denied access but rather points to privacy panel. I'm saying it can keep this behaviour since it'll make sense with this change I'm proposing in shell. > ... > > > > Also it's less annoying to user. Before this patch, if they denied > > > > access to application, they have to keep doing that at least each time > > > > they launch the application. > > > > > > It's less annoying, but it also means that users lose the ability to try an > > > app out without granting permanent access. > > > > Not really, they can change their preferences from privacy panel. > > Some users might do that, but a lot won't go digging in their settings to > turn off access. > > > > If this change is made, we'll probably need to change the text in the shell > > > dialog to indicate that granting access is permanent, and that access can be > > > managed from the privacy settings. > > > > Sure! > > OK, so should I be working on new mockups? Yes please. :)
I talked about this bug with Jakub yesterday. We both feel that there are benefits to both approaches (ask three times versus ask once), and that there's not a huge amount in it. However, it should be said that the ask three times behaviour is more focused on third party applications, and is more suited to ecosystems where there are lots of (potentially untrustworthy) apps to try. In my mind, this raises two issues: 1. Should we default to giving core apps access to location data? This would allow the "try before giving permanent access" behaviour (asking three times) for third party apps, without being annoying for those apps that we do trust. 2. If we were to switch to asking once rather than three times, would we have the option of changing back to asking three times in the future (say, if the number of apps using location data increased)? It would be good to be able to do this without having to make changes to application behaviour.
Created attachment 322966 [details] mockups Here's mockups for each variant of the access dialog.
(In reply to Allan Day from comment #13) > I talked about this bug with Jakub yesterday. We both feel that there are > benefits to both approaches (ask three times versus ask once), and that > there's not a huge amount in it. > > However, it should be said that the ask three times behaviour is more > focused on third party applications, and is more suited to ecosystems where > there are lots of (potentially untrustworthy) apps to try. In my mind, this > raises two issues: > > 1. Should we default to giving core apps access to location data? This > would allow the "try before giving permanent access" behaviour (asking three > times) for third party apps, without being annoying for those apps that we > do trust. I'm not sure I follow. How is giving core apps access is related to how many times we ask the user for third party apps. > 2. If we were to switch to asking once rather than three times, would we > have the option of changing back to asking three times in the future (say, > if the number of apps using location data increased)? It would be good to be > able to do this without having to make changes to application behaviour. Currently the only application that's affected by this change is Maps and I think that might be the only application that will have to be chagned if we go for 'asking multiple times'. Given that existing Maps (in git master) is behaving as expected for asking once case but will need re-work (and re-design) to handle the 3 times case. So even if we think that we're likely going to switch to asking 3 times later, it make sense to go with asking once for 3.20.
(In reply to Zeeshan Ali (Khattak) from comment #15) > (In reply to Allan Day from comment #13) > > I talked about this bug with Jakub yesterday. We both feel that there are > > benefits to both approaches (ask three times versus ask once), and that > > there's not a huge amount in it. > > > > However, it should be said that the ask three times behaviour is more > > focused on third party applications, and is more suited to ecosystems where > > there are lots of (potentially untrustworthy) apps to try. In my mind, this > > raises two issues: > > > > 1. Should we default to giving core apps access to location data? This > > would allow the "try before giving permanent access" behaviour (asking three > > times) for third party apps, without being annoying for those apps that we > > do trust. > > I'm not sure I follow. How is giving core apps access is related to how many > times we ask the user for third party apps. Asking three times is useful for third party apps, because it gives the user opportunity to try the app without giving it permanent access to location data. However, it is also potentially annoying. Not asking for core apps would help to mitigate the annoyance factor while retaining the useful ask three times behaviour for third party apps. > > 2. If we were to switch to asking once rather than three times, would we > > have the option of changing back to asking three times in the future (say, > > if the number of apps using location data increased)? It would be good to be > > able to do this without having to make changes to application behaviour. > > Currently the only application that's affected by this change is Maps and I > think that might be the only application that will have to be chagned if we > go for 'asking multiple times'. Given that existing Maps (in git master) is > behaving as expected for asking once case but will need re-work (and > re-design) to handle the 3 times case. So even if we think that we're likely > going to switch to asking 3 times later, it make sense to go with asking > once for 3.20. I'm not talking about Maps. My point was more about what would happen if third party apps adapt to the ask once behaviour, and then we change (potentially a while in the future) to ask three times.
(In reply to Allan Day from comment #16) <snip> > > > 2. If we were to switch to asking once rather than three times, would we > > > have the option of changing back to asking three times in the future (say, > > > if the number of apps using location data increased)? It would be good to be > > > able to do this without having to make changes to application behaviour. > > > > Currently the only application that's affected by this change is Maps and I > > think that might be the only application that will have to be chagned if we > > go for 'asking multiple times'. Given that existing Maps (in git master) is > > behaving as expected for asking once case but will need re-work (and > > re-design) to handle the 3 times case. So even if we think that we're likely > > going to switch to asking 3 times later, it make sense to go with asking > > once for 3.20. > > I'm not talking about Maps. My point was more about what would happen if > third party apps adapt to the ask once behaviour, and then we change > (potentially a while in the future) to ask three times. The application should require no changes. The dialogue is provided by gnome-shell, and it's the agent, the service that says how many times an application should ask before being granted geolocation information. It's going to be more complicated showing this behaviour in the control-center's settings, to be honest, but that's a discussion for later.
Review of attachment 322765 [details] [review]: Code looks fine, but doesn't include any of the changes for the "ask-once" case in the mockup
Review of attachment 322765 [details] [review]: well the mockup came after. :) Can't we do that in 3.91.92?
Review of attachment 322765 [details] [review]: Obviously I meant 3.19.92. :)
(In reply to Zeeshan Ali (Khattak) from comment #20) > Obviously I meant 3.19.92. :) If we do it now, we can just do it. If we wait for 3.19.92, we'll have to ask for a freeze break. As far as I can see, we need to change a label and swap two elements around - not sure why we'd want to delay that to after string freeze.
(In reply to Florian Müllner from comment #21) > (In reply to Zeeshan Ali (Khattak) from comment #20) > > Obviously I meant 3.19.92. :) > > If we do it now, we can just do it. If we wait for 3.19.92, we'll have to > ask for a freeze break. As far as I can see, we need to change a label and > swap two elements around - not sure why we'd want to delay that to after > string freeze. We are already in UI freeze so we gotta ask for permission anyway, no?
(In reply to Zeeshan Ali (Khattak) from comment #22) > We are already in UI freeze so we gotta ask for permission anyway, no? I would consider the change minor enough to sneak it in, but when in doubt, asking may be the better option. So if you are about to ask anyway, feel free to commit the partial change now and update the dialog in a follow-up patch after 3.19.91 ...
Comment on attachment 322765 [details] [review] location: Only ask user once Attachment 322765 [details] pushed as 3492121 - location: Only ask user once
What's left to do in this task?