1270600 - Chrome Parity: Allow setting newly non-default permissions in site identity panel

Status: RESOLVED WONTFIX

(Firefox :: Settings UI, defect)

Description

[Stephan Sokolow]

In Chrome, granting permissions exceptions without add-ons is easy:

1. Click the site identity block
2. Click the relevant dropdown within a list of only permissions relevant to the site
3. Click a new value ("Use default" will be assumed if your choice matches the default)
4. Click outside the panel to dismiss it

Just click the site identity block and you'll be given a list of all permissions that apply to the site.

In Firefox, because the site identity block's panel only shows permissions with non-default values, the following much more awkward workflow is required:

1. Right-click
2. Choose "View Page Info"
3. Wait 2 or 3 seconds for a new window to appear rather than 0.5 to 1 second for the panel.
4. Click "Permissions"
5. Scroll through many permissions that may or may not apply to this particular site to find the one you want to change
6. Uncheck "Use Default"
7. Click the radio button for the permission you want
8. Habitually click the button in the bottom-right corner of a dialog-like box
9. Curse loudly at accidentally triggering Firefox help AGAIN
10. Close the newly opened tab
11. Click the titlebar close button on the Page Info window

I've actually advised people to install the Self-Destructing Cookies addon, not because they need it, but because its toolbar button provides a more accessible way to manipulate functionality already in Firefox.

Comment 1

[Matthew N. [:MattN]]

(In reply to Stephan Sokolow from comment #0)
> 2. Click the relevant dropdown within a list of only permissions relevant to
> …
> Just click the site identity block and you'll be given a list of all
> permissions that apply to the site.
> …
> 5. Scroll through many permissions that may or may not apply to this
> particular site to find the one you want to change

The browser alone can't know in advance what permissions may be relevant to the site. One page on the site may use geolocation to get directions to the business but if the user hasn't visited that site before the browser won't know that. You could remember what permissions an origin has used so show ones that have been relevant for the site or build a database on the server side I guess. The former doesn't address your problem if the site hasn't requested that permission for that user yet. The latter is a potential privacy issue and a lot more work. How do you or Chrome define what's relevant?

> In Firefox, because the site identity block's panel only shows permissions
> with non-default values, the following much more awkward workflow is
> required:

UX confirmed recently that we only want to show non-default permissions. At one point I suggested moving the about:permissions Permissions tab to the control center subview but UX decided against it. 

> 1. Right-click
> 2. Choose "View Page Info"
> 3. Wait 2 or 3 seconds for a new window to appear rather than 0.5 to 1
> second for the panel.
> 4. Click "Permissions"

Comment 2

[Stephan Sokolow]

True, but it's "good enough for most cases" and that makes a big difference.

Also, that reminded me. Should I file another bug over the fact that Chrome's site identity panel has a "Site Settings" link at the bottom which does an end-run around some of the complexity in my Firefox example? (By doing the equivalent of opening the Page Info window straight into the Preferences pane)

Comment 3

[Justin Dolske [:Dolske]]

One of the major criticism's of Chrome approach is that it's most often just a flood of options that are not relevant to the page or user's task (classic example of Hick's Law). It also makes it much harder to see what's _different_ about the current page.

I think our Page Info permission UI could be improved to help the workflow you describe, but not by adding a bunch of default permissions to the panel.

A bug on doing something to better connect the panel to broader permission management might be fair; I'm not sure what UX's ultimate thinking about that is. Linking it up to Page Info -> Permissions would be easy, but it's also a bit gross (as I noted) so I'm not sure if that's great to do. And, ultimately this is asking for the ability to set non-default permissions for a specific site before it's been requested, and I'm not sure that's a very interesting use-case to support.

Comment 4

[Justin Dolske [:Dolske]]

(In reply to Stephan Sokolow from comment #0)

> I've actually advised people to install the Self-Destructing Cookies addon,
> not because they need it, but because its toolbar button provides a more
> accessible way to manipulate functionality already in Firefox.

(This is exactly why add-ons exist -- niche features that a subset of users are specifically interested in.)

Comment 5

[Stephan Sokolow]

(In reply to Justin Dolske [:Dolske] from comment #3)
> One of the major criticism's of Chrome approach is that it's most often just
> a flood of options that are not relevant to the page or user's task (classic
> example of Hick's Law). It also makes it much harder to see what's
> _different_ about the current page.
> 
> I think our Page Info permission UI could be improved to help the workflow
> you describe, but not by adding a bunch of default permissions to the panel.
> 
> A bug on doing something to better connect the panel to broader permission
> management might be fair; I'm not sure what UX's ultimate thinking about
> that is. Linking it up to Page Info -> Permissions would be easy, but it's
> also a bit gross (as I noted) so I'm not sure if that's great to do. And,
> ultimately this is asking for the ability to set non-default permissions for
> a specific site before it's been requested, and I'm not sure that's a very
> interesting use-case to support.

Actually, I was referring to use cases like these:

1. The site specified JavaScript to be loaded, so we know that permission is relevant. Include a permission for that in the site identity panel which will take effect after page reload.

2. At the moment the user clicks the site identity block, the site has cookies, so we know that permission is relevant. Include a permission for that in the site identity panel which can retroactively opt cookies in/out of "delete on end of session" without a page reload.

3. etc.

The key point being that it displays only permissions that are known to be relevant, so that users don't have to scroll through the entire permissions list in the Page Info window.

Comment 6

[Stephan Sokolow]

(In reply to Justin Dolske [:Dolske] from comment #4)
> (In reply to Stephan Sokolow from comment #0)
> 
> > I've actually advised people to install the Self-Destructing Cookies addon,
> > not because they need it, but because its toolbar button provides a more
> > accessible way to manipulate functionality already in Firefox.
> 
> (This is exactly why add-ons exist -- niche features that a subset of users
> are specifically interested in.)

Yes, but the question is where the line is drawn.

Given how much awareness of things like clearing cookies to protect privacy has spread outside technical circles, I could use the same line of reasoning to argue that the base Firefox install should be more like chrome-less browsers like Luakit or Jumanji with the browser chrome being an add-on since so many people disagree on what it should look like.

This is a built-in Firefox feature that is crippled by a UI dating back to the era when manually approving or denying individual cookies was still a feasible course of action.