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
* 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...
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
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.
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
Where is the Security Policies panel? There's a panel in the PSM dialog under
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
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.
So here are my UI thoughts:
We allow users to create n zones for sites whose activity they wish to limit. We
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
| 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
Created attachment 23448 [details]
What a zone-savvy prefs dialog should look like
also setting this dependent on the 'prevent annoying popups' bug 29346.
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,"
Created attachment 23677 [details]
A much less horribly-modal (and more space-conserving) design than my previous attempt
Yucky sites |\
New Zone ...
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. ***
Created attachment 30279 [details]
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
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.
*** 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
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. ***
Created attachment 49951 [details]
Proposed UI: pref-policies.xul
First stab at a patch attached. It allows creating and deleting zones,
Window.status capabilities for each zone.
You'll need to include a link to it in your prefs tree.
Matthew, you are now officially my hero. It looks spiffy.
currently controlled in the Advanced Preferences panel.)
instead of capability.policy.mailnews.javascipt.enabled?
Ah. I see. In my prefs, I do not have any
defaulting to unchecked. If undefined, it should resort to the value of
...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
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.
a UI for this one, under Advanced). THat one covers all content within a mail
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
> 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
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
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
maybe provide with a expert mode when I have to type the name of the properties
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
> There is an installable XPI and screenshots of the current version at
> 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...
enough. There should at least be the same options as the ones currently in the
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?
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.
Agreed - I expect that the options should be the same as on 0.9.7's "Scripts &
[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
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
Created attachment 63187 [details]
Idea for interface
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.
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 -
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
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.
Created attachment 63262 [details]
Suggestions for customize dialog
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
>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
I suggest to (re)consider the following:
1) "Zone" is too vague and implies a geographic/physical location. I suggest
3) There should not be two collumns of dropdown lists. Maybe there could be a
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).
Levels" (zones) then maybe there should be a "Edit Permission Level Types"
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.
> > list.
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.
Something like IE with drop-down lists instead of those radios would be ok. But
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 :-)
Created attachment 63290 [details]
Another suggestion for the customize dialog
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).
automatically disabled. I showed this in the screenshot when they selected Do
not allow popups.
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 :)
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.
> 1) "Zone" is too vague and implies a geographic/physical location. I suggest
Permission Levels" aren't 4 letters long. Can you imagine putting such a
long-winded phrase on the buttons?
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.
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
> horiz line.
I argee. Let's hope Matthew doesn't mention it again :)
> 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
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.
> 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.
> 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.
> 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?
I can imagine
*Site Permission Groups* or *Site Permissions*
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
( 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:
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
Other options which could be added:
Allow the web page to scroll itself
Allow the web page to know what browser I'm using
Allow the web page to see what operating system I'm using
Allow the web page to see what plugins I have installed
Allow the web page to see what resolution I'm running
Allow the web page to see how many colours I am displaying
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)?
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.
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
*** 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
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
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. ***
read current way of setting policy is by as following line in prefs.js
This option wont allows us to have some pages of a site to show alert and others
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):
| | +--<safe.popup.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
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. ***
*** Bug 402077 has been marked as a duplicate of this bug. ***
(Filter "spam" on 'prefs-nobody-20080612'.)
*** Bug 610898 has been marked as a duplicate of this bug. ***
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.