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 junruh@netscape.com

Where is the Security Policies panel? There's a panel in the PSM dialog under Applications/Java and Javascript, but all that's there is a Reset All Privileges button, which does nothing right now. Is this all the functionality that's expected? Or am I missing something? A Reset button is probably all that's needed for this go-around, as it allows users to start from scratch if they make a security decision they want to change later. I own the backend for this functionality, so please let me know what features you're adding; I can point you at the APIs to accomplish these things.

*** 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.

Verified.

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.

So here are my UI thoughts: We allow users to create n zones for sites whose activity they wish to limit. We allow them to control access to javascript and java globally, as well as access to any of the DOM props listed in dom/public/nsDOMPropNames.h. Providing a UI to set any of the DOM properties is probably overkill, although we could offer a small but meaningful subset (popup windows, status text, etc). There would be a pref panel for this, similar I guess to IE's. The UI would probably have to offer a fixed set of zones unless there was scriptable access to prefs enumerators (there may be now, there wasn't last time I looked) but definitely there should be a few default zones that people can get started with, with default settings. The other UI I was thinking off was an addition to Navigator that placed a popup menu somewhere, perhaps in the expanse of space near the bottom right that had some items like (excuse me while I slip into my mpt clothes and produce some ascii art): +----------------- | Annoyances | Untrusted Sites | Trusted Sites | x Internet Zone +-------------------- | Create New Zone... +---------------------- | ^ Internet Zone | +-----------------+ This is a nice non-modal solution, sure the annoyance appears the first time but is henceforth quickly segregated. Setting prefs involve reloading the page, which perhaps should be automatic. I think there should probably be a confirm dialog when changing the zone of a untrusted site to that of a trusted site (not sure exactly how to measure this) to prevent accidental changes.

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.

also setting this dependent on the 'prevent annoying popups' bug 29346.

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...)

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. ***

nominating...bueller? :)

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. ***

First stab at a patch attached. It allows creating and deleting zones, enabling/disabling Javascript for each zone, and setting the Window.open and Window.status capabilities for each zone. You'll need to include a link to it in your prefs tree. Comments welcome.

Matthew, you are now officially my hero. It looks spiffy. Is "Enable Javascript" supposed to be unchecked by default?

"Enable Javascript" for a zone should be checked or unchecked depending on the value of the preference capability.policy.<zone>.javascript.enabled. (Is this right? There seems to be a javascript.enabled preference as well, currently controlled in the Advanced Preferences panel.)

There also seems to be a preference javascript.allow.mailnews. Should I use that instead of capability.policy.mailnews.javascipt.enabled?

> "Enable Javascript" for a zone should be checked or unchecked depending on the > value of the preference capability.policy.<zone>.javascript.enabled. Ah. I see. In my prefs, I do not have any capability.policy.<zone>.javascript.enabled defined at all, so it must be defaulting to unchecked. If undefined, it should resort to the value of capability.policy.default.javascript.enabled and if THAT is undefined it ought to resort to the global pref javascript.enabled ...at least thats how I think it probably ought to work without really knowing how it all works on the inside Also, I see that the changes I make on your prefs panel are not actuall saved to my prefs.js file. Is that part just not done yet, or did I install the xul file wrong?

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.

> "Enable Javascript" for a zone should be checked or unchecked depending on the > value of the preference capability.policy.<zone>.javascript.enabled. This is correct. Don't use "capability.policy.default.javascript.enabled," I'm not sure if that works. Use the global "javascript.enabled" pref instead. Also, don't use "capability.policy.mailnews.javascript.enabled" because that doesn't cover iframes in mail messages. Use "javascript.allow.mailnews" (there's already a UI for this one, under Advanced). THat one covers all content within a mail message. I'm sorry I neglected to mention this earlier, but the zone capability prefs don't have callbacks to the capabilities engine right now, which menas that you'll have to restart the browser in some cases for the zone prefs to take effect. I'm going to add callbacks soon so these prefs can be changed on the fly.

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.

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)?

