Last Comment Bug 38966 - (BlockJS) Privacy and Security [was Security Policies] pref panel work
(BlockJS)
: Privacy and Security [was Security Policies] pref panel work
Status: RESOLVED FIXED
[sg:want P3][2012 Fall Equinox]
: meta, sec-want
Product: SeaMonkey
Classification: Client Software
Component: Preferences (show other bugs)
: Trunk
: All All
: -- enhancement with 87 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 27012 43712 44037 45083 46602 63287 76058 79773 80754 100127 115789 118602 119692 125923 137377 145316 146370 149537 153301 154799 156885 157436 159925 160647 192667 207196 207807 222678 223798 277160 402077 610898 (view as bug list)
Depends on: 150872 27159 29346 43501 75371 81526 1258295
Blocks: 114521 436934 BlockFlash
  Show dependency treegraph
 
Reported: 2000-05-11 13:15 PDT by sairuh (rarely reading bugmail)
Modified: 2016-03-29 07:09 PDT (History)
100 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
What a zone-savvy prefs dialog should look like (3.33 KB, text/plain)
2001-01-25 06:39 PST, Matthew Paul Thomas
no flags Details
A much less horribly-modal (and more space-conserving) design than my previous attempt (3.12 KB, text/plain)
2001-01-28 05:26 PST, Matthew Paul Thomas
no flags Details
UI for Javascript settings within mpt's prefs UI (1.98 KB, text/plain)
2001-04-10 09:46 PDT, Peter Lairo
no flags Details
Proposed UI: pref-policies.xul (12.14 KB, text/plain)
2001-09-19 13:48 PDT, Matthew Wilson
no flags Details
Revised UI (pref-policies.xul) (12.08 KB, application/vnd.mozilla.xul+xml)
2001-12-12 02:29 PST, Matthew Wilson
no flags Details
Idea for interface (13.22 KB, image/gif)
2002-01-01 13:11 PST, Neil Marshall
no flags Details
Screenshot of possible UI (30.19 KB, image/png)
2002-01-02 08:13 PST, Matthew Wilson
no flags Details
Suggestions for customize dialog (36.58 KB, image/gif)
2002-01-02 10:47 PST, Matthias Deege
no flags Details
How Visual Basic does it (2.29 KB, image/gif)
2002-01-02 11:15 PST, Neil Marshall
no flags Details
Another suggestion for the customize dialog (9.95 KB, image/gif)
2002-01-02 13:56 PST, Neil Marshall
no flags Details

Description sairuh (rarely reading bugmail) 2000-05-11 13:15:08 PDT
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
Comment 1 sairuh (rarely reading bugmail) 2000-05-11 13:16:26 PDT
not sure if the work for this is due for nsbeta2... expected miletstone?
Comment 2 Mitchell Stoltz (not reading bugmail) 2000-05-11 13:24:35 PDT
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.
Comment 3 Stephen P. Morse 2000-05-11 14:28:28 PDT
I'm not doing any UI for this.  Ben is in charge of pref UI.
Comment 4 leger 2000-05-11 15:16:29 PDT
Putting on [nsbeta2-] radar. Not critical to beta2.
Comment 5 Chris McAfee 2000-05-16 15:12:00 PDT
UI needs layout cleanup, things are jumbled up right now.
Comment 6 sairuh (rarely reading bugmail) 2000-06-28 13:16:48 PDT
*** Bug 44037 has been marked as a duplicate of this bug. ***
Comment 7 Blake Ross 2000-06-28 21:46:02 PDT
morse -- ben did the UI for this, right?  just need the backend now?
Comment 8 Stephen P. Morse 2000-06-29 07:56:19 PDT
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.
Comment 9 Stephen P. Morse 2000-06-29 07:57:31 PDT
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.
Comment 10 Blake Ross 2000-06-29 11:08:00 PDT
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)
Comment 11 sairuh (rarely reading bugmail) 2000-06-29 11:10:21 PDT
h'm, was under the impression that ben was doing the backend work on this...
ben?
Comment 12 Ben Goodger (use ben at mozilla dot org for email) 2000-06-29 16:42:02 PDT
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. 

