933917 - Remove about:permissions from Firefox

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

2:54 PM <bsmedberg> about:permissions isn't exposed in the UI anywhere, is it?
2:56 PM <•gavin> it isn't
2:58 PM <madhava> bsmedberg: nope
2:59 PM <madhava> though... hm.
2:59 PM <madhava> now that we're looking at doing in-content prefs
3:00 PM <madhava> I wonder if there's a more sensible way to integrate it
3:03 PM <bsmedberg> madhava: I was just making sure because of a question from mkaply
3:03 PM <bsmedberg> madhava: we already expose plugin permissions in pageinfo
3:04 PM <madhava> yes - and we have plans to let users change more of their prefs from the site identity panel
3:04 PM <madhava> aka larry panel
3:04 PM <madhava> so that when you're on a particular site you can revisit decisions you've made about it
3:04 PM <madhava> it's just odd that we've had this other UI for it build and landed but unsurfaced
3:05 PM <bsmedberg> perhaps removing it is the right option
3:06 PM <shorlander> Probably considering it isn't really what we want and we don't expose it anyway
3:11 PM <jaws> yeah
3:14 PM <jaws> but should we wait until we have a better replacement before removing it?
3:15 PM <jaws> there are probably some people that depend on it, and removing it without putting in something better doesn't sound like much of a win
3:19 PM <shorlander> jaws: I don't have a strong feeling on removing or keeping it before replacing it since it is largely hidden and works AFAIK. Depends on if it is causing problems or not.
3:20 PM <jaws> it's one of those things that doesn't cause problems, and it works, but occasionally people forget to update it. for the most part it's a minor nuisance when working with the code (similar to in-content preferences right now)
3:20 PM <jaws> with the exception that we want to push forward on in-content preferences
3:22 PM <•gavin> we shouldn't hesitate to remove it if it isn't what we want

Comment 1

[Albert Scheiner [:alberts]]

bug 658618 and bug 697941 were create in order to expose about:permissions.

I just accidentally set on a page to 'never' all fullscreen for videos instead of 'always'. This setting is handled via about:permissions and it was a pain in the butt to find. If now even this UI gets removed where would this being set afterwards?

Would that be handled via 'Identity panel'? see bug 909326

Comment 2

[Ian Nartowicz]

There are definitely people who use it.  Depend on it might be too strong a word, but it fills part of a yawning gap.  My own addon would break, in a small way, if it was completely removed.

Note that a single-domain version of about:permissions appears in a tab of the page info dialog.

Comment 3

[Anne (:annevk)]

This should be WONTFIX. Having centralized permission management is absolutely critical as we move the web to an OS-like model.

I think we should strongly consider merging about:permissions into about:preferences.

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Ian Nartowicz from comment #2)
> Note that a single-domain version of about:permissions appears in a tab of
> the page info dialog.

Hidden gem, thanks! Unfortunately, it doesn't cover iframes, which means using it to e.g. control camera access for https://jsfiddle.net/srn9db4h/ doesn't work.

Comment 5

[Dão Gottwald [:dao]]

Attachment: patch

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/ec09a14e52b3

Comment 7

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/ec09a14e52b3

Comment 8

[Keul]

T______T
Now, explain me now HOW you:
- set the default permissions for all websites? (and disable sound by default like explained in bug 1193191 ?)
- see what sites don't have default permissions?

Comment 9

[u428464]

Typing about:permissions in the location bar and hitting enter does nothing instead of redirecting to the "address not found" page.

Comment 10

[Masatoshi Kimura [:emk]]

Attachment: Follow-up patch

Fix comment #9.

Comment 11

[u428464]

This bug needs to be reopened to have the follow-up patch pushed.

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/ae832b2e3196

Comment 13

[Justin Dolske [:Dolske]]