> 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. Just saw the screenshot. Damn, that's complex, and IE-like, but oh well... (And to make it more complex...) I think that the two JavaScript options aren't enough. There should at least be the same options as the ones currently in the 0.9.8 version.

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.

[Brendan]> I think that the two JavaScript options aren't enough. Agreed - I expect that the options should be the same as on 0.9.7's "Scripts & Windows" panel. [Neil]> Remove the details from the main dialog. Can you be more explicit about what you mean by "details" here?

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.

Yes, similar to the "Custom Level..." button on IE in the Privacy options. Try to cram as much security options as possible in that one, again, like in IE. (After all, if you're going to have this security dialog look like IE, go all the way. And yes, I appreciate the adding of zones feature you put in this thing, which IE does -not- have.) IMO, it should have more than just the "Script & Windows" options. I like the idea of being able to block certain events, not functions. Like block all OnLoad or OnExit events, instead of blocking pop-ups. Then again, maybe not. (I'm just throwing ideas.) Also, those options should probably have a "prompt" option for each one, so that you could selectively imploy the option if it's not being naughty. Of course, with some details on what it's doing on each dialog box, similar to cookie prompts. And yes, you can't really do it with some of the more generalistic options like "Allow JavaScript", but you know what I mean. About the message filtering dialog, I don't think it would be a good idea to model after that. It's fine how it is, except the type of options should be on another button/dialog.

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.

I don't think an UI like the "Message Filters..." would be a bad idea. And this option may be as well seperated from the standard preferences. Instead of the mail addresse you configure categories like "trusted sites", "default sites", "annoying sites" including a set of URLs. Instead of message filters you configure javascript filters. And instead of "Body contains" you set up somethin like "Popup windows - Same site". As a feature for beginners there may be some predefined categories with some predefined filters (like "annoying sites" -> "popup - never, resize windows - never" .....) The advantage may be its similarity. One would see the interface an recognize "aaaah. I know this." and naturally use it as one is used to do with the message filters.

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.)

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.

I think this bug is treading on very thin ice. The subject matter is very confusing and the terms used may not be the best choices (but should be, due to the complexity of what is being attempted). Joe user must be able to understand this. I suggest to (re)consider the following: 1) "Zone" is too vague and implies a geographic/physical location. I suggest "Site-Groups Permissions" or "Site Groups" or "Javascript Permission Levels" ... 2) If all "events" pertain to javascript, then the window title should be "Javascript permission rules" (at least mention javascript). 3) There should not be two collumns of dropdown lists. Maybe there could be a fixed list of default javascript events, and then a custom list separated by a horiz line. 4) "Same site" and "No Access" mean nothing to me. Maybe it should be worded more like it is now (which was hammered-out in long discussions). Simple Yes/No/Ask-Me radio buttons would be best (and, if placed horizontally, would take up no extra space). 5) If a custom item *could* be something *other* than javascript, then the sunken border for "[ ] Enable Javascript" should not enclose the custom items list. 6) If this is where the user is going to deal with "Javascript Permission Levels" (zones) then maybe there should be a "Edit Permission Level Types" button at the top next to "Javascript Permission Levels". € 0.02

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!

> 4) "Same site" and "No Access" mean nothing to me. Maybe it should be worded > more like it is now (which was hammered-out in long discussions). Simple > Yes/No/Ask-Me radio buttons would be best (and, if placed horizontally, would > take up no extra space). "Same site" and "No Access" are being used here as shortcuts, I don't think anyone is suggesting that they are the phrases which would appear on the UI. My original wording for the three options were "Always allow", "Don't allow", and "Only for pages from the same site". These are *not* Yes/No/Ask Me. > 5) If a custom item *could* be something *other* than javascript, then the > sunken border for "[ ] Enable Javascript" should not enclose the custom items > > list. Agreed; at the moment all these relate to Javascript. (It's the same appearance as the existing "Scripts & Windows" panel.

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.