Comment 13 Blake Ross 2000-07-04 23:52:33 PDT
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.
Comment 14 Jay Patel [:jay] 2000-07-05 13:25:09 PDT
Putting on [nsbeta2-] radar. Not critical to beta2. We decided to cut the panel 
from the product (according to bug 44121).
Comment 15 Blake Ross 2000-07-05 13:30:30 PDT
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.
Comment 16 verah (gone) 2000-07-21 14:24:30 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.
Comment 17 Ben Goodger (use ben at mozilla dot org for email) 2000-07-22 22:21:40 PDT
adding nsbeta3 keyword. 
Comment 18 Ben Goodger (use ben at mozilla dot org for email) 2000-07-22 23:02:04 PDT
*** Bug 43712 has been marked as a duplicate of this bug. ***
Comment 19 Claudius Gayle 2000-07-26 12:09:35 PDT
nav triage team: [b3nav+] now = [nsbeta3+]
Comment 20 sairuh (rarely reading bugmail) 2000-07-31 12:54:41 PDT
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...
Comment 21 Ben Goodger (use ben at mozilla dot org for email) 2000-08-10 14:17:24 PDT
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+
Comment 22 Blake Ross 2000-08-10 14:25:06 PDT
OK, I talked to ben, and agreed to give this a shot.  No promises, but it's 
better than lying around futured.
Comment 23 Paul Wyskoczka 2000-08-11 06:43:39 PDT
John could you look at this when it's fixed. Thanks
Changing QA Contact to junruh@netscape.com
Comment 24 Mitchell Stoltz (not reading bugmail) 2000-08-11 16:19:50 PDT
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.
Comment 25 Mitchell Stoltz (not reading bugmail) 2000-08-14 14:35:29 PDT
*** Bug 27012 has been marked as a duplicate of this bug. ***
Comment 26 Mitchell Stoltz (not reading bugmail) 2000-08-14 14:37:05 PDT
What features will the Security Policies panel have?
Comment 27 leger 2000-08-22 09:38:34 PDT
lord, is this for you'all to outline?
Comment 28 Blake Ross 2000-08-22 09:48:06 PDT
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.
Comment 29 Blake Ross 2000-08-24 13:35:46 PDT
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.
Comment 30 John Unruh 2000-11-15 14:49:26 PST
Marking invalid, based upon bug 50172 being invalid.
Comment 31 John Unruh 2000-11-27 09:19:45 PST
Verified.
Comment 32 sairuh (rarely reading bugmail) 2000-12-14 13:32:33 PST
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. :)
Comment 33 Blake Ross 2000-12-14 16:13:21 PST
doing that :)
Comment 34 Mitchell Stoltz (not reading bugmail) 2000-12-14 19:41:58 PST
*** Bug 46602 has been marked as a duplicate of this bug. ***
Comment 35 Mitchell Stoltz (not reading bugmail) 2000-12-19 12:45:38 PST
*** Bug 63287 has been marked as a duplicate of this bug. ***
Comment 36 Ben Goodger (use ben at mozilla dot org for email) 2001-01-24 20:11:18 PST
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. 
Comment 37 Ben Goodger (use ben at mozilla dot org for email) 2001-01-24 21:01:01 PST
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. 

Comment 38 Matthew Paul Thomas 2001-01-25 06:37:05 PST
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.
Comment 39 Matthew Paul Thomas 2001-01-25 06:39:16 PST
Created attachment 23448 [details]
What a zone-savvy prefs dialog should look like
Comment 40 sairuh (rarely reading bugmail) 2001-01-25 11:11:09 PST
also setting this dependent on the 'prevent annoying popups' bug 29346.
Comment 41 Mitchell Stoltz (not reading bugmail) 2001-01-25 15:43:00 PST
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.
Comment 42 Mitchell Stoltz (not reading bugmail) 2001-01-25 15:49:40 PST
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...)
Comment 43 Matthew Paul Thomas 2001-01-28 05:26:44 PST
Created attachment 23677 [details]
A much less horribly-modal (and more space-conserving) design than my previous attempt
Comment 44 timeless 2001-01-28 09:27:29 PST
  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)