(In reply to Keul from comment #8)
> Now, explain me now HOW you:
> - set the default permissions for all websites? (and disable sound by
> default like explained in bug 1193191 ?)

Some of the permissions can still be globally disabled from about:preferences UI (like cookies and passwords). The others can all be disabled from about:config. We can consider adding UI for the ones not already exposed, although I not sure it's generally useful.

(Actually, I don't know if there are about:config entries for the camera/mic, but the about:permissions UI/code didn't actually let you globally disable those anyway. Ironically, these are the ones I'd expect to be of more privacy interest, and so it really just shows how bad about:permissions was at its job.)


> - see what sites don't have default permissions?

From https://mail.mozilla.org/pipermail/firefox-dev/2015-November/003521.html:

===
If we think there are compelling use-cases for management of specific
permissions (that are not met with existing UI, like the Control Center or
various stuff in about:preferences), we could consider adding some
per-permission UI as was done in bug 1201398. But I don't feel the general
about:permissions use-case is compelling enough that we should block
removal on a total/unified successor.
===

I'll note that this is also an example of how bad about:permissions is at its task... Cookies are allowed by default (and most users leave them so), and thus the about:permissions list quickly clutters up with every site you've visited because nearly every site sets cookies. That makes it very difficult to use about:permissions to find sites with non-default permissions.

(Not to mention that default / non-default settings are visually identical, so it's hard to click a site in about:permissions and see what's actually different. This is why newer / purposefully-designed UI only shows _changes_ from the defaults, or makes them visually distinct.)

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ae832b2e3196

Comment 15

[Bob49]

Think, before you go too fast!

It is of course not necessary that I open a new bug, because it is a mistake on your part.

And how do you refuse or set it to "always ask" geolocation for all sites, without the opportunity?
Put the possibility of choice in the privacy options. Thank you.
Choice to:
_refuse
_toujours request

Thank you on behalf of disgruntled users!

Comment 16

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Justin Dolske [:Dolske] from comment #13)
> (Actually, I don't know if there are about:config entries for the
> camera/mic, but the about:permissions UI/code didn't actually let you
> globally disable those anyway. Ironically, these are the ones I'd expect to
> be of more privacy interest, and so it really just shows how bad
> about:permissions was at its job.)

Sure, but it still gave an overview of all sites that might have been given say microphone permission, where users could, by hitting down-arrow repeatedly, at least manually audit sites where microphone had been allowed and correct each one if so desired, say, after reading some upsetting article [1] caused them to rethink their privacy stance.

Without about:permissions, the user basically has to remember every site they ever granted microphone access to, and revisit each one online and pull down the PageInfo drop-down (but see bug 1224453), a tall order for someone wanting peace-of-mind that websites are no longer be listening to them while they're browsing.

While WebRTC can be disabled entirely from about:config, this is undesirable, and has (until now) been unnecessary to solve this.

> I'll note that this is also an example of how bad about:permissions is at its task...

If my only jacket has a hole in it, then removing it still makes me colder than I was before.

[1] http://arstechnica.com/tech-policy/2015/11/beware-of-ads-that-use-inaudible-sound-to-link-your-phone-tv-tablet-and-pc/

Comment 17

[Matthew N. [:MattN]]

Somebody can revive Kairo's Tahoe Data Manager[1] (source: https://hg.mozilla.org/users/kairo_kairo.at/dataman/ ) or make something similar if they want a replacement.

[1] https://home.kairo.at/?d=w&i=1&m=v&f.tags=Data+Manager

Comment 18

[Mohammad Maruf Islam]

I have reproduced this bug with Firefox Nightly 28.0a1 (Build ID: 20131101030205) on 
windows 8.1, 64-bit.

Verified as fixed with latest Firefox Developer edition 45.0a2 (Build ID: 20160119004010)
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0

Comment 19

[Khalid Syfullah Zaman [:khalid32]]

I have reproduced this bug on Nightly 28.0a1 (2013-11-01) on ubuntu 14.04 LTS, 32 bit!

The bug's fix is now verified on Latest Firefox Developer Edition 45.0a2!

Build ID: 20160120004005
User Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0

As this bug is verified on Windows 8.1(comment 18), I am marking this as verified!

Comment 20

[Hugo Sousa]

I just found out that about:permissions was removed from Firefox. That change makes impossible to intercept HTTPS traffic for security purposes with a proxy because we can't clear the  HSTS (HTTP Strict Transport Security) cache. So my question is, after this update how do I clear the HSTS cache?

I don't understand how could the "permissions tab" be removed when there aren't alternative ways of doing the same things.

Comment 21

[Frederik Braun [:freddy]]

Bugzilla is not a discussion forum.
In the future please reach out to one of
- Mozilla Support: https://support.mozilla.org/
- the dev-security mailing list: https://lists.mozilla.org/listinfo/dev-security
- IRC at irc.mozilla.org #security

FWIW, I recommend using a separate browsing profile and intercept HTTPS by adding a marking a CA certificate as trusted that is used by your intercepting proxy. There might be additional techniques hidden in the UI to remove HSTS, but you can also remove security state manually. It is currently stored in your profile directory in the file SiteSecurityServiceState.txt.