3.33 KB, text/plain
3.12 KB, text/plain
1.98 KB, text/plain
12.08 KB, application/vnd.mozilla.xul+xml
13.22 KB, image/gif
30.19 KB, image/png
36.58 KB, image/gif
2.29 KB, image/gif
9.95 KB, image/gif
if there's a tracking bug on this already, feel free to dup. basically, in the browser Preferences dialog, the features in the Security Panel aren't functional, afaik: * Policies scrolling list does nothing * Add Site... button does nothing * Policy Description: Settings for button does nothing
not sure if the work for this is due for nsbeta2... expected miletstone?
I don't think this is intended for Beta2...but correct me if I'm wrong. Marking M20 and reassigning to Steve Morse, who's workin on security UI.
I'm not doing any UI for this. Ben is in charge of pref UI.
Putting on [nsbeta2-] radar. Not critical to beta2.
UI needs layout cleanup, things are jumbled up right now.
*** Bug 44037 has been marked as a duplicate of this bug. ***
morse -- ben did the UI for this, right? just need the backend now?
As I commented above, I had nothing to do with either the front end or the back end of the security pref panel. This bug already came to me and I reassigned to ben since he did the front end. And the bug seems to talk about front-end work since it mentions "layout cleanup" and "things are jumbled up right now". So I'm giving it back to ben.
If I'm wrong and this bug is about the back-end work, then it should go to one of the security people, possibly thayes.
sorry morse. I got confused by your earlier comment and thought you were going to do the backend once ben finished the UI. reassigning to security, afaik the UI for this is done (but reassign back to ben if I'm wrong)
h'm, was under the impression that ben was doing the backend work on this... ben?
ack! this is mine. All the back end stuff is in place, and has been in place since the completion of bug 858. All this requires is me to do this panel. Setting QA contact back to se too.
nsbeta2+ bug 44121 asks for the removal of this unfinished panel, but from ben's comments it doesn't seem like a lot of work is involved here (or am I getting the wrong impression?) Re-requesting nsbeta2+ status in the hopes that we can close 44121...if it's easy enough, we might as well fix it for beta2 instead of hide it.
Putting on [nsbeta2-] radar. Not critical to beta2. We decided to cut the panel from the product (according to bug 44121).
er...not cut the panel from the product for good, just for beta2... well, it seems kind of silly to me...44121 asked to cut it for beta2 since it wasn't functioning yet, but since the backend is in it seems like it'd be easy to get it working. thus we'd be cutting functionality from beta2 for no apparent reason. Whatever, I won't mess with the mysterious innerworkings of the PDT.
Nav triage team: Bug 44121 states that this panel should be taken out of beta2 but not out of the product. Minor work remains to finalize this.
adding nsbeta3 keyword.
*** Bug 43712 has been marked as a duplicate of this bug. ***
nav triage team: [b3nav+] now = [nsbeta3+]
don't think i'll get to this (afaik, as of now), so over to paw to decide which qa engr to pound on this feature...
As much as I'd love a UI for this cool feature, I don't have time right now. Will implement as a drop in component later or integrate into a future relase. Future. clearing nsbeta3+
OK, I talked to ben, and agreed to give this a shot. No promises, but it's better than lying around futured.
John could you look at this when it's fixed. Thanks Changing QA Contact to email@example.com
*** Bug 27012 has been marked as a duplicate of this bug. ***
What features will the Security Policies panel have?
lord, is this for you'all to outline?
Please just cc someone to ask them a question, rather than reassigning the bug...thanks. Matt, iirc, you removed this pref panel for beta2. Could you please add it back in, so everyone knows what it looks like, and it's functionality? I don't see a problem with having a nonfunctional panel in the nightlies right now. If need be, we can remove it again for a milestone.
Bug 50172 has been reported to cover the missing security panel issue. There's also a screenshot (http://mozilla.org/quality/browser/front- end/testplans/browser-prefs/img/security.gif) of what the panel looked like.
Marking invalid, based upon bug 50172 being invalid.
reopening as an enhancement request per conversation i had with mstolz re: bug 60323 and bug 7380. blake feel free to bop this to someone else/nobody if your schedule has no room for this in the forseeable future. :)
doing that :)
*** Bug 46602 has been marked as a duplicate of this bug. ***
*** Bug 63287 has been marked as a duplicate of this bug. ***
reassigning back to me. Matt, if you disagree and really want to do this, feel free to take it back, otherwise, I have some ideas and would like to give this a shot sometime soon.
The main problem with having a separate panel is that it would be forwards-incompatible with the UI for bug 7380. For specific zones I should be able to control all display-related prefs -- not just JS calls, but also colors, fonts, style sheets, whatever. And the more prefs were covered by zones, the more duplication of UI you would have -- the UI for prefs in `Normal' (i.e. where no other zone applies), and the UI for the same prefs in a particular zone. I think the best way to handle this is to have a popup menu and buttons at the top of the prefs dialog for managing zones, like the popup menu and buttons at the top of Mac OS's Internet control panel for managing Sets. Then all prefs configured below the popup menu are obviously meant to apply to the selected zone, and you can quickly flick between zones to see how their settings differ. The only awkward part of this is that the `Navigator' category of prefs would be under the popup menu but not controlled by the zones; the best way I can think of to deal with this is to disable the whole of the `Navigator' category when a zone other than `Normal' is selected. Currently only a few prefs can be handled on a zone-by-zone basis, but the rest could be disabled (and shown with their `Normal' zone values), or even hidden, until zone coverage for them is implemented. I'm about to attach mockups showing the Navigator prefs dialog in two different states.
Ben, Good ideas - basically what I had in mind. This may be a longer-term idea, but it might be cool to combine cookie management, image blocking, JS security, and (coming soon) P3P preferences into a "zone prefs" dialog. There isn't any scriptable access to prefs enumerators yet, but I'm going to add some scriptable APIs to caps that will give you all the info you need for the UI.
mpt: I agree. It would be great to have all "zoned" prefs in the same place. Unlike IE, users should be able to define any number of zones, and we should have some good defaults in place, as Ben suggests (default, "annoying sites," trusted sites...)
Created attachment 23677 [details] A much less horribly-modal (and more space-conserving) design than my previous attempt
Normal settings Trusted zone ::Too:garish::,::: Yucky sites |\ ---------------\-- New Zone ... Delete "Yuck..." Duplicate "Y..." Get rid of delete and duplicate. If you're going to put them somewhere we'll have to use a listview/treeview control like windows printers/objects which is probably a better idea. New is ok in either a listbox or a listview, but Delete and Duplicate do not belong in a listview, they are inconsistent with the context. 'Scripts Delete X' doesn't need all of the children like _Enable scripts. Nor does Scripts Duplicate X. Ben: is there a xul bug for an object that supports multiple views (esp List, Large Icons, Details)
> Get rid of delete and duplicate. That was a mistake ... What I drew What it should be ----------- ----------------- New Zone ... Delete "Yuck..." Delete "Yuck..." Duplicate "Y..." Duplicate "Y..." Zone Coverage... I know it's bad to include command items in a menu which is mainly for mutually exclusive options, but I judged it was far better to do that than to spend screen real estate (which we don't have enough of in the prefs dialog as it is) on separate controls for something which only a small minority of users will ever want to use.
*** Bug 45083 has been marked as a duplicate of this bug. ***
*** Bug 75371 has been marked as a duplicate of this bug. ***
well, a Privacy & Security category now exists in the prefs. i'm tempted to remove the rfe severity, too... when could we move other security-related items underneath it, like Cookies, Forms, Passwords...? i understand that those aren't psm components, but from an enduser perspective they still deal with security/privacy issues and should be grouped as such. it'd also reduce the clutter under the Advanced category. just my $0.02.
I agree. Forms & cookies should go under the Privacy and Security category. End users consider those part of privacy; they don't distinguish PSM from cookie management, nor do they need to.
*** Bug 76058 has been marked as a duplicate of this bug. ***
clearing minus for nsbeta1 reconsideration --now that there is a Privacy and Security panel in the preferences dialog.
hokay, i was recently reminded of bug 43501 --which would cover the aspect of moving the Cookies, Images, Forms and Passwords categories under Privacy and Secuirty. almost missed that one...
Blake - do you want to take this? Ben's plate for mozilla0.9.1 and mozilla0.9.2 is already pretty full. This is a nice to have but we have to mark it nsCatFood- and nsbeta1+ but only a P5.
*** Bug 79773 has been marked as a duplicate of this bug. ***
I have created bug 80336 that will hopefully get *popup windows* fixed. This bug is for everyone tired of *popup windows* not being dealt with (closed bugs that aren't fixed - bug 29346; being moved to general bugs <this one, bug 38966> that don't deal with the problem specifically).
Okay, I'll take this.
This morning's builds had a bug ( bug 80746 ) which may have led to a Bugzilla user inadvertantly changing this bug from the Assignbed/Accepted status to the New status. If you are the owner of this bug please check to see that it is in the correct Status. Thanks.
*** Bug 80754 has been marked as a duplicate of this bug. ***
I'mnot sure if this is the right place to report, but the "Privacy and Security" prefs panel is the only of the pref panels where the "root panel" has no content. This looks rather stupid. Maybe at least a little informational text could be moved there.
We are working on putting something there... maybe a "reset all prefs" button, maybe a summary of privacy/security settings, maybe a button to open up "About Security" help window.
don't you have a UI designer behind this? CC'ing german for some input - this is starting to look like the old 4.x "security stuff looks different than everything else" disease
i filed bug 81526 for the empty P&S toplevel panel. let's continue discussion there. thx!
This looks like the best candidate for the UI for Bug 7380, unless somebody knows a better one...
*** Bug 100127 has been marked as a duplicate of this bug. ***
Pref loading and saving should be OK as long as this panel is being called from the preferences panel.
Hmm. I inserted your pref-policies.xul into my comm.jar file at /content/communicator/pref and I edited my /content/communicator/pref/preftree.xul file so that the policies panel appears under the "advanced" branch of my prefs screen. When I go into prefs, I can see the policy panel, and I can add and change policies, and the zones that I had already created by manually editing my prefs.js file in the past show up, but the changes/additions/removals I make go away when i close the prefs panel.
How about, say, capability.policy.mailnews.Window.open? And should we allow capability.policy.mailnews.sites to be edited?
> How about, say, capability.policy.mailnews.Window.open? Yes, changing that requires a restart at this point. Changing 'default' prefs does not. > And should we allow capability.policy.mailnews.sites to be edited? No! In fact, the user should not be able to edit any of the existing capability.policy.mailnews prefs other than to add new restrictions. That could open up a bunch of holes. This is great work, but let's take some time to evaluate the security risks of this UI before we check it in.
Created attachment 61423 [details] Revised UI (pref-policies.xul) Brings up to date with XUL changes. Prevents viewing or editing of list of site for "mailnews".
Matthew's doing the work...
*** Bug 115789 has been marked as a duplicate of this bug. ***
There is an installable XPI and screenshots of the current version at http://security.mozdev.org. Feedback needed - on the UI, and on what preferences should be exposed.
I just download and install your XPI. There a list various feature I think could be interesting. I think the setting maybe ok for a begginner, but there is no expert mode. What I would like would be the ability to change member of the policy, just like in the text file (http://www.mozilla.org/projects/security/components/ConfigPolicy.html). That maybe provide with a expert mode when I have to type the name of the properties directly. Regarding the information I would like in the basic dialog, I think it would be a good think to be able to disable SSL warning for trusted site. Maybe we could merge all the subsection of the Privacy and Security that retains site list with your dialog (cookies, images, form, password...), so people could simply move site to a trusted or untrusted domain instead of saying each time, I accept images, I accept cookies... Also, I would like to be able to create a domain by cloning any existing domain. (That means the create domain dialog should take two parameters, the base domain and the domain name). After it's creation the new domain would be unrelated to the base domain, it's just in the case we have a lot of properties sets and we just want to change one for some sites.
>Regarding the information I would like in the basic dialog, I think it would be >a good think to be able to disable SSL warning for trusted site. Unless there is an existing preference for this (does anyone know?), I think this should be raised as a new bug. This bug (as I understand it) is only for creating a UI for existing preferences.
Reagarding SSL warning, I search further to find it, but I agree that I have to open a new bug if it don't exist.
Should the list of preferences exposed here be the same as those in http://bugzilla.mozilla.org/attachment.cgi?id=62007&action=view (the bug 75371 attachment)?
Oh, I have another thought for it: Have it able to block APPLETs, or maybe even not show ANYTHING from a URL. This would block those annoying Flash ads that are cropping up. Also, look at bug 92469 for some good ideas on being able to import these settings, including the ability to use reg exps for some of the URLs. I'm not sure if regexps are wise or not (imagine the confusion of having one not working right), but it could be a step into the right direction of getting 100% of all ads and annoying pop-ups blocked (while having 100% of your content intacted). BTW, what's the ETA on getting this put into the official version?
UI Suggestions: Remove the details from the main dialog. Shouldn't the name of the policy tell the user what it is going to block? Take a look at the Message filters dialog - that one is relativly easy to use and doesn't look terribly complex. Move the details to another dialog where you would see a scrollable list of options. Similar to either Preferences->Advanced->System or the property list used in Visual Basic. An option to move a site from one policy to another would be nice. As for preferences that should be exposed... well anything which could annoy the user. Popups, moving the browser window, changing the width of the browser window, alert boxes, conformation boxes, images, cookies, plugins, applets. Thats all I can think of at the moment.
By details I mean "Open windows" and "Change status text" On the first dialog I'd just want to see the list of policies (Trusted, untrusted, etc) and what sites fall under those policies. If I want to change the settings I don't mind going in another level.
As people make requests for stuff in this panel, notice that this is _UI_ work. There are some things that the back end security policies cannot do that are pointless to ask for: 1) blocking particular events. This is bug 64737 2) an "Ask me" option for all these things. There is no back end support and the security component owner is opposed to such support. Read, e.g., bug 103405 for details (please don't comment on this issue in _this_ bug). 3) blocking applets/embeds. This is bug 66644 (or bug 19118). Adding UI for these is impossible at the moment. It would make a lot more sense, to me, to get this panel working with the options from the current "Scripts & Windows" panel first, then add more options as they become available.
Created attachment 63247 [details] Screenshot of possible UI Should this code be reworked as a patch to the existing Scripts & Windows panel? Here's a screenshot of what it might look like. (This would lose the ability to specify NoAccess/SameSite/AllAccess, reverting to a simple Yes/No choice.)
Again, I disargee with the Message Filter comparison. This is NOT a boolean matching system! If we were talking about a search engine, such as the message search, then yes, I'd compare it to the Message Filter (to some degree). Actually, I like the model he has, except for the lack of a Settings button. It's clean, already has the URLs right there to access (so you know exactly what the zone is about), and uses only that one Settings dialog box. I really don't know how your idea would look like anyway, because you are comparing apples and oranges. If you had some sort of ASCII art or a virtual screenshot, I might have a better idea.
In my opinion it would make more sense to upgrade the current Scripts&Windows panel to a three-choice menu from its current checkboxes...
M. Wilson: (comment #95) > Should this code be reworked as a patch to the existing Scripts & Windows > panel? Here's a screenshot of what it might look like. Well, I liked your older idea better, again, with the URL on front. Makes the zone more identifible, rather than some arcane-looking JS options. Boris: (comment #97) > In my opinion it would make more sense to upgrade the current Scripts&Windows > panel to a three-choice menu from its current checkboxes... Well, we don't have the back-end for an "Prompt" selection set. This is in bug 103405. (And lemme point out that I'm very irate that it's set to WONTFIX, when this is a requested feature from a number of people.) Wait...you were the one you pointed that out. Are you talking about something else?
> Are you talking about something else? Yes, I am. The current security setup has three levels of access for objects: 1) No access allowed for untrusted content ("noAccess") 2) Access allowed for all untrusted content ("allAccess") 3) Access allowed for scripts running on the same "domain" as the page in which the object lives. ("sameOrigin"). The default for most things is "sameOrigin". The UI at http://security.mozdev.org allows one to choose among the three levels, whereas the screenshot in attachment 63247 [details] (as Matthew Wilson points out) only allows one to choose between "noAccess" and "default" (whether the default is "sameOrigin" or "allAccess" depends on the object in question).
OK. You're right. Another idea: We take the old version with the URL on front and customize zones with some kind of customize button. I'll create an atachment with some idea for this.
I still don't like this more/fewer idea with the options. It's already a nightmarish mess on the Message Filter, but it's a necessary evil because there's a potential of a infinate number of options to put in. For a static number of options, you use a static system. What if somebody put in two of the same option? Do you follow the first or the second option? Do you put up an error message? Do you take away options when they are used? Is this confusing? Yes! Besides, I'd rather have the default options available there in plain view, rather than have to guess on whather it's going to work or not. You're basically putting in your run-of-the-mill selection options on an overly-complex system. The security panel is complex enough for your average Joe User. Again, IE's version of this panel is just fine, though I'd prefer drop-down boxes to a grouping of radio buttons. (I fine radio buttons to be mostly useless.)
Created attachment 63268 [details] How Visual Basic does it Take a look at how visual basic does it. It's a list, with dropdown menus in the list. It would also make it shorter than having a bunch of radio boxes like IE.
Boris: >In my opinion it would make more sense to upgrade the current > Scripts&Windows panel to a three-choice menu from its current checkboxes... I think the problem is providing a (relatively) easy UI for people without advanced requirements - i.e. people who don't care about multiple zones. I think that the 3-choice menu would be a significantly more complicated UI, because you have to work out the meaning of 3 complicated phrases before deciding which option you want. Under the current UI it's just on/off.
Yes, but the VB is a list of variables for a bunch of programmers. We are going to be dealing with average Joe User, who needs a bit more descriptive info on what the option does (like "Change Status Text", not "ChgStatusText"), and the grid system would look kinda ugly like that. Just have the same system without the gridlines and it'll look good. And definately make a dialog box for it. Not only would the amount of options not fit the vertical, but the descr + drop-down won't fit the horizonal of that small general Preferences box, either. As it is, IE has this -ugly- horizonal scrollbar (on the Custom Level box), which we should NOT copy!
Matthew, point taken. A simple yes/no toggle is what most users care about. The few who want to make things allAccess can use a sidebar panel or some such that is not a default part of the browser UI. So yes, modeling things on the current "Scripts&Windows" dialog makes sense.
> Yes, but the VB is a list of variables for a bunch of programmers. Yes, I know that, I was just pointing out how it was done. Have a list with selectable dropdown boxes. You can also see the same thing in the message compose dialog in mozilla. Select To: Bcc: or cc: and then the email address. Just flip that around, so you see the preference to block, and you get a dropdown to select Allow/Deny Does modern use the horizontal/vertical lines in the message compose dialog box? Classic has a light blue coloured grid which looks fine.
> Can you allow popups on load and unload but not allow all other popups? Not with the current back end.
Hm. And maybe instead of just put the zones name above you could use a drop-down box instead. So one can easily configure multiple zones without having to do some "OK -> choose zone -> Edit" procedure every time.
> I'd rather see an "Enable advanced options" checkbox. You mean <disclosure /> widget right? (Once that works)
> You mean <disclosure /> widget right? (Once that works) Say again? Sorry, not versed in X programming.
<disclosure />, once it exists, will give a way to click a button and have new content that was hidden before appear. Similar to "Advanced" toggles on many dialogs in Windows, eg.
Yes, that is exactly what I mean (just lack the correct vocabulary to express :) Since I'm "spamming" anyway, I'd like to comment a bit on the latest suggested config box/window ( http://bugzilla.mozilla.org/attachment.cgi?id=63290&action=view ) I think the idea behind how it's done is good, but the graphical appearance should be reworked to better fit with what is already there in Mozilla. Nowhere in the entire UI is there anything even remotely similar to such a compact "VB" layout. I suggest the graphics should drift a bit more towards how eg the messagefilters look. Ie less squareness, no horizontal lines and perhaps even some space between the buttons/selectlists.
> Nowhere in the entire UI is there anything even remotely similar to such a > compact "VB" layout. Not in the preferences but the message composer. Look at the lines where you put in To: or Cc:. This is the reversed version of the last UI suggestion. Maybe you're right and the conventions of Mozilla's _preferences_ style should be used. But there we won't find anything really useful to what is needed here (Can the Message Filters be seen as "preferences" as they are optically seperated?) I just think the actual version is very space saving if you compare it with a version containing a message filter like list. Nice that we are that far to discuss purely optical issues :)
> Can the policies stop these [disabling menubars and the like] Should be able to if you find the classnames for those objects. > navigator.userAgent Bad idea, IMO. Setting something to noAccess makes script execution completely stop when access is denied (unless the script writer uses try/catch, which is never the case). If there is a preference for disabling things like userAgent and appName on this panel, there had better be a big warning that this will break almost every dynamic site out there. We already have this problem with the window.status blocking pref... see bug 117707
BTW, this stuff ain't UI. Again, our helpful Boris has bug links on comment #93.
*** Bug 119692 has been marked as a duplicate of this bug. ***
WRT Boris's comment #126, we should have a way to suppress annoying content without throwing an exception and stopping script execution. That's the difference between security and content filtering - they're really two separate feature sets. I have filed bug 122866 on this issue.
*** Bug 125923 has been marked as a duplicate of this bug. ***
*** Bug 137377 has been marked as a duplicate of this bug. ***
Is all of the back-end in place for this? I've been waiting on this for quite a while, so it seems the only good solution is to work on it myself. Is there a place to store the prefs for this besides prefs.js? I guess that is a separate issue from this bug.
All the back end is in place for this, and the prefs go in prefs.js
Sorry, I've allowed my patch to become out of date.
*** Bug 118602 has been marked as a duplicate of this bug. ***
What about adding the mozilla1.0 and nsbeta1 keywords here ? btw, I really like http://bugzilla.mozilla.org/attachment.cgi?id=63290&action=view
*** Bug 145316 has been marked as a duplicate of this bug. ***
*** Bug 146370 has been marked as a duplicate of this bug. ***
*** Bug 149537 has been marked as a duplicate of this bug. ***
*** Bug 153301 has been marked as a duplicate of this bug. ***
I notice that bug 11707 has changed the Scripts & Windows panels to use a new set of preferences, describing the old way of doing things as "just BROKEN!" (comment 10) and meaning that we don't have a back-end any more for site-specific policies (comments 86,87).
Sorry, I meant bug 117707
*** Bug 154799 has been marked as a duplicate of this bug. ***
Looks like someone has developed an XPI for this at http://www.cc-net.or.jp/~piro/xul/_policymanager.html
*** Bug 156885 has been marked as a duplicate of this bug. ***
*** Bug 157436 has been marked as a duplicate of this bug. ***
*** Bug 150872 has been marked as a duplicate of this bug. ***
*** Bug 159925 has been marked as a duplicate of this bug. ***
Some sites use popups for advertising and on other pages, popups that can be useful (e.g. identification). So, there should be a more flexible way to block popups, in particular, capability.policy.allowpopups.sites should be extended to allow particular web pages (and not only web sites) to use popups, or any prefix of the URL for instance. AFAIK, this would be simpler than a more general blocking mechanism, thus I hope that it could be implemented earlier.
*** Bug 160647 has been marked as a duplicate of this bug. ***
Why not just a function that give you the possibility to rightclick on the pop'ed up windows and then choose "Block popups from this server". (or "Block popups with this URL", for a less general blocking).
Regarding comment 151, I would prefer to see the opposite situation. I would like to block all popups by default, but then would like to right click and choose "Allow popups from this site."
Me too. In my configuration, I block popups by default, and I don't want to change this. Methods to unblock popups should take that into account.
I also would prefer a mechanism where I block all popups and can unblock specific sites/URLs. Maybe there should also be a small icon (e.g. on the lower right of the browser) indicating when a popup is blocked. So you would be able to aware that a site doesn't work because a popup is blocked.
and clicking on the icon could unblock the popup (temporarily or permanently, perhaps depending on what button has been used).
Marking bug 150872 as blocking this bug, based on coment #6 in that report.
Matthew Wilson is gone, right? So why is this bug, the only one, still assigned to him?
Well, I'm still here, but I'm not working on this, I found a much more functional version than my patch (see comment 144)
*** Bug 192667 has been marked as a duplicate of this bug. ***
From http://www.mozilla.org/projects/security/components/ConfigPolicy.html read current way of setting policy is by as following line in prefs.js user_pref("capability.policy.policynames", "strict"); user_pref("capability.policy.strict.sites", "http://www.evil.org http://www.annoying.com"); user_pref("capability.policy.strict.Window.alert", "noAccess"); This option wont allows us to have some pages of a site to show alert and others not. If we can get a Java Script function called to determine the URLs "policy name" it will be a great help. Function should receive an argument, as pages URLs and return a string with a value as policy name.
*** Bug 207196 has been marked as a duplicate of this bug. ***
*** Bug 222678 has been marked as a duplicate of this bug. ***
*** Bug 223798 has been marked as a duplicate of this bug. ***
My thoughts on a somewhat-advanced UI and simple framework: It would be nice to have a menu system like this (a tree), all groups user-configurable (such as naming and where to place sites): +policies +-+default | +--<*> +-+annoyances | +-+<*.popup.com> | | +--<safe.popup.com> | +--<*.banner.com> +-+unsafe | +--<*.evil.com> Selecting a site or group displays that site/group's preferences in another box, containing items to block (all, specific mimetypes, cookies, js, popups, etc). The selected options can cascade down from the parent's options, just like CSS, which would be very efficient. some option examples all: block cookies: block */*: block text/*: allow image/png: allow image/jpeg: allow js: ask popups: block Sites added to certain groups will have the group's default settings automatically applied, for example, adding <*.banner.com> to annoyances will have image/* blocked by default, if the user specifies that action to be the default behavior for the annoyances zone. Wildcarding can come in handy in the mimetypes and site names. The user can set up their browser to blacklist or whitelist everything this way,as they can configure the default to block everything if they want. There could possibly be a "computed preferences" box similar to the "computed style" in the DOM inspector, so the user can see what will be blocked/allowed. Of course the "factory default" options should be well-configured so that the average user can just add a site to a group and not worry about all of the settings.
*** Bug 277160 has been marked as a duplicate of this bug. ***
*** Bug 207807 has been marked as a duplicate of this bug. ***
*** Bug 320522 has been marked as a duplicate of this bug. ***
bug 94035 expresses a similar desire for plugins. It's really the same thing probably, but I don't want to throw away the other bug's 440 votes by duping.
since there is implementation of zones (pref-policies.xul) why not review it for usability and bake it on the trunk?
*** Bug 358113 has been marked as a duplicate of this bug. ***
(Filter "spam" on 'prefs-nobody-20080612'.)
Any news about this bug?
With presence of Data Manager in current SeaMonkey versions, is this bug still actual?
Considering bug 913734 removes CAPS completely from the browser, is this still relevant? Is NoScript going to be the "go-to" extension in its stead?
Closing this meta bug as FIXED per comment #176 and comment #177 given that bug 1258295 removed the last remnants of the Security Policies preferences pane and the last comment here was 4 years ago.