Comment 45 Matthew Paul Thomas 2001-01-28 09:43:35 PST
> 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.
Comment 46 sairuh (rarely reading bugmail) 2001-02-07 19:55:28 PST
*** Bug 45083 has been marked as a duplicate of this bug. ***
Comment 47 Boris Zbarsky [:bz] (still a bit busy) 2001-04-10 09:26:06 PDT
*** Bug 75371 has been marked as a duplicate of this bug. ***
Comment 48 Peter Lairo 2001-04-10 09:46:07 PDT
Created attachment 30279 [details]
UI for Javascript settings within mpt's prefs UI
Comment 49 sairuh (rarely reading bugmail) 2001-04-11 13:39:06 PDT
nominating...bueller? :)
Comment 50 sairuh (rarely reading bugmail) 2001-04-13 11:41:09 PDT
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.
Comment 51 Mitchell Stoltz (not reading bugmail) 2001-04-16 12:08:31 PDT
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. 
Comment 52 Keyser Sose 2001-04-17 13:28:15 PDT
*** Bug 76058 has been marked as a duplicate of this bug. ***
Comment 53 sairuh (rarely reading bugmail) 2001-04-20 17:41:52 PDT
clearing minus for nsbeta1 reconsideration --now that there is a Privacy and
Security panel in the preferences dialog.
Comment 54 sairuh (rarely reading bugmail) 2001-04-23 17:42:03 PDT
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...
Comment 55 Viswanath Ramachandran 2001-04-30 15:51:33 PDT
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. 
Comment 56 Mitchell Stoltz (not reading bugmail) 2001-05-09 14:32:52 PDT
*** Bug 79773 has been marked as a duplicate of this bug. ***
Comment 57 Peter Lairo 2001-05-11 13:26:30 PDT
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).
Comment 58 Blake Ross 2001-05-14 08:47:20 PDT
Okay, I'll take this.
Comment 59 Asa Dotzler [:asa] 2001-05-14 13:13:46 PDT
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.
Comment 60 Boris Zbarsky [:bz] (still a bit busy) 2001-05-14 19:39:33 PDT
*** Bug 80754 has been marked as a duplicate of this bug. ***
Comment 61 Jens Lautenbacher 2001-05-17 12:16:10 PDT
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.
Comment 62 Jeremy Loeb (gone) 2001-05-17 15:18:51 PDT
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.
Comment 63 Alec Flett 2001-05-17 15:33:07 PDT
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
Comment 64 sairuh (rarely reading bugmail) 2001-05-17 16:47:00 PDT
i filed bug 81526 for the empty P&S toplevel panel. let's continue discussion
there. thx!
Comment 65 A. Craig West 2001-09-14 11:19:03 PDT
This looks like the best candidate for the UI for Bug 7380, unless somebody
knows a better one...
Comment 66 sairuh (rarely reading bugmail) 2001-09-17 18:14:59 PDT
*** Bug 100127 has been marked as a duplicate of this bug. ***
Comment 67 Matthew Wilson 2001-09-19 13:48:43 PDT
Created attachment 49951 [details]
Proposed UI: pref-policies.xul
Comment 68 Matthew Wilson 2001-09-19 13:52:31 PDT
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.
Comment 69 James Paige 2001-09-19 14:16:57 PDT
Matthew, you are now officially my hero. It looks spiffy.

Is "Enable Javascript" supposed to be unchecked by default?
Comment 70 Matthew Wilson 2001-09-20 03:29:42 PDT
"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.)
Comment 71 Matthew Wilson 2001-09-20 03:57:15 PDT
There also seems to be a preference javascript.allow.mailnews. Should I use that
instead of capability.policy.mailnews.javascipt.enabled?
Comment 72 James Paige 2001-09-20 07:57:02 PDT
> "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?
Comment 73 Matthew Wilson 2001-09-20 08:34:11 PDT
Pref loading and saving should be OK as long as this panel is being called from
the preferences panel.
Comment 74 James Paige 2001-09-20 09:46:49 PDT
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.
Comment 75 Mitchell Stoltz (not reading bugmail) 2001-09-20 11:14:51 PDT
> "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.
Comment 76 Matthew Wilson 2001-09-20 13:22:58 PDT
How about, say, capability.policy.mailnews.Window.open?

And should we allow capability.policy.mailnews.sites to be edited?

Comment 77 Mitchell Stoltz (not reading bugmail) 2001-09-20 16:51:15 PDT
> 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.

Comment 78 Matthew Wilson 2001-12-12 02:29:44 PST
Created attachment 61423 [details]
Revised UI (pref-policies.xul)

