Define Add-on Permission UI
designakt opened this issue · 33 comments
How does surfacing permissions help the user?
What do we need to surface on install, update, or request of optional permissions?
What should the user control, and what could the user control?
UX Bug 1229230
Engineering Bug 1197420
Need more info on the permission model and context to understand what UI needs to be in place.
I see three parts to this project:
- Displaying permissions
- Granting permissions
- Revoking/editing permissions
Displaying permissions
Advanced users might want to know what permissions an add-on is asking for and manage them. Most users don’t care and just want their add-ons to work.
So, a good principle to follow seems to be to provide information only to those who want it.
Execution: on add-on listing page
- Create a new section called “Permissions” – this section doesn’t need to be very prominent. Just needs to be accessible to advanced users
- Under this section, we can say something like “This add-on can access… [permission_list]”
Granting permissions
I posited above that most users wants the add-on to work in way that’s “one-click install-and-forget”. Unfortunately, the more permissions dialogue we display, we’re going to get people who not be able to successfully active the add-on.
A good principle to follow seems to be:
- Provide maximum security to every user
- Grant permissions in the least number of clicks possible
Alternative 1: ask user to give the add-on all the permissions that it requires
This can be done at either one of these two points in time:
- Before installing, or
- Before firstrun
- Pros: user will only ever see one dialogue box
- Cons: user has no idea what this dialogue means and will most probably click “Install” or “Allow all” without understanding what it means
Alternative 2: ask user to give permission only when specific features within the add-on is activated
For example, I have an audio-recorder add-on. The add-on will only ask for permission to access my microphone when I click the “Record” button.
- Pros: there is no dialogue box to block add-ons from installing or firstrun, preserving the one-click-install experience
- Cons: user can potentially go through more than one permissions dialogue
Revoking/editing permissions
We will need an interface to manage permissions after it’s been granted.
I think that a good place to put this is under about:addons > [addon_name] > Preferences > create a new section called “Permissions”.
We put each permission there, and user can revoke at will.
Thoughts?
Would there be anything about non-WebExtension add-ons? There's a couple of concerns here:
- non-WebExtension add-ons have a lot more permission to do things to Firefox
- if a WebExtension add-on needs no permissions that require user input, nothing will be shown
- if a WebExtension add-on needs permissions that require user input, something will be shown somewhere
The downside is that a WebExtension add-on that still can do less harm to a user than an old style add-on triggers the warning. For a end users point of view it might appear worse. And that's a disincentive for WebExtensions.
If all this puts in place a prompt for users, does this also make sense for old style add-ons? Maybe a question for product.
Do we want old-style add-ons to start asking for permissions like WebExtensions add-ons can? We’ve never done this before. And given the fact that we’re moving to a WebExtensions future, it’s probably not a good idea. But this is a product question.
For WebExtension add-ons, as you said, they will be less attractive than old style add-on that don’t/can’t ask for permissions. One potential solution here is to ask for user approval prior to install instead of prior to permission activation. So instead of saying “Do you want to install {addon_name}?”, we say instead “Do you want to install {addon_name}? It requires {permission_1}, {permission_2}, etc.” It’s not the best in terms of security, but it’s the least interrupting.
An interesting example of permissions experienced with Momentum on Chrome:
One is shown some permissions on install:
After that the extension is installed, an icon appears in the toolbar and a door-hanger confirming the installation appears. And from then on the extension is active and replaces the newTab page.
On ones first encounter with the new newTab page, Chrome will - after some delay - prompt if this is the page one expects.
If one does not act on that prompt, Chrome will show it again on the next restart of the browser (but not every time one opens a newTab in the current Session).
Learn more in that dialog links to the Chrome Web Store Help on the topic of permissions.
And settings that have been changed by an extension, show up in Chromes settings with a reference to the respective extension:
Interesting to see that the extension is allowed to modify the browser first, and only later the users is asked if they accept that change. This gives the user time to understand the effect and prevents a more abstract decision upfront.
On Safari it feels like they don't inform about the addon's permissions.
Atfer Downloading Recent tab List, an Addon which is able to read and track through your recently closed Tabs. Is just installed and then active.
Strong preference for Alternative 2, prompting at time-of-use for sensitive APIs. It's consistent with the Web Platform (we prompt on use for geolocation, getusermedia, notifications, etc.) and it allows users to make more informed decisions since the prompt is temporally correlated with a specific directed action.
Furthermore, Android initially used the permission-at-install model for apps, and was widely panned for its inscrutability. In Android 6, Google moved to the prompt-on-use model. iOS has followed this model for several years.
Given the convergence to prompt-at-use in all other platforms, I suspect this model would be consistent with the expectations of users and developers.
Permissions prioritization in Chrome:
Chrome is using a prioritization of how critical the permissions are.
I like the idea of this system, wether we should rethink/clarify the prioritization for Firefox. Pre-installation Notifications could be tagged or seperated into the different required permissions weight. There should also be a way to display, which permissions are optional and which ones are required for the addon to work.
At the moment chromes prioritization looks like the following list.
light-weight:
- Your list of installed apps, extensions and themes: The app or extension can enable, disable, uninstall or launch themes, extensions, and apps you have installed.
- Your bookmarks: The app or extension can read, change, add to, and organize your bookmarks.
- Your browsing history: The app or extension can read and erase your browsing history.
- Your tabs and browsing activity: The app or extension can see the URLs and titles of websites you visit. It can also open and close tabs and windows, as well as navigate to new pages in open tabs and windows.
- Your physical location: The app or extension can use the current location of your computer or device.
- Data you copy and paste: The app or extension can access information you've copied and pasted
- Optional permissions will ask you to deny or allow permissions after the app or extension has been installed. When you allow optional permissions, you can't change them after.
medium-weight:
- Your data on all the websites you visit gives access to read, request or modify data from every page you visit (bank account, Facebook).
- Your data on a list of websites gives access to read, request or modify data on pages you visit on a list of specified websites.
critical-weight:
- When the permission requires access to all data on your computer and the websites you visit, it means that the app or extension can access almost anything (webcam, personal files), inside or outside of your browser.
I did a quick version to visualize the idea of different pre-install notifications, based on the addon permissions weight, using the design of my concepts at Install Confirmations to stay consistent.
Activating Permissions:
Based on the different permissions, we have to decide:
1. We don't activate this permission, unless the the user "Grants" activation
- geolocation
- desktopCapture
- management
- printerProvider
- privacy
2. We activate this permission, but the user is able to "Revoke"
- background
- bookmarks
- browsingData
- downloads
- history
- nativeMessaging
- notifications
- power
- tabs
- topSites
- wallpaper
3. We activate this permission, the user can "view only" not edit/revoke
- activeTabs
- alarms
- audioModem
- clipboardRead
- clipboardWrite
- contentSettings (unclear yet)
- contextMenus
- cookies
- debugger
- declarativeContent
- experimental (unclear yet)
- fontSettings
- gcm
- identity
- idle
- pageCapture
- proxy (unclear yet)
- sessions
- storage
- system.cpu
- system.display
- system.memory
- system.storage
- tabCapture
- tts
- tts-Engine
- unlimitedStorage
- webNavigation
- webRequest
- webRequestBlocking
List of existing defined permissions
(Work in progress / feel free to comment )
Concepts of different treatment:
1. We don't activate this permission, unless the user "Grants" activation
Before the add-on will be installed, the user is asked to grant the addon's critical permissions. If he grants, the add-on will be installed. If he denies the permissions, the add-on won't be installed.
Sidenote:
- a "Learn more" link to the detailed desciptions and information about add-on permissions in general would be a good idea at this point.
2. We activate this permission, but the user is able to "Revoke"
After the add-on is installed, the user is able to view the addon's permissions. There will be needed and optional permissions in the list. If he decides to "revoke" needed permissions, the add-on will be deactivated. A notification will inform the user that the permission is required to keep the add-on activated/working properly. If he decides to "revoke" an optional permission, he can just do this, without having the add-on deactivated. One way to view the add-on's permissions would be to show them on the user's installed add-ons page.
If he grants, the add-on will be installed.
If, at that point, the add-on isn't installed, I wonder where this panel can be attached to? Or if it need to be attached to anything at all.
The action shortly before the install is somehow related to downloads. So attaching it to the download-button, as shown in the concept would make sense.
Max wrote:
…attaching it to the download-button, as shown in the concept would make sense.
This makes sense if the add-on does not modify the UI.
However, if the add-on is adding a new icon to the toolbar (for example, AdBlock Plus or Video DownloadHelper), one thing we can do is add the icon at 50% opacity and ask “Do you want to install this thing that’s behind this icon?”. If user says yes, we then install the add-on and ‘fade in’ the opacity to 100%. If user says no, we can ‘fade out’ the opacity, as if the add-on is also visually removed.
What do you think?
Regardless of what we show before the install, we will need a way to manage permissions. What happen if you go to about:addons and click on the “Permissions” button? An idea I had was to use the modal dialogue that Firefox already uses in about:preferences, like so:
The wording shown here isn’t final, but it should nevertheless give you an idea of what this permissions management UI could look like.
This green, yellow, red color coding is bullshit
@askmatey Please keep your comments constructive, there's no need for that kind of language.
@askmatey I am not sure color coding is the right way either. I would love to hear your reasons why it isn't.
I think Android and iOS perfectly illustrate the problems around permissions that we need to solve:
Android used to show all permissions upfront (like Chrome), but like TOS or EULAs most people won't read them because they are eager to try the thing, because it is too much info with too little context, and because it might be confusing what it means.
iOS on the other hand did drastically reduce the number of permissions users see and only shows them in context. With that system the user gets to try the thing, and the developer has a chance to explain why they need a permission before they ask the user.
By now Android (6.0) also moved to an iOS style permission system.
Fewer permissions shown to users in context keeps them relevant and understandable. Maybe we too need to cover all cases internally that can not be explained to users in context.
For that we need to review all permissions, see which ones are necessary for the user to decide on, which can be understood, and which can be shown in context. And then figure out how to deal with the remaining permissions.
On Jul 7, 2016 04:22, "Markus Jaritz" notifications@github.com wrote:
@askmatey I am not sure color coding is the right way either. I would
love to hear your reasons why it isn't.
One hurdle to overcome: color coding isn't especially accessible for folks
with color vision deficiencies.
Besides WebExtensions, permissions are also discussed in the context of websites. Which have some similar permissions (Location, Camera, Microphone). And also discuss similar problems of how to best serve permissions in context for users to understand.
I had a chat with @ashgrigas about that and she shared their prototype:
https://mozilla.invisionapp.com/share/9J7RMC2G7#/screens/170569580
They default to temporarily granting permissions with an option for the users to make it permanent.
Unless a permission is so visible to the user that they have an easy way to undo. Like notifications.
Can we use the same system for all permissions, Websites and WebExtensions?
They default to temporarily granting permissions with an option for the users to make it permanent.
This behaviour is great for non-essential permissions.
For example, if an add-on wants to change your wallpaper, we can say “Would you like to allow [Add-on name] to change your desktop wallpaper? [Allow] [Don’t allow] [x] Remember my decision”
But if an add-on requires a permission in order to function correctly (maybe an ad blocker needs the ability to modify your privacy settings), then it would be smart to ask before the add-on is installed. Otherwise, the add-on will be installed and we immediately need to ask users “Would you like to allow [Add-on name] to change your privacy settings?”. If you say “Don’t allow”, that add-on cannot function.
For non-essential but critical permissions, the in-context system could look like this. Using the same style as used for websites permissions.
There are different ways, on where the panel is attached to. I would expect that this information is attached to the add-on's toolbar-icon if one is existing. If there is no toolbar-icon displayed, we can display the icon for as long as the panel is opened, or simply attach it to the menu icon.
It might make for a more consistent experience to always have it attached
to the menu icon if its likely some won't have menu bar icons.
If a user doesn't click Remember my decision when are they asked again?
Aislinn
On Sun, Jul 24, 2016 at 4:45 AM, maxpopp notifications@github.com wrote:
For non-essential but critical permissions, the in-context system could
look like this. Using the same style as used for websites permissions.[image: permission-panel]
https://cloud.githubusercontent.com/assets/17761517/17082726/795abcbc-5188-11e6-9002-d5606362f14a.pngThere are different ways, on where the panel is attached to. I would
expect that this information is attached to the add-on's toolbar-icon if
one is existing. If there is no toolbar-icon displayed, we can display the
icon for as long as the panel is opened, or simply attach it to the menu
icon.[image: attach-permission]
https://cloud.githubusercontent.com/assets/17761517/17082826/6f048f92-518b-11e6-884d-b2ce1cf930f3.png—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#51 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AI_-mFSyumiZWzGdRCiJyeIjKYcbhrboks5qYyYbgaJpZM4HtIWN
.
Aislinn Dewey Grigas
User Experience Design Consultant
www.aislinndewey.com
978.930.3729
http://www.linkedin.com/in/aislinn http://www.twitter.com/ashdewey
http://www.facebook.com/ashdewey
I totally agree on this one. Makes it a lot more consistent, since not every Addon has an icon in the toolbar.
The message would appear in context. So whenever the Addon uses this permissions (for example: track geolocation) it would ask to do so.
Yeah makes sense - I guess I mean if a user doesn't check remember my
decision, how long does the permission get allowed/blocked? Until they
reset the browser? close that tab? refresh the page?
On Wed, Jul 27, 2016 at 9:46 AM, maxpopp notifications@github.com wrote:
I totally agree on this one. Makes it a lot more consistent, since not
every Addon has an icon in the toolbar.
[image: attachment]
https://cloud.githubusercontent.com/assets/17761517/17177299/0293d466-5411-11e6-95d2-a562ef20c2b4.pngThe message would appear in context. So whenever the Addon uses this
permissions (for example: track geolocation) it would ask to do so.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#51 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AI_-mPgQQ2Nt3r1StereMX9UYYcKsbR5ks5qZ2FCgaJpZM4HtIWN
.
Aislinn Dewey Grigas
User Experience Design Consultant
www.aislinndewey.com
978.930.3729
http://www.linkedin.com/in/aislinn http://www.twitter.com/ashdewey
http://www.facebook.com/ashdewey
I wonder if temporary permissions is manageable for WebExtensions. For access to my camera it might make sens to control it, but what with history or others where the add-on might require permanent access. Would it then ask on every start-up? That might soon get annoying.
And what would happen if a user doesn't want to give a certain permission permanently? With web-sites that is pretty easy. The users would be surprised by a permission request, wouldn't give that permission, and close the tab. (To maybe never come back again.)
But with a WebExtension there is no close button. The user would have to remove the add-on. But there is no one-click way. Should we maybe offer to remove the add-on as an option in the permission panel? At least if the dev specified that permission as needed? I mean the add-on will not be functioning at that point anyway.
Max, you mentioned, the icon could temporary show up when the permission is asked. That might be interesting to indicate activity of otherwise invisible extensions if not only visible when first accessing something, but any time they access something behind a permission. (Might be another issue though.)
If the user doesn't click "remember" he would be asked again if he resets the browser(since this is not tab or window related) and the permissions is needed again.
The in context system is only meant to be for these 5 permissions, as described above.
So only geolocation, management, printerProvider, desktopCapture and privacy. I am working on a permissions panel, with a disable/remove addon option.
Permissions Panel
We will also need a way to manage different permissions of every single Addon. I did a quick rework suggestion for bram's visual of the permissions panel, which I like very much. I reduced the number of categories to Optional Permissions and Essential Permissions. I also included a way to quickly disable the Addon if the user doesn't like the Essential Permissions to run. I think providing a way to quickly perform instead of only leading to, what the user has to do if he wants to disable essential Addons will be much quicker.
I like the two categories - wondering if the essential ones should be at
the top of the overlay and the optional ones at the bottom since I think
most of the time options settings/prefs are usually buried and
de-emphasized.
I wonder also if these should be duplicated into our upcoming re-design of
about:permissions which will become a more global place to view all
permissions grant across sites and I'm guessing add-ons so that users don't
have to look in multiple prefs tabs to understand what they've granted
across a single category like 'web history' or 'geolocation.'
A
On Thu, Aug 18, 2016 at 8:50 AM, Markus Jaritz notifications@github.com
wrote:
Feedback from User Research on Disco Pane that might apply to our work on
Install Confirmation :
- Create more consistent confirmation messaging after add-on
activation and de-activation- Help users manage add-ons once activated, including clarifying where
users should go to activate/deactivate add-ons and helping users get rid of
unhelpful add-ons—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#51 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AI_-mGg3-_Jnah_kmtPrtry8Wkx1bbu5ks5qhFUbgaJpZM4HtIWN
.
Aislinn Dewey Grigas
User Experience Design Consultant
www.aislinndewey.com
978.930.3729
http://www.linkedin.com/in/aislinn http://www.twitter.com/ashdewey
http://www.facebook.com/ashdewey
It would be great to have a central point showing all permissions granted to websites and add-ons. @ashgrigas you mentioned about:premissions , I couldn't find that in current nightly. Please update us if you know more about that.
I just checked with the team and it was removed in 45 so I guess I can't
show you what it looked like. It was essentially a global permissions
manager and our goal is to move that into prefs.
On Mon, Aug 22, 2016 at 10:01 AM, Markus Jaritz notifications@github.com
wrote:
It would be great to have a central point showing all permissions granted
to websites and add-ons. You mentioned about:premissions but I couldn't
find that in current nightly. Please update us if you know more about that.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#51 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AI_-mKlnkVULncIm8WV0JEidJmq2YELnks5qiavHgaJpZM4HtIWN
.
Aislinn Dewey Grigas
User Experience Design Consultant
www.aislinndewey.com
978.930.3729
http://www.linkedin.com/in/aislinn http://www.twitter.com/ashdewey
http://www.facebook.com/ashdewey
We made a lot of progress on this.
UI-Flows for first phase of implementation here:
https://www.figma.com/file/HrLiKUwoLQZsIUIVBKM8Wnnu/Install-Flow-showing-Permissions?node-id=321%3A78
Future work will be broken down into individual bug:
- Optional Permissions
- Permissions Management (surfacing permissions in Firefox after install, revoke optional permissions)
- surfacing permissions on android
other install-related work:
- unify/improve install confirmation / uninstall confirmation
- simplify install flow (have all interaction before download)
It might make for a more consistent experience to always have it attached
to the menu icon if its likely some won't have menu bar icons.
What about for users who have used Classic Theme Restorer to switch to a more traditional-style menu with keyboard shortcut hints (like Chrome still uses) rather than the Australis "word-wrapped toolbar in a panel" design?
(I ask because I have the older "firefox button in the top-left corner" menu design and, ever since the aggressive deprecation plan for XUL addons was announced, I've been collecting data points to decide when to start riding down from Aurora through to ESR and, when that is no longer viable, which alternative browser to use.)
The implementation of it's now in the product!
As designakt mentioned before, optional Permissions and permissions management we'll cover in others bugs. The Fennec team is currently caring of displaying permissions on Android.