don't forget that the "Enable Javascript" is global. People might confuse it to disabling/enabling javascript per site.

There is a per-policy version of enable/disable javascript as well, capability.policy.policyname.javascipt.enabled

Something like IE with drop-down lists instead of those radios would be ok. But something is still missing then. The policies allow to define every javascript object, i think. The average Joe user will be happy with some standard options for popup windows and status bar text. But everyone else might want to use also the other features. OK, maybe they are smart enough to configure them by directly editing the prefs file. Some kind of "Add Option" feature would be nice. I already have some policies using more features then available in the UI at the moment. So I would need such a feature. I don't think a beginner would be more confused by such a button than by a "Customize" button for IE's standard zones. But another question: Will any average Joe user ever use a complex and powerful zone-policy thing like this? For them the actual "Scripts & Windows" is great. Anything with zones maybe to complex as it is (How many of them every touched IE's Zone configuration without being advised to because of security reasons?). So maybe there have to be one step before. Something like "Scripts&Windows" (for configuring the default-policy) and an "Advanced rules" with all those stuff we are actually discussing. Maybe it's too complex then. Maybe it's impossible to realize. Was just a thought coming up to my mind :-)

Here is a more fleshed out version of what I was thinking for the setting of the policies. Select a zone in the first dialog, then press edit or customize, then this window would popup. You get a list of all the things you can change and little dropdown boxes to select what you want it to do. At the top, it tells you which "zone" you had selected. I think this is better than a checkbox because there can be more than 3 choices and those choices can vary (Maybe not right now, but in the future). If someone selects deny on say javascript, all the other preferences should be automatically disabled. I showed this in the screenshot when they selected Do not allow popups.

The general Javascript Allow/Disallow-Option should however be put out of the list of options because it affects any other option. So I think it's quite important to optically seperate this from the other ones. The human mind needs hierarchies and needs to recognize them :)

I was thinking about that, all of the options below Javascript could be indented and Allow popups on load and unload could be indented in one more level because it is really a child of allow all popups. Can you allow popups on load and unload but not allow all other popups? Useless I know, just wondering :)

> 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.