Brings up to date with XUL changes. Prevents viewing or editing of list of site
for "mailnews".
Comment 79 Blake Ross 2001-12-13 10:11:14 PST
Matthew's doing the work...
Comment 80 Boris Zbarsky [:bz] (still a bit busy) 2001-12-18 00:07:58 PST
*** Bug 115789 has been marked as a duplicate of this bug. ***
Comment 81 Matthew Wilson 2001-12-18 01:05:21 PST
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.
Comment 82 Guillaume Coté 2001-12-18 02:39:27 PST
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.
Comment 83 Matthew Wilson 2001-12-18 06:34:59 PST
>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.
Comment 84 Guillaume Coté 2001-12-18 06:51:55 PST
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.
Comment 85 Matthew Wilson 2001-12-18 07:48:51 PST
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)?
Comment 86 SineSwiper 2002-01-01 08:05:05 PST
> 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.
Comment 87 SineSwiper 2002-01-01 10:08:43 PST
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?
Comment 88 Neil Marshall 2002-01-01 10:52:24 PST
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.
Comment 89 Matthew Wilson 2002-01-01 11:06:58 PST
[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?
Comment 90 Neil Marshall 2002-01-01 11:10:44 PST
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.
Comment 91 SineSwiper 2002-01-01 11:40:30 PST
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.
Comment 92 Neil Marshall 2002-01-01 13:11:50 PST
Created attachment 63187 [details]
Idea for interface
Comment 93 Boris Zbarsky [:bz] (still a bit busy) 2002-01-01 15:56:20 PST
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.
Comment 94 Matthias Deege 2002-01-02 04:37:08 PST
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.
Comment 95 Matthew Wilson 2002-01-02 08:13:39 PST
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.)
Comment 96 SineSwiper 2002-01-02 08:17:53 PST
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.
Comment 97 Boris Zbarsky [:bz] (still a bit busy) 2002-01-02 08:23:03 PST
In my opinion it would make more sense to upgrade the current Scripts&Windows 
panel to a three-choice menu from its current checkboxes...
Comment 98 SineSwiper 2002-01-02 10:11:08 PST
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?

Comment 99 Boris Zbarsky [:bz] (still a bit busy) 2002-01-02 10:27:21 PST
> 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).
Comment 100 Matthias Deege 2002-01-02 10:45:10 PST
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.
Comment 101 Matthias Deege 2002-01-02 10:47:47 PST
Created attachment 63262 [details]
Suggestions for customize dialog
Comment 102 SineSwiper 2002-01-02 11:07:40 PST
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.)
Comment 103 Neil Marshall 2002-01-02 11:15:04 PST
Created attachment 63268 [details]
How Visual Basic does it

Take a look at how visual basic does it.  It's a list, with dropdown menus in
the list.  It would also make it shorter than having a bunch of radio boxes
like IE.
Comment 104 Matthew Wilson 2002-01-02 11:24:24 PST
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.
Comment 105 Peter Lairo 2002-01-02 11:48:12 PST
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
Comment 106 SineSwiper 2002-01-02 12:02:20 PST
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!
Comment 107 Matthew Wilson 2002-01-02 12:29:21 PST
> 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.
Comment 108 Boris Zbarsky [:bz] (still a bit busy) 2002-01-02 12:41:15 PST
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.
Comment 109 Neil Marshall 2002-01-02 12:47:37 PST
> 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.
Comment 110 Doron Rosenberg (IBM) 2002-01-02 13:03:06 PST
don't forget that the "Enable Javascript" is global. People might confuse it to
disabling/enabling javascript per site.
Comment 111 Boris Zbarsky [:bz] (still a bit busy) 2002-01-02 13:12:52 PST
There is a per-policy version of enable/disable javascript as well,
capability.policy.policyname.javascipt.enabled
Comment 112 Matthias Deege 2002-01-02 13:53:30 PST
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 :-)
Comment 113 Neil Marshall 2002-01-02 13:56:04 PST
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).

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.
Comment 114 Matthias Deege 2002-01-02 14:12:46 PST
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 :)
Comment 115 Neil Marshall 2002-01-02 14:29:38 PST
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 :)
Comment 116 Boris Zbarsky [:bz] (still a bit busy) 2002-01-02 14:32:31 PST
> Can you allow popups on load and unload but not allow all other popups? 

