Closed Bug 1369776 Opened 8 years ago Closed 8 years ago

Requesting a permission again after removing it prompts the user again

Categories

(WebExtensions :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: wbamberg, Unassigned)

Details

(Whiteboard: [design-decision-denied] triaged)

Attachments

(1 file)

Attached file perms.zip
According to the Chrome docs: "After a permission has been removed, calling permissions.request() usually adds the permission back without prompting the user. "(https://developer.chrome.com/extensions/permissions#remove). I'm not sure what "usually" unpacks to here, but... I've attached an add-on that adds a browser action. Clicking the browser action loads a bundled page with three buttons: "request" requests a permission "remove" removes it "list" lists current permissions In Chrome, the behavior is as the docs say: clicking "request' for the first time prompts, then if you click "remove" then "request" you're not prompted again, but the permission is granted silently. In Firefox this does not happen: you get prompted every time you click "request".
Hm, thanks for bringing this up, I never noticed that in the Chrome docs. ni? to paul to get input from the security perspective
Flags: needinfo?(ptheriault)
I dunno what to say here, Im still trying to get my head around the point of optional permissions are. But I'll deflect this question to Christiane and Freddy as well since they have been looking into these permissions (and Im on PTO) I think the key thing here is why are we asking for the prompt. I assume the user isnt involved in the 'remove' flow, so as far as the user is concerned, they are asked for the permission once, and then they assume the addon has this permission (in perpetuity?) I don't really understand why the app would 'unrequest' a permission - maybe to be a good citizen and drop permissions it doesnt need. But if it can re-add the permission silently then what is that point? If anything now the user is worse off, as the addon could transiently request permissions only when they use it. AFAIK we dont show a list of permissions to users, but we might in the future. It would be bad if addons could hide their permissions usage by just toggle their own permission states. But maybe Im missing the point of optional permissions here.
Flags: needinfo?(ptheriault)
Flags: needinfo?(fbraun)
Flags: needinfo?(cr)
There are several reasons for optional permissions: 1. It lets extensions connect actions a user is taking with the need for specific permissions. So rather than getting a big list at install time and having to make an all-or-nothing decision up front, a user is prompted at the moment they try to use a feature of an extension that requires a specific permission(s). 2. For things like host/origin permissions, an extension might not know what origins it will be asked to access until runtime. Without optional permissions, an extension would generally just request <all_urls>, giving it for more extensive privileges than what it actually needs. 3. If a big extension has optional features, some of which require extra permissions, its lets users use the part of the extension they are interested in without granting additional unwanted permissions for features they don't want. As for why an extension would drop permissions, its really just to allow them to follow the principle of running without unneeded privileges, so that the impact of any vulnerability in the implementation of the extension is minimized. If that's something we want to encourage, that would be an argument for implementing the behavior described in this bug (since as it stands now, extension authors are dis-incentivized from dropping permissions they may request again later since that can lead to annoying over-prompting). Anyway, its true that users are not involved or notified when permissions are revoked. And we don't currently have a way for users to see (or manually revoke) permissions they have already granted. I think if we do implement the behavior described in this bug, it needs to be taken into account when showing granted permissions to users.
I agree that flow of request, remove, request is odd, but I can't see anything exceedingly harmful here. Depending on how an add-on keeps state, I suppose it makes sense not to re-check existing permissions but just asking onclick for the current tab/website. Naturally, this will lead to a request/remove/request flow. The more dynamics we have in terms of changing permission, I think the more important it is, that we have a way to get clear visibility into current, but also past permissions (like a permission backlog that contains entries for every change including add-on/principal, permission name, timestamp, action (remove/request,list)).
Flags: needinfo?(fbraun)
Elaborating on Andrew's list, the purpose of optional permissions in my book is to allow the developer to split off permissions that - few users will ever require, or - users should have the option to deny but still get an otherwise working extension. The concept encourages devs to handle permission denial in a graceful manner instead of running the user into a global on-install "all or nothing" situation. You can still get a lot out of that map extension without giving it access to your location, for example. In general I think there is nothing wrong with caching the user's choice and prevent prompts accordingly on re-requests. Problems may arise from the added complexity, though. Just re-prompting every time *would* also make for a simplistic form of permission management with cooperative extensions should users change their mind. I am saying *would* because the current implementation in Firefox 55 never seems to revoke an optional permission until the browser is restarted even if the user clicks "deny" on a consecutive prompt. The extension has to explicitly drop the permission for that to happen.
Flags: needinfo?(cr)
Whiteboard: [design-decision-needed] triaged
Hi Will, this has been added to the agenda for the August 1 WebExtensions APIs triage meeting. Would you be able to join us? Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting Agenda: https://docs.google.com/document/d/1l5zlSASqZAzzJGZhHtLWY1yaUwCKZiHXXGP1k_2W-TU/edit#
Flags: needinfo?(amckay)
From memory in the meeting this was decided to do nothing here, let Firefox keep prompting after the user removed the optional permission. > I am saying *would* because the current implementation in Firefox 55 never seems to revoke an optional permission until the browser is restarted even if the user clicks "deny" on a consecutive prompt. The extension has to explicitly drop the permission for that to happen. Is there a bug for this? That seems not intentional.
Flags: needinfo?(cr)
I think you're seeing bug 1352239 which is fixed in 56. With that fix in place, if an extension requests a permission that it already has, there's no prompt (so no opportunity to choose "deny")
> Is there a bug for this? That seems not intentional. This came up during an optional permissions review in May[1], but never made it into a dedicated bug. I reported it here because it seemed related. [1] https://docs.google.com/document/d/128jZdUPeiBOJ4-sw-T21hBRl8YP_q2yhkJDtZC-GUTA (last page)
Flags: needinfo?(cr)
I think at this point its fine to keep our simple implementation in place. It keeps our codes simpler and it keeps the flow for users and developers very clear. It diverges a little from Chrome, but not in a way that negatively affects much. The benefits of simplicity outweigh the rest here. Statistics for optional permissions in Chrome extensions show that they are rarely used at this point so this scenario is probably quite rare. We can revisit this in the future if we need to, so let's not do this for now.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(amckay)
Resolution: --- → WONTFIX
Whiteboard: [design-decision-needed] triaged → [design-decision-denied] triaged
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: