User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-GB; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-GB; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6 The list of blocked/allowed/per-session domains for cookies displays most of the domains visited, including details of which ones are actively used (cookies permitted to store a login ID across multiple sessions) Instead of using the domain name as the key, it might be possible to use the hash of the domain name. The list would not then be browsable, but you could type a domain name to see or alter its settings. More usefully, there could be a control to display settings for the domain of the current page, for use when a login fails and you want to allow cookies for the page currently being viewed. Reproducible: Always Steps to Reproduce: 1. visit website with 'prompt for cookies' enabled 2. preferences -> privacy -> cookie exceptions Actual Results: Displays a plaintext list of domains visited Expected Results: Would be nice to show just settings for the current page's domain, with the option of typing a domain name to see its settings.

this doesn't sound like a problem to me under normal browsing circumstances - there are plenty of other ways to get information about site visited (history being the most obvious). we're not currently doing anything here with regard to privatebrowsing though, and perhaps we should - for instance, with "clear recent history" (bug 463607). for the permission manager, this would require saving timestamps with the entries, i.e. a db schema change. ehsan, any thoughts here?

history disappears after a couple of days or when you close the browser, whereas the list of sites you trust with cookies from again should stay around for a long time

Saving timestamps with the entries might be useful - if you've accidentally blocked a site that you're trying to login to, you might want to delete any entries made recently (almost like an 'undo' function for cookie blocking)

Originally in bug 248970, I had a patch to handle the permissions manager inside the private browsing mode. IIRC the patch disabled storing anything in the on-disk DB during the private mode, but it handled saving them in memory, so that the permission manager continues to work inside the private browsing mode. mconnor however suggested that we disable the UI instead. I still think a back-end change is more appropriate. mconnor: do you still think the same thing about this?

My opinion hasn't changed. Once we are able to go with per-window states, such a change would have to be undone anyway. You can only add cookie exceptions in the prefwindow by default, and everything else you can change there is retained. As for this bug, well, we've made the decision in the past that ability to edit those settings is more important than the potential data leak. There's ways around this, but it's a little tricky and needs some obvious UI that may not be desirable.

I realised as soon as I had posted this bug that the required UI would be horrible. How can you manage trust for cookies if you can't read the list? It would lead to people deleting the whole trust list to get some login to work properly. However I can suggest something (not sure how this overlaps with Mike's per-window stuff) similar to how popup windows are currently handled: -+-------------------------------------------+---------- | The last action tried to set 3 cookie(s) | | www.a.sample.com blocked [unblock] | | www.a.sample.com blocked [unblock] | | www.b.sample.com per-session [unblock] | | [unblock all] | +-------------------------------------------+ So when you load a new page, it tells you all the cookie transactions that were accepted or rejected by your trust rules, and gives you the option of deleting s710.whatever.login.yahoo.com from the list without having to go search for it in the preferences menu. The advantage over displaying the full list, is that (a) it only shows entries relevant to your current activity, so less searching for weird subdomains and 3rd party sites, and (b) it doesn't reveal your entire list of which sites to trust to anyone using your PC

Storing hashes would actually hurt your privacy. Currently, you can remove items you don't want other people to find out about. If we stored hashes, you wouldn't be able to do that easily, but an attacker still could by running your hashes against a list of the 10 million most popular web sites.

(In reply to comment #5) > You can only add cookie exceptions in the prefwindow by default, and > everything else you can change there is retained. But it's not just cookies, the permission manager is generic functionality used for other settings by Firefox itself and by several addons. We can of course handle all the built-in uses individually if we want to go that route, but we can't count on all the addons doing this right. Wouldn't it make more sense to build this into the permission manager generically?

Yes, the same logic applies. Ultimately, we want to have private windows, not app-wide settings, and it makes even less sense to disable making permanent changes in the prefwindow. As for the rest, Jesse's argument seems pretty sane to me.

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258