Peter (#105): > 1) "Zone" is too vague and implies a geographic/physical location. I suggest > "Site-Groups Permissions" or "Site Groups" or "Javascript Permission Levels" Yeah, except "Site-Groups Permissions" or "Site Groups" or "Javascript Permission Levels" aren't 4 letters long. Can you imagine putting such a long-winded phrase on the buttons? [Add Javascript Permission Levels] [Edit Javascript Permission Levels] [Delete Javascript Permission Levels] Okay, maybe I'm just exaggerating a bit, but Zone is still nice. It's what MSIE uses, and they are the experts in PolCor phrases for the average Joe masses. > 2) If all "events" pertain to javascript, then the window title should be > "Javascript permission rules" (at least mention javascript). This isn't a definate here. We will be expanding it to include other things. If you didn't notice, this bug is for "Security Policies", and it should say that in the window. > 3) There should not be two collumns of dropdown lists. Maybe there could be a > fixed list of default javascript events, and then a custom list separated by a > horiz line. I argee. Let's hope Matthew doesn't mention it again :) Matthew (#112): > The average Joe user will be happy with some standard options for popup > windows and status bar text. But everyone else might want to use also the > other features. OK, maybe they are smart enough to configure them by directly > editing the prefs file. Editing the prefs file?! Get out! j/k :) > But another question: Will any average Joe user ever use a complex and > powerful zone-policy thing like this? For them the actual "Scripts & Windows" > is great. Anything with zones maybe to complex as it is (How many of them > every touched IE's Zone configuration without being advised to because of > security reasons?). Isn't there an all or default zone for setting up your global options? If not, there should be, for URLs not matched by the other zones. > So maybe there have to be one step before. Something like "Scripts&Windows" > (for configuring the default-policy) and an "Advanced rules" with all those > stuff we are actually discussing. Maybe it's too complex then. Maybe it's > impossible to realize. Was just a thought coming up to my mind :-) I do argee that we'll need an Advanced... button, as some of this stuff is entering the realm of non-Joe. Of course, if we put this in the Advanced section, we won't need to, but seriously, I think this Security Policy thing should go in the Privacy & Security section. (Makes sense, as this is the bug's name.) Frankly, I don't think the Scripts&Windows menu makes sense in the Advanced section. I have to give credit for the way WinXP handles its TCP/IP properties and the Advanced button there. If we can get a system like that, that'll work. Of course, changing the options is already an Advanced level operation, so having different predefined levels... screw it... just model the whole damn thing off of IE's Security tab :P Sorry, I'm ranting. I'd create some screenshots of my own (instead of talking about them), but I'm on Linux and don't even have VB to play with. Neil (#113): > Created an attachment (id=63290) > Another suggestion for the customize dialog Okay, now that looks a lot better. I guess the grid lines work after all. Neil (#115): > Can you allow popups on load and unload but not allow all other popups? > Useless I know, just wondering :) That's the subject of another debate already in progress on another bug, referenced in one of Boris's comments. Matt (#117): > 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. That's good. I guess add the drop-box on the top of the Options dialog. The main screen would have the URLs, and the secondary would have the options, both with ways to select the zone. --- BTW, why is this bug still set to New? Can we slow down on the attachments? We already used up 5 slots in two days, and I see no way to delete the old versions.

>Can you imagine putting such a long-winded phrase on the buttons? >[Add Javascript Permission Levels] >[Edit Javascript Permission Levels] >[Delete Javascript Permission Levels] I can imagine *Site Permission Groups* or *Site Permissions* New Group Edit Group Delete Group That is 1 additional letter compaired to Zone and also "neutral" (ie not specific to JS). >Isn't there an all or default zone for setting up your global options? If not, there should be, for URLs not matched by the other zones. Indeed there must be definable default/global setting, which the individual group permissions should override. >I do argee that we'll need an Advanced... button, as some of this stuff is entering the realm of non-Joe. I'd rather see an "Enable advanced options" checkbox. When enabled the "advanced" features appear together with the rest, and not in some other menu/window. > The main screen would have the URLs, and the secondary would have the options, both with ways to select the zone. Sounds good to mee too =)

> 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 :)

Previously stated options: JavaScript Popup windows Popup Windows on load and unload Move the browser window Resize the browser wondow Make windows popup/under others Change the status bar text Change Images (Image rollovers) Create or change cookies Read cookies Other options which could be added: Allow the web page to scroll itself self.scrollTo(0,20); self.scrollBy(-5,30); Allow the web page to know what browser I'm using navigator.userAgent navigator.appVersion navigator.appName navigator.appCodeName Allow the web page to see what operating system I'm using navigator.platform Allow the web page to see what plugins I have installed navigator.plugins[index] Allow the web page to see what resolution I'm running screen.width screen.height screen.availLeft screen.availTop screen.availWidth screen.availHeight Allow the web page to see how many colours I am displaying screen.pixelDepth screen.colorDepth Is it possible (I have a hunch it's not), in the back end, to force all "untrusted sites" to use my predefined colours, yet have all others use their own link colours? Can the policies stop these (when a page opens a new window, force it to have a menu bar and status bar)? self.menubar.visible=false; self.toolbar.visible=false; self.locationbar.visible=false; self.personalbar.visible=false; self.scrollbars.visible=false; self.statusbar.visible=false; And one more thing. Wouldn't it be best if prefs not on the list were set in an editable version of about:config (Bug 110090)

> 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. ***

[sg:want P3] - this refers specifically to letting users whitelist sites on which they want to allow JavaScript. Many users would like to disable JavaScript for security reasons (it's a great way to protect against yet-to-be-discovered browser security holes) but can't because they use a few sites that need JavaScript. The NoScript extension provides UI for whitelisting sites for JavaScript and is the 6th most popular extension on addons.mozilla.org.

(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.