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
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
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.
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.
(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.
Attachment #8686475 - Flags: review?(MattN+bmo) → review+
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?
Typing about:permissions in the location bar and hitting enter does nothing instead of redirecting to the "address not found" page.
Attachment #8687943 - Flags: review?(MattN+bmo) → review+
(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.)
(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  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.  http://arstechnica.com/tech-policy/2015/11/beware-of-ads-that-use-inaudible-sound-to-link-your-phone-tv-tablet-and-pc/
Somebody can revive Kairo's Tahoe Data Manager (source: https://hg.mozilla.org/users/kairo_kairo.at/dataman/ ) or make something similar if they want a replacement.  https://home.kairo.at/?d=w&i=1&m=v&f.tags=Data+Manager
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
QA Whiteboard: [bugday-20160120]
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!
Status: RESOLVED → VERIFIED
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.
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.
You need to log in before you can comment on or make changes to this bug.