Not with the current back end.
Comment 117 Matthias Deege 2002-01-02 15:04:16 PST
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.
Comment 118 SineSwiper 2002-01-02 19:30:40 PST
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.
Comment 119 Stefan Huszics 2002-01-03 04:53:24 PST
>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 =)
Comment 120 Boris Zbarsky [:bz] (still a bit busy) 2002-01-03 07:41:49 PST
> I'd rather see an "Enable advanced options" checkbox.

You mean <disclosure /> widget right?  (Once that works)
Comment 121 SineSwiper 2002-01-03 08:42:12 PST
> You mean <disclosure /> widget right?  (Once that works)

Say again?  Sorry, not versed in X programming.

Comment 122 Boris Zbarsky [:bz] (still a bit busy) 2002-01-03 08:53:57 PST
<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.
Comment 123 Stefan Huszics 2002-01-03 09:18:55 PST
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.
Comment 124 Matthias Deege 2002-01-03 10:22:18 PST
> 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 :)
Comment 125 Neil Marshall 2002-01-04 21:59:55 PST
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)
Comment 126 Boris Zbarsky [:bz] (still a bit busy) 2002-01-04 22:10:19 PST
> 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
Comment 127 SineSwiper 2002-01-05 06:14:02 PST
BTW, this stuff ain't UI.  Again, our helpful Boris has bug links on comment #93.
Comment 128 Olav Vitters 2002-01-12 12:15:48 PST
*** Bug 119692 has been marked as a duplicate of this bug. ***
Comment 129 Mitchell Stoltz (not reading bugmail) 2002-02-06 14:33:27 PST
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.
Comment 130 Matthias Versen [:Matti] 2002-02-16 13:38:18 PST
*** Bug 125923 has been marked as a duplicate of this bug. ***
Comment 131 Boris Zbarsky [:bz] (still a bit busy) 2002-04-14 07:30:27 PDT
*** Bug 137377 has been marked as a duplicate of this bug. ***
Comment 132 A. Craig West 2002-04-26 13:59:30 PDT
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.
Comment 133 Boris Zbarsky [:bz] (still a bit busy) 2002-04-26 14:37:48 PDT
All the back end is in place for this, and the prefs go in prefs.js
Comment 134 Matthew Wilson 2002-04-27 01:54:40 PDT
Sorry, I've allowed my patch to become out of date.
Comment 135 Jesse Ruderman 2002-05-12 19:56:13 PDT
*** Bug 118602 has been marked as a duplicate of this bug. ***
Comment 136 Vidar Haarr (not reading bugmail) 2002-05-13 07:42:41 PDT
What about adding the mozilla1.0 and nsbeta1 keywords here ?
btw, I really like http://bugzilla.mozilla.org/attachment.cgi?id=63290&action=view
Comment 137 Alfonso Martinez 2002-05-17 13:47:14 PDT
*** Bug 145316 has been marked as a duplicate of this bug. ***
Comment 138 Alfonso Martinez 2002-05-23 07:27:03 PDT
*** Bug 146370 has been marked as a duplicate of this bug. ***
Comment 139 Gilles Durys 2002-06-06 02:52:33 PDT
*** Bug 149537 has been marked as a duplicate of this bug. ***
Comment 140 Matthias Versen [:Matti] 2002-06-21 02:52:07 PDT
*** Bug 153301 has been marked as a duplicate of this bug. ***
Comment 141 Matthew Wilson 2002-06-27 01:40:40 PDT
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).
Comment 142 Matthew Wilson 2002-06-28 05:42:30 PDT
Sorry, I meant bug 117707
Comment 143 Alfonso Martinez 2002-06-28 08:50:16 PDT
*** Bug 154799 has been marked as a duplicate of this bug. ***
Comment 144 Matthew Wilson 2002-07-11 01:30:42 PDT
Looks like someone has developed an XPI for this at
http://www.cc-net.or.jp/~piro/xul/_policymanager.html
Comment 145 Matthew Wilson 2002-07-11 07:00:11 PDT
*** Bug 156885 has been marked as a duplicate of this bug. ***
Comment 146 Matthias Versen [:Matti] 2002-07-14 12:46:20 PDT
*** Bug 157436 has been marked as a duplicate of this bug. ***
Comment 147 Hanspeter Niederstrasser 2002-07-24 12:20:46 PDT
*** Bug 150872 has been marked as a duplicate of this bug. ***
Comment 148 R.K.Aa. 2002-07-29 09:29:47 PDT
*** Bug 159925 has been marked as a duplicate of this bug. ***
Comment 149 Vincent Lefevre 2002-07-29 09:33:46 PDT
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.
Comment 150 Alfonso Martinez 2002-08-02 02:21:51 PDT
*** Bug 160647 has been marked as a duplicate of this bug. ***
Comment 151 Arne Falk 2002-08-02 03:34:47 PDT
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).
Comment 152 Sean Kendall Schneyer 2002-08-02 08:07:16 PDT
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."
Comment 153 Vincent Lefevre 2002-08-02 08:14:52 PDT
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.
Comment 154 Thorsten Gebuhr 2002-08-03 05:25:18 PDT
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.
Comment 155 Vincent Lefevre 2002-08-03 05:51:13 PDT
and clicking on the icon could unblock the popup (temporarily or permanently,
perhaps depending on what button has been used).
Comment 156 Vladimir Ermakov 2002-09-12 15:09:49 PDT
Marking bug 150872 as blocking this bug, based on coment #6 in that report.
Comment 157 HJ 2002-11-20 02:29:26 PST
Matthew Wilson is gone, right? So why is this bug, the only one, still assigned
to him?
Comment 158 Matthew Wilson 2002-11-20 04:57:22 PST
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)
Comment 159 Alfonso Martinez 2003-02-11 14:33:51 PST
*** Bug 192667 has been marked as a duplicate of this bug. ***
Comment 160 Biju 2003-03-07 20:18:02 PST
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.
Comment 161 Matthias Versen [:Matti] 2003-05-26 22:58:32 PDT
*** Bug 207196 has been marked as a duplicate of this bug. ***
Comment 162 Charles Fenwick 2003-10-18 18:56:25 PDT
*** Bug 222678 has been marked as a duplicate of this bug. ***
Comment 163 Boris Zbarsky [:bz] (still a bit busy) 2003-10-26 21:25:09 PST
*** Bug 223798 has been marked as a duplicate of this bug. ***
Comment 164 Kyle Guinn 2004-08-06 23:42:50 PDT
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.
Comment 165 Kenneth Herron 2005-01-05 11:38:59 PST
*** Bug 277160 has been marked as a duplicate of this bug. ***
Comment 166 Daniel Veditz [:dveditz] 2006-08-09 16:36:02 PDT
*** Bug 207807 has been marked as a duplicate of this bug. ***
Comment 167 Daniel Veditz [:dveditz] 2006-08-09 16:43:34 PDT
*** Bug 320522 has been marked as a duplicate of this bug. ***
Comment 168 Daniel Veditz [:dveditz] 2006-08-09 16:45:19 PDT
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.
Comment 169 georgi - hopefully not receiving bugspam 2006-08-11 08:47:52 PDT
since there is implementation of zones (pref-policies.xul) why not review it for usability and bake it on the trunk?
Comment 170 Ria Klaassen (not reading all bugmail) 2006-10-26 01:19:34 PDT
*** Bug 358113 has been marked as a duplicate of this bug. ***
Comment 171 Jesse Ruderman 2006-12-14 05:05:05 PST
[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.
Comment 172 Kevin Brosnan 2007-11-01 10:22:41 PDT
*** Bug 402077 has been marked as a duplicate of this bug. ***
Comment 173 Serge Gautherie (:sgautherie) 2008-06-11 15:01:57 PDT
(Filter "spam" on 'prefs-nobody-20080612'.)
Comment 174 Jesse Ruderman 2011-03-23 15:38:08 PDT
*** Bug 610898 has been marked as a duplicate of this bug. ***
Comment 175 brunoais 2012-04-06 03:43:38 PDT
Any news about this bug?
Comment 176 Phoenix 2012-09-23 13:49:03 PDT
With presence of Data Manager in current SeaMonkey versions, is this bug still actual?
Comment 177 Mark Straver 2013-12-28 11:42:45 PST
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?
Comment 178 rsx11m 2016-03-29 07:09:49 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.