Closed Bug 38966 (BlockJS) Opened 24 years ago Closed 8 years ago

Privacy and Security [was Security Policies] pref panel work

Categories

(SeaMonkey :: Preferences, enhancement)

Product:
SeaMonkey
Component:
Preferences
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bugzilla, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: meta, sec-want, Whiteboard: [sg:want P3][2012 Fall Equinox])

Attachments

(9 files, 1 obsolete file)

What a zone-savvy prefs dialog should look like
3.33 KB, text/plain
Details
A much less horribly-modal (and more space-conserving) design than my previous attempt
3.12 KB, text/plain
Details
UI for Javascript settings within mpt's prefs UI
1.98 KB, text/plain
Details
Revised UI (pref-policies.xul)
12.08 KB, application/vnd.mozilla.xul+xml
Details
Idea for interface
13.22 KB, image/gif
Details
Screenshot of possible UI
30.19 KB, image/png
Details
Suggestions for customize dialog
36.58 KB, image/gif
Details
How Visual Basic does it
2.29 KB, image/gif
Details
Another suggestion for the customize dialog
9.95 KB, image/gif
Details 
if there's a tracking bug on this already, feel free to dup. basically, in the
browser Preferences dialog, the features in the Security Panel aren't
functional, afaik:

* Policies scrolling list does nothing
* Add Site... button does nothing
* Policy Description: Settings for button does nothing
not sure if the work for this is due for nsbeta2... expected miletstone?
Keywords: meta, nsbeta2
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.
Assignee: mstoltz → morse
Target Milestone: --- → M20
I'm not doing any UI for this.  Ben is in charge of pref UI.
Assignee: morse → ben
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
UI needs layout cleanup, things are jumbled up right now.

*** Bug 44037 has been marked as a duplicate of this bug. ***
Depends on: 27159
morse -- ben did the UI for this, right?  just need the backend now?
Assignee: ben → morse
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.
Assignee: morse → 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)
Assignee: ben → mstoltz
Component: Preferences → Security: General
QA Contact: sairuh → czhang
h'm, was under the impression that ben was doing the backend work on this...
ben?
ack!
this is mine. All the back end stuff is in place, and has been in place since 
the completion of bug 858. All this requires is me to do this panel. Setting QA 
contact back to se too.
Assignee: mstoltz → ben
QA Contact: czhang → sairuh
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.
Whiteboard: [nsbeta2-]
Putting on [nsbeta2-] radar. Not critical to beta2. We decided to cut the panel 
from the product (according to bug 44121).
Whiteboard: [nsbeta2-]
er...not cut the panel from the product for good, just for beta2...

well, it seems kind of silly to me...44121 asked to cut it for beta2 since it 
wasn't functioning yet, but since the backend is in it seems like it'd be easy 
to get it working.  thus we'd be cutting functionality from beta2 for no 
apparent reason.  Whatever, I won't mess with the mysterious innerworkings of 
the PDT.
Nav triage team: Bug 44121 states that this panel should be taken out of beta2 
but not out of the product. Minor work remains to finalize this.
Whiteboard: [nsbeta2-] → [nsbeta2-] [b3nav+]
adding nsbeta3 keyword.
Status: NEW → ASSIGNED
Keywords: nsbeta3
*** Bug 43712 has been marked as a duplicate of this bug. ***
nav triage team: [b3nav+] now = [nsbeta3+]
Whiteboard: [nsbeta2-] [b3nav+] → [nsbeta2-] [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...
QA Contact: sairuh → paw
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+
Whiteboard: [nsbeta2-] [nsbeta3+] → [nsbeta2-]
Target Milestone: M20 → Future
OK, I talked to ben, and agreed to give this a shot.  No promises, but it's 
better than lying around futured.
Assignee: ben → BlakeR1234
Status: ASSIGNED → NEW
John could you look at this when it's fixed. Thanks
Changing QA Contact to junruh@netscape.com
QA Contact: paw → junruh
Where is the Security Policies panel? There's a panel in the PSM dialog under 
Applications/Java and Javascript, but all that's there is a Reset All Privileges 
button, which does nothing right now. Is this all the functionality that's 
expected? Or am I missing something? A Reset button is probably all that's needed 
for this go-around, as it allows users to start from scratch if they make a 
security decision they want to change later. I own the backend for this 
functionality, so please let me know what features you're adding; I can point you 
at the APIs to accomplish these things.

*** Bug 27012 has been marked as a duplicate of this bug. ***
What features will the Security Policies panel have?

lord, is this for you'all to outline?
Assignee: BlakeR1234 → lord
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.
Keywords: nsbeta3
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.
Assignee: lord → BlakeR1234
Marking invalid, based upon bug 50172 being invalid.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Verified.
Status: RESOLVED → VERIFIED
reopening as an enhancement request per conversation i had with mstolz re: bug
60323 and bug 7380. blake feel free to bop this to someone else/nobody if your
schedule has no room for this in the forseeable future. :)
Severity: major → enhancement
Status: VERIFIED → REOPENED
Component: Security: General → Preferences
Keywords: nsbeta2 → helpwanted
QA Contact: junruh → sairuh
Resolution: INVALID → ---
Summary: Security Policies panel work → Security Policies pref panel work
Target Milestone: Future → ---
Assignee: blakeross → matt
Status: REOPENED → NEW
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.
Assignee: matt → ben
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.
Status: NEW → ASSIGNED
The main problem with having a separate panel is that it would be
forwards-incompatible with the UI for bug 7380. For specific zones I should be 
able to control all display-related prefs -- not just JS calls, but also colors, 
fonts, style sheets, whatever.

And the more prefs were covered by zones, the more duplication of UI you would 
have -- the UI for prefs in `Normal' (i.e. where no other zone applies), and the 
UI for the same prefs in a particular zone.

I think the best way to handle this is to have a popup menu and buttons at the 
top of the prefs dialog for managing zones, like the popup menu and buttons at 
the top of Mac OS's Internet control panel for managing Sets. Then all prefs 
configured below the popup menu are obviously meant to apply to the selected 
zone, and you can quickly flick between zones to see how their settings differ. 
The only awkward part of this is that the `Navigator' category of prefs would be 
under the popup menu but not controlled by the zones; the best way I can think of 
to deal with this is to disable the whole of the `Navigator' category when a zone 
other than `Normal' is selected.

Currently only a few prefs can be handled on a zone-by-zone basis, but the rest 
could be disabled (and shown with their `Normal' zone values), or even hidden, 
until zone coverage for them is implemented.

I'm about to attach mockups showing the Navigator prefs dialog in two different 
states.

also setting this dependent on the 'prevent annoying popups' bug 29346.
Depends on: 29346
Ben,
   Good ideas - basically what I had in mind. This may be a longer-term idea,
but it might be cool to combine cookie management, image blocking, JS security,
and (coming soon) P3P preferences into a "zone prefs" dialog. There isn't any
scriptable access to prefs enumerators yet, but I'm going to add some scriptable
APIs to caps that will give you all the info you need for the UI.
mpt: I agree. It would be great to have all "zoned" prefs in the same place.
Unlike IE, users should be able to define any number of zones, and we should
have some good defaults in place, as Ben suggests (default, "annoying sites,"
trusted sites...)
  Normal settings 
  Trusted zone    
::Too:garish::,:::
  Yucky sites |\  
---------------\--
  New Zone ...    
  Delete "Yuck..."
  Duplicate "Y..."

Get rid of delete and duplicate.  If you're going to put them somewhere we'll 
have to use a listview/treeview control like windows printers/objects which is 
probably a better idea.  New is ok in either a listbox or a listview, but 
Delete and Duplicate do not belong in a listview, they are inconsistent with 
the context. 'Scripts Delete X' doesn't need all of the children like  _Enable 
scripts.  Nor does Scripts Duplicate X.

Ben: is there a xul bug for an object that supports multiple views (esp List, 
Large Icons, Details)
> Get rid of delete and duplicate.

That was a mistake ...

What I drew             What it should be
-----------             -----------------
  New Zone ...            Delete "Yuck..."
  Delete "Yuck..."        Duplicate "Y..."
  Duplicate "Y..."        Zone Coverage...

I know it's bad to include command items in a menu which is mainly for mutually 
exclusive options, but I judged it was far better to do that than to spend screen 
real estate (which we don't have enough of in the prefs dialog as it is) on 
separate controls for something which only a small minority of users will ever 
want to use.

*** Bug 45083 has been marked as a duplicate of this bug. ***
*** Bug 75371 has been marked as a duplicate of this bug. ***
nominating...bueller? :)
Keywords: nsbeta1, nsCatFood
Whiteboard: [nsbeta2-]
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.
Keywords: nsbeta1 → nsbeta1-
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.
Keywords: mozilla0.9.1
*** 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.
Keywords: nsbeta1- → nsbeta1
Depends on: 43501
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...
Summary: Security Policies pref panel work → Privacy and Security [was Security Policies] pref panel work
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.
Keywords: nsbeta1, nsCatFood → nsbeta1+, nsCatFood-
Priority: P3 → P5
Target Milestone: --- → Future
*** Bug 79773 has been marked as a duplicate of this bug. ***
Depends on: 80336
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).
No longer depends on: 80336
Depends on: 75371
Okay, I'll take this.
Assignee: ben → blakeross
Status: ASSIGNED → NEW
This morning's builds had a bug ( bug 80746 ) which may have led to 
a Bugzilla user inadvertantly 
changing this bug from the Assignbed/Accepted status to the New status.  If you 
are the owner of this bug please check to see that it is in the correct Status.  
Thanks.
*** Bug 80754 has been marked as a duplicate of this bug. ***
I'mnot sure if this is the right place to report, but the "Privacy and Security"
prefs panel is the only of the pref panels where the "root panel" has no
content. This looks rather stupid. 

Maybe at least a little informational text could be moved there.

We are working on putting something there... maybe a "reset all prefs" button, 
maybe a summary of privacy/security settings, maybe a button to open up "About 
Security" help window.
don't you have a UI designer behind this? CC'ing german for some input - this is
starting to look like the old 4.x "security stuff looks different than
everything else" disease
i filed bug 81526 for the empty P&S toplevel panel. let's continue discussion
there. thx!
Depends on: 81526
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: Future → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla1.0
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. ***
Status: NEW → ASSIGNED
Attached file Proposed UI: pref-policies.xul (obsolete) — 

    
    

    
  
First stab at a patch attached. It allows creating and deleting zones,
enabling/disabling Javascript for each zone, and setting the Window.open and
Window.status capabilities for each zone.

You'll need to include a link to it in your prefs tree.

Comments welcome.


    
    

    
  
Matthew, you are now officially my hero. It looks spiffy.

Is "Enable Javascript" supposed to be unchecked by default?

    
    

    
  
"Enable Javascript" for a zone should be checked or unchecked depending on the
value of the preference capability.policy.<zone>.javascript.enabled.

(Is this right? There seems to be a javascript.enabled preference as well,
currently controlled in the Advanced Preferences panel.)

    
    

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


    
    

    
  
> "Enable Javascript" for a zone should be checked or unchecked depending on the
> value of the preference capability.policy.<zone>.javascript.enabled.

Ah. I see. In my prefs, I do not have any
capability.policy.<zone>.javascript.enabled defined at all, so it must be
defaulting to unchecked. If undefined, it should resort to the value of
capability.policy.default.javascript.enabled and if THAT is undefined it ought
to resort to the global pref javascript.enabled

...at least thats how I think it probably ought to work without really knowing
how it all works on the inside

Also, I see that the changes I make on your prefs panel are not actuall saved to
my prefs.js file. Is that part just not done yet, or did I install the xul file
wrong?


    
    

    
  
Pref loading and saving should be OK as long as this panel is being called from
the preferences panel.

    
    

    
  
Hmm. I inserted your pref-policies.xul into my comm.jar file at
/content/communicator/pref and I edited my
/content/communicator/pref/preftree.xul file so that the policies panel appears
under the "advanced" branch of my prefs screen. When I go into prefs, I can see
the policy panel, and I can add and change policies, and the zones that I had
already created by manually editing my prefs.js file in the past show up, but
the changes/additions/removals I make go away when i close the prefs panel.

    
    

    
  
> "Enable Javascript" for a zone should be checked or unchecked depending on the
> value of the preference capability.policy.<zone>.javascript.enabled.

This is correct. Don't use "capability.policy.default.javascript.enabled," I'm
not sure if that works. Use the global "javascript.enabled" pref instead. Also,
don't use "capability.policy.mailnews.javascript.enabled" because that doesn't
cover iframes in mail messages. Use "javascript.allow.mailnews" (there's already
a UI for this one, under Advanced). THat one covers all content within a mail
message.

I'm sorry I neglected to mention this earlier, but the zone capability prefs
don't have callbacks to the capabilities engine right now, which menas that
you'll have to restart the browser in some cases for the zone prefs to take
effect. I'm going to add callbacks soon so these prefs can be changed on the fly.


    
    

    
  
How about, say, capability.policy.mailnews.Window.open?

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



    
    

    
  
> How about, say, capability.policy.mailnews.Window.open?
Yes, changing that requires a restart at this point. Changing 'default' prefs
does not.

> And should we allow capability.policy.mailnews.sites to be edited?
No! In fact, the user should not be able to edit any of the existing
capability.policy.mailnews prefs other than to add new restrictions. That could
open up a bunch of holes.

This is great work, but let's take some time to evaluate the security risks of
this UI before we check it in.



    
  
Target Milestone: mozilla1.0 → mozilla0.9.8
No longer blocks: 65121

    
  
Target Milestone: mozilla0.9.8 → mozilla0.9.9

    
  

        Attachment #49951 -
        Attachment is obsolete: true

    
    

    
  


  
Brings up to date with XUL changes. Prevents viewing or editing of list of site
for "mailnews".

    
    

    
  
Matthew's doing the work...
Assignee: blakeross → matthew
Status: ASSIGNED → NEW
Priority: P5 → --
Target Milestone: mozilla0.9.9 → ---

    
  
Blocks: 114521

    
    

    
  
*** Bug 115789 has been marked as a duplicate of this bug. ***

    
    

    
  
There is an installable XPI and screenshots of the current version at
http://security.mozdev.org.

Feedback needed - on the UI, and on what preferences should be exposed.

    
    

    
  
I just download and install your XPI.  There a list various feature I think
could be interesting.

I think the setting maybe ok for a begginner, but there is no expert mode.  What
I would like would be the ability to change member of the policy, just like in
the text file
(http://www.mozilla.org/projects/security/components/ConfigPolicy.html).  That
maybe provide with a expert mode when I have to type the name of the properties
directly.

Regarding the information I would like in the basic dialog, I think it would be
a good think to be able to disable SSL warning for trusted site.

Maybe we could merge all the subsection of the Privacy and Security that retains
site list with your dialog (cookies, images, form, password...), so people could
simply move site to a trusted or untrusted domain instead of saying each time, I
accept images, I accept cookies...

Also, I would like to be able to create a domain by cloning any existing domain.
 (That means the create domain dialog should take two parameters, the base
domain and the domain name).  After it's creation the new domain would be
unrelated to the base domain, it's just in the case we have a lot of properties
sets and we just want to change one for some sites.

    
    

    
  
>Regarding the information I would like in the basic dialog, I think it would be
>a good think to be able to disable SSL warning for trusted site.

Unless there is an existing preference for this (does anyone know?), I think
this should be raised as a new bug. This bug (as I understand it) is only for
creating a UI for existing preferences.

    
    

    
  
Reagarding SSL warning, I search further to find it, but I agree that I have to
open a new bug if it don't exist.

    
    

    
  
Should the list of preferences exposed here be the same as those in
http://bugzilla.mozilla.org/attachment.cgi?id=62007&action=view (the bug 75371
attachment)?

    
    

    
  
> There is an installable XPI and screenshots of the current version at
> http://security.mozdev.org.
> 
> Feedback needed - on the UI, and on what preferences should be exposed.

Just saw the screenshot.  Damn, that's complex, and IE-like, but oh well...

(And to make it more complex...) I think that the two JavaScript options aren't
enough.  There should at least be the same options as the ones currently in the
0.9.8 version.


    
    

    
  
Oh, I have another thought for it: Have it able to block APPLETs, or maybe even
not show ANYTHING from a URL.  This would block those annoying Flash ads that
are cropping up.

Also, look at bug 92469 for some good ideas on being able to import these
settings, including the ability to use reg exps for some of the URLs.  I'm not
sure if regexps are wise or not (imagine the confusion of having one not working
right), but it could be a step into the right direction of getting 100% of all
ads  and annoying pop-ups blocked (while having 100% of your content intacted).

BTW, what's the ETA on getting this put into the official version?

    
    

    
  
UI Suggestions:

Remove the details from the main dialog.  Shouldn't the name of the policy tell 
the user what it is going to block?  Take a look at the Message filters dialog 
- that one is relativly easy to use and doesn't look terribly complex.

Move the details to another dialog where you would see a scrollable list of 
options.  Similar to either Preferences->Advanced->System or the property list 
used in Visual Basic.

An option to move a site from one policy to another would be nice.

As for preferences that should be exposed... well anything which could annoy the 
user.  Popups, moving the browser window, changing the width of the browser 
window, alert boxes, conformation boxes, images, cookies, plugins, applets.  
Thats all I can think of at the moment.

    
    

    
  
[Brendan]> I think that the two JavaScript options aren't enough.  

Agreed - I expect that the options should be the same as on 0.9.7's "Scripts &
Windows" panel.

[Neil]> Remove the details from the main dialog.

Can you be more explicit about what you mean by "details" here?

    
    

    
  
By details I mean "Open windows" and "Change status text"

On the first dialog I'd just want to see the list of policies (Trusted, 
untrusted, etc) and what sites fall under those policies.  If I want to change 
the settings I don't mind going in another level.

    
    

    
  
Yes, similar to the "Custom Level..." button on IE in the Privacy options.  Try
to cram as much security options as possible in that one, again, like in IE. 
(After all, if you're going to have this security dialog look like IE, go all
the way.  And yes, I appreciate the adding of zones feature you put in this
thing, which IE does -not- have.)

IMO, it should have more than just the "Script & Windows" options.  I like the
idea of being able to block certain events, not functions.  Like block all
OnLoad or OnExit events, instead of blocking pop-ups.  Then again, maybe not. 
(I'm just throwing ideas.)

Also, those options should probably have a "prompt" option for each one, so that
you could selectively imploy the option if it's not being naughty.  Of course,
with some details on what it's doing on each dialog box, similar to cookie
prompts.  And yes, you can't really do it with some of the more generalistic
options like "Allow JavaScript", but you know what I mean.

About the message filtering dialog, I don't think it would be a good idea to
model after that.  It's fine how it is, except the type of options should be on
another button/dialog.

    
    

    
  

      
      
      
      

        Attached image
          
        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.
Instead of message filters you configure javascript filters.
And instead of "Body contains" you set up somethin like "Popup windows - Same site".

As a feature for beginners there may be some predefined categories with some
predefined filters (like "annoying sites" -> "popup - never, resize windows -
never" .....)

The advantage may be its similarity. One would see the interface an recognize
"aaaah. I know this." and naturally use it as one is used to do with the message
filters.

    
    

    
  


  
Should this code be reworked as a patch to the existing Scripts & Windows
panel? Here's a screenshot of what it might look like.

(This would lose the ability to specify NoAccess/SameSite/AllAccess, reverting
to a simple Yes/No choice.)

    
    

    
  
Again, I disargee with the Message Filter comparison.  This is NOT a boolean
matching system!  If we were talking about a search engine, such as the message
search, then yes, I'd compare it to the Message Filter (to some degree).  

Actually, I like the model he has, except for the lack of a Settings button. 
It's clean, already has the URLs right there to access (so you know exactly what
the zone is about), and uses only that one Settings dialog box.

I really don't know how your idea would look like anyway, because you are
comparing apples and oranges.  If you had some sort of ASCII art or a virtual
screenshot, I might have a better idea.

    
    

    
  
In my opinion it would make more sense to upgrade the current Scripts&Windows 
panel to a three-choice menu from its current checkboxes...

    
    

    
  
M. Wilson: (comment #95)
> Should this code be reworked as a patch to the existing Scripts & Windows
> panel? Here's a screenshot of what it might look like.

Well, I liked your older idea better, again, with the URL on front.  Makes the
zone more identifible, rather than some arcane-looking JS options.

Boris: (comment #97)
> In my opinion it would make more sense to upgrade the current Scripts&Windows 
> panel to a three-choice menu from its current checkboxes...

Well, we don't have the back-end for an "Prompt" selection set.  This is in bug
103405.  (And lemme point out that I'm very irate that it's set to WONTFIX, when
this is a requested feature from a number of people.)

Wait...you were the one you pointed that out.  Are you talking about something else?



    
    

    
  
> Are you talking about something else?

Yes, I am.  The current security setup has three levels of access for objects:

1)  No access allowed for untrusted content ("noAccess")
2)  Access allowed for all untrusted content ("allAccess")
3)  Access allowed for scripts running on the same "domain" as the page in which
    the object lives.  ("sameOrigin").

The default for most things is "sameOrigin".

The UI at http://security.mozdev.org allows one to choose among the three 
levels, whereas the screenshot in attachment 63247 [details] (as Matthew Wilson points 
out) only allows one to choose between "noAccess" and "default" (whether the 
default is "sameOrigin" or "allAccess" depends on the object in question).

    
    

    
  
OK. You're right. Another idea:

We take the old version with the URL on front and customize zones with some kind
of customize button. I'll create an atachment with some idea for this.

    
    

    
  
I still don't like this more/fewer idea with the options.  It's already a
nightmarish mess on the Message Filter, but it's a necessary evil because
there's a potential of a infinate number of options to put in.

For a static number of options, you use a static system.  What if somebody put
in two of the same option?  Do you follow the first or the second option?  Do
you put up an error message?  Do you take away options when they are used?  Is
this confusing?  Yes!

Besides, I'd rather have the default options available there in plain view,
rather than have to guess on whather it's going to work or not.  You're
basically putting in your run-of-the-mill selection options on an overly-complex
system.  The security panel is complex enough for your average Joe User.

Again, IE's version of this panel is just fine, though I'd prefer drop-down
boxes to a grouping of radio buttons.  (I fine radio buttons to be mostly useless.)

    
    

    
  


  
Take a look at how visual basic does it.  It's a list, with dropdown menus in
the list.  It would also make it shorter than having a bunch of radio boxes
like IE.

    
    

    
  
Boris:
>In my opinion it would make more sense to upgrade the current
> Scripts&Windows panel to a three-choice menu from its current checkboxes...

I think the problem is providing a (relatively) easy UI for people without
advanced requirements - i.e. people who don't care about multiple zones. I think
that the 3-choice menu would be a significantly more complicated UI, because you
have to work out the meaning of 3 complicated phrases before deciding which
option you want. Under the current UI it's just on/off.

    
    

    
  
I think this bug is treading on very thin ice. The subject matter is very
confusing and the terms used may not be the best choices (but should be, due to
the complexity of what is being attempted). Joe user must be able to understand
this.

I suggest to (re)consider the following:

1) "Zone" is too vague and implies a geographic/physical location. I suggest
"Site-Groups Permissions" or "Site Groups" or "Javascript Permission Levels" ...

2) If all "events" pertain to javascript, then the window title should be
"Javascript permission rules" (at least mention javascript).

3) There should not be two collumns of dropdown lists. Maybe there could be a
fixed list of default javascript events, and then a custom list separated by a
horiz line.

4) "Same site" and "No Access" mean nothing to me. Maybe it should be worded
more like it is now (which was hammered-out in long discussions). Simple
Yes/No/Ask-Me radio buttons would be best (and, if placed horizontally, would
take up no extra space).

5) If a custom item *could* be something *other* than javascript, then the
sunken border for "[ ] Enable Javascript" should not enclose the custom items list.

6) If this is where the user is going to deal with "Javascript Permission
Levels" (zones) then maybe there should be a "Edit Permission Level Types"
button at the top next to "Javascript Permission Levels".

€ 0.02

    
    

    
  
Yes, but the VB is a list of variables for a bunch of programmers.  We are going
to be dealing with average Joe User, who needs a bit more descriptive info on
what the option does (like "Change Status Text", not "ChgStatusText"), and the
grid system would look kinda ugly like that.  Just have the same system without
the gridlines and it'll look good.

And definately make a dialog box for it.  Not only would the amount of options
not fit the vertical, but the descr + drop-down won't fit the horizonal of that
small general Preferences box, either.  As it is, IE has this -ugly- horizonal
scrollbar (on the Custom Level box), which we should NOT copy!

    
    

    
  
> 4) "Same site" and "No Access" mean nothing to me. Maybe it should be worded
> more like it is now (which was hammered-out in long discussions). Simple
> Yes/No/Ask-Me radio buttons would be best (and, if placed horizontally, would
> take up no extra space).

"Same site" and "No Access" are being used here as shortcuts, I don't think
anyone is suggesting that they are the phrases which would appear on the UI. My
original wording for the three options were "Always allow", "Don't allow", and
"Only for pages from the same site". These are *not* Yes/No/Ask Me.

> 5) If a custom item *could* be something *other* than javascript, then the
> sunken border for "[ ] Enable Javascript" should not enclose the custom items
> > list.

Agreed; at the moment all these relate to Javascript. (It's the same appearance
as the existing "Scripts & Windows" panel.

    
    

    
  
Matthew, point taken.  A simple yes/no toggle is what most users care about.  
The few who want to make things allAccess can use a sidebar panel or some such 
that is not a default part of the browser UI.  So yes, modeling things on the 
current "Scripts&Windows" dialog makes sense.

    
    

    
  
> Yes, but the VB is a list of variables for a bunch of programmers.  

Yes, I know that, I was just pointing out how it was done.  Have a list with 
selectable dropdown boxes.  You can also see the same thing in the message 
compose dialog in mozilla.  Select To: Bcc: or cc: and then the email address.  
Just flip that around, so you see the preference to block, and you get a 
dropdown to select Allow/Deny

Does modern use the horizontal/vertical lines in the message compose dialog box? 
 Classic has a light blue coloured grid which looks fine.

    
    

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

    
    

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

    
    

    
  
Something like IE with drop-down lists instead of those radios would be ok. But
something is still missing then. The policies allow to define every javascript
object, i think.
The average Joe user will be happy with some standard options for popup windows
and status bar text. But everyone else might want to use also the other
features. OK, maybe they are smart enough to configure them by directly editing
the prefs file.

Some kind of "Add Option" feature would be nice. I already have some policies
using more features then available in the UI at the moment. So I would need such
a feature. I don't think a beginner would be more confused by such a button than
by a "Customize" button for IE's standard zones.

But another question: Will any average Joe user ever use a complex and powerful
zone-policy thing like this? For them the actual "Scripts & Windows" is great.
Anything with zones maybe to complex as it is (How many of them every touched
IE's Zone configuration without being advised to because of security reasons?).

So maybe there have to be one step before. Something like "Scripts&Windows" (for
configuring the default-policy) and an "Advanced rules" with all those stuff we
are actually discussing. Maybe it's too complex then. Maybe it's impossible to
realize. Was just a thought coming up to my mind :-)

    
    

    
  


  
Here is a more fleshed out version of what I was thinking for the setting of
the policies.  Select a zone in the first dialog, then press edit or customize,
then this window would popup.  You get a list of all the things you can change
and little dropdown boxes to select what you want it to do.  At the top, it
tells you which "zone" you had selected.

I think this is better than a checkbox because there can be more than 3 choices
and those choices can vary (Maybe not right now, but in the future).

If someone selects deny on say javascript, all the other preferences should be
automatically disabled.  I showed this in the screenshot when they selected Do
not allow popups.

    
    

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

    
    

    
  
I was thinking about that, all of the options below Javascript could be indented 
and Allow popups on load and unload could be indented in one more level because 
it is really a child of allow all popups.

Can you allow popups on load and unload but not allow all other popups?  Useless 
I know, just wondering :)

    
    

    
  
> Can you allow popups on load and unload but not allow all other popups? 

Not with the current back end.

    
    

    
  
Hm. And maybe instead of just put the zones name above you could use a drop-down
box instead. So one can easily configure multiple zones without having to do
some "OK -> choose zone -> Edit" procedure every time.

    
  
QA Contact: sairuh → junruh

    
    

    
  
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.

    
  
Status: NEW → ASSIGNED

    
    

    
  
>Can you imagine putting such a long-winded phrase on the buttons?
>[Add Javascript Permission Levels]
>[Edit Javascript Permission Levels]
>[Delete Javascript Permission Levels]

I can imagine 
*Site Permission Groups* or *Site Permissions*
New Group
Edit Group
Delete Group

That is 1 additional letter compaired to Zone and also "neutral" (ie not
specific to JS).

>Isn't there an all or default zone for setting up your global options?  If not,
there should be, for URLs not matched by the other zones.

Indeed there must be definable default/global setting, which the individual
group permissions should override.

>I do argee that we'll need an Advanced... button, as some of this stuff is
entering the realm of non-Joe.

I'd rather see an "Enable advanced options" checkbox.
When enabled the "advanced" features appear together with the rest, and not in
some other menu/window.

> The main screen would have the URLs, and the secondary would have the options,
both with ways to select the zone.

Sounds good to mee too =)

    
    

    
  
> I'd rather see an "Enable advanced options" checkbox.

You mean <disclosure /> widget right?  (Once that works)


    
    

    
  
> You mean <disclosure /> widget right?  (Once that works)

Say again?  Sorry, not versed in X programming.



    
    

    
  
<disclosure />, once it exists, will give a way to click a button and have new 
content that was hidden before appear.  Similar to "Advanced" toggles on many 
dialogs in Windows, eg.

    
    

    
  
Yes, that is exactly what I mean (just lack the correct vocabulary to express :)

Since I'm "spamming" anyway, I'd like to comment a bit on the latest suggested
config box/window
( http://bugzilla.mozilla.org/attachment.cgi?id=63290&action=view )

I think the idea behind how it's done is good, but the graphical appearance
should be reworked to better fit with what is already there in Mozilla.
Nowhere in the entire UI is there anything even remotely similar to such a
compact "VB" layout.

I suggest the graphics should drift a bit more towards how eg the messagefilters
look. Ie less squareness, no horizontal lines and perhaps even some space
between the buttons/selectlists.


    
    

    
  
> Nowhere in the entire UI is there anything even remotely similar to such a
> compact "VB" layout.

Not in the preferences but the message composer. Look at the lines where you put
in To: or Cc:. This is the reversed version of the last UI suggestion. Maybe
you're right and the conventions of Mozilla's _preferences_ style should be
used. But there we won't find anything really useful to what is needed here (Can
the Message Filters be seen as "preferences" as they are optically seperated?)
I just think the actual version is very space saving if you compare it with a
version containing a message filter like list.

Nice that we are that far to discuss purely optical issues :)

    
    

    
  
Previously stated options:
JavaScript
Popup windows
Popup Windows on load and unload
Move the browser window
Resize the browser wondow
Make windows popup/under others
Change the status bar text
Change Images (Image rollovers)
Create or change cookies
Read cookies

Other options which could be added:

Allow the web page to scroll itself 
  self.scrollTo(0,20);
  self.scrollBy(-5,30);
Allow the web page to know what browser I'm using
  navigator.userAgent
  navigator.appVersion
  navigator.appName
  navigator.appCodeName
Allow the web page to see what operating system I'm using
  navigator.platform
Allow the web page to see what plugins I have installed
  navigator.plugins[index]
Allow the web page to see what resolution I'm running
  screen.width
  screen.height
  screen.availLeft
  screen.availTop
  screen.availWidth
  screen.availHeight
Allow the web page to see how many colours I am displaying
  screen.pixelDepth
  screen.colorDepth



Is it possible (I have a hunch it's not), in the back end, to force all 
"untrusted sites" to use my predefined colours, yet have all others use their 
own link colours?

Can the policies stop these (when a page opens a new window, force it to have a 
menu bar and status bar)?
self.menubar.visible=false;
self.toolbar.visible=false;
self.locationbar.visible=false;
self.personalbar.visible=false;
self.scrollbars.visible=false;
self.statusbar.visible=false;

And one more thing.  Wouldn't it be best if prefs not on the list were set in an 
editable version of about:config (Bug 110090)

    
    

    
  
> Can the policies stop these [disabling menubars and the like]

Should be able to if you find the classnames for those objects.

> navigator.userAgent

Bad idea, IMO.  Setting something to noAccess makes script execution completely 
stop when access is denied (unless the script writer uses try/catch, which is 
never the case).  If there is a preference for disabling things like userAgent 
and appName on this panel, there had better be a big warning that this will 
break almost every dynamic site out there.  We already have this problem with 
the window.status blocking pref... see bug 117707

    
    

    
  
BTW, this stuff ain't UI.  Again, our helpful Boris has bug links on comment #93.

    
    

    
  
*** Bug 119692 has been marked as a duplicate of this bug. ***

    
    

    
  
WRT Boris's comment #126, we should have a way to suppress annoying content
without throwing an exception and stopping script execution. That's the
difference between security and content filtering - they're really two separate
feature sets. I have filed bug 122866 on this issue.

    
    

    
  
*** Bug 125923 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 137377 has been marked as a duplicate of this bug. ***

    
    

    
  
Is all of the back-end in place for this? I've been waiting on this for quite a
while, so it seems the only good solution is to work on it myself. Is there a
place to store the prefs for this besides prefs.js? I guess that is a separate
issue from  this bug.

    
    

    
  
All the back end is in place for this, and the prefs go in prefs.js

    
    

    
  
Sorry, I've allowed my patch to become out of date.

    
    

    
  
*** Bug 118602 has been marked as a duplicate of this bug. ***

    
    

    
  
What about adding the mozilla1.0 and nsbeta1 keywords here ?
btw, I really like http://bugzilla.mozilla.org/attachment.cgi?id=63290&action=view

    
    

    
  
*** Bug 145316 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 146370 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 149537 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 153301 has been marked as a duplicate of this bug. ***

    
    

    
  
I notice that bug 11707 has changed the Scripts & Windows panels to use a new
set of preferences, describing the old way of doing things as "just BROKEN!"
(comment 10) and meaning that we don't have a back-end any more for
site-specific policies (comments 86,87).

    
    

    
  
Sorry, I meant bug 117707

    
    

    
  
*** Bug 154799 has been marked as a duplicate of this bug. ***

    
    

    
  
Looks like someone has developed an XPI for this at
http://www.cc-net.or.jp/~piro/xul/_policymanager.html

    
    

    
  
*** Bug 156885 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 157436 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 150872 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 159925 has been marked as a duplicate of this bug. ***

    
    

    
  
Some sites use popups for advertising and on other pages, popups that can be
useful (e.g. identification). So, there should be a more flexible way to block
popups, in particular, capability.policy.allowpopups.sites should be extended to
allow particular web pages (and not only web sites) to use popups, or any prefix
of the URL for instance. AFAIK, this would be simpler than a more general
blocking mechanism, thus I hope that it could be implemented earlier.

    
  
QA Contact: junruh → sairuh

    
    

    
  
*** Bug 160647 has been marked as a duplicate of this bug. ***

    
    

    
  
Why not just a function that give you the possibility to rightclick on the
pop'ed up windows and then choose "Block popups from this server".

(or "Block popups with this URL", for a less general blocking).

    
    

    
  
Regarding comment 151, I would prefer to see the opposite situation. I would
like to block all popups by default, but then would like to right click and
choose "Allow popups from this site."

    
    

    
  
Me too. In my configuration, I block popups by default, and I don't want to
change this. Methods to unblock popups should take that into account.

    
    

    
  
I also would prefer a mechanism where I block all popups and can unblock
specific sites/URLs.

Maybe there should also be a small icon (e.g. on the lower right of the browser)
indicating when a popup is blocked.
So you would be able to aware that a site doesn't work because a popup is blocked.

    
    

    
  
and clicking on the icon could unblock the popup (temporarily or permanently,
perhaps depending on what button has been used).

    
  
QA Contact: sairuh → bsharma

    
  
Depends on: 150872

    
    

    
  
Marking bug 150872 as blocking this bug, based on coment #6 in that report.

    
    

    
  
Matthew Wilson is gone, right? So why is this bug, the only one, still assigned
to him?
Assignee: matthew → ben
Status: ASSIGNED → NEW
QA Contact: bsharma → sairuh

    
    

    
  
Well, I'm still here, but I'm not working on this, I found a much more
functional version than my patch (see comment 144)

    
    

    
  
*** Bug 192667 has been marked as a duplicate of this bug. ***

    
    

    
  
From 
http://www.mozilla.org/projects/security/components/ConfigPolicy.html
read current way of setting policy is by as following line in prefs.js 
  user_pref("capability.policy.policynames", "strict");
  user_pref("capability.policy.strict.sites", "http://www.evil.org
http://www.annoying.com");
  user_pref("capability.policy.strict.Window.alert", "noAccess");

This option wont allows us to have some pages of a site to show alert and others
not. 

If we can get a Java Script function called to determine the URLs "policy name"
it will be a great help.

Function should receive an argument, as pages URLs and return a string with a
value as policy name.

    
    

    
  
*** Bug 207196 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 222678 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 223798 has been marked as a duplicate of this bug. ***

    
  
Blocks: majorbugs

    
    

    
  
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.
Product: Browser → Seamonkey

    
    

    
  
*** Bug 277160 has been marked as a duplicate of this bug. ***

    
  
No longer blocks: majorbugs

    
    

    
  
*** 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.
Alias: BlockJS

    
    

    
  
since there is implementation of zones (pref-policies.xul) why not review it for usability and bake it on the trunk?

    
    

    
  
*** Bug 358113 has been marked as a duplicate of this bug. ***

    
    

    
  
[sg:want P3] - this refers specifically to letting users whitelist sites on which they want to allow JavaScript.  Many users would like to disable JavaScript for security reasons (it's a great way to protect against yet-to-be-discovered browser security holes) but can't because they use a few sites that need JavaScript.

The NoScript extension provides UI for whitelisting sites for JavaScript and is the 6th most popular extension on addons.mozilla.org.
Whiteboard: [sg:want P3]

    
  
Assignee: bugs → prefs
QA Contact: bugzilla

    
    

    
  
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs

    
  
Blocks: 436934

    
    

    
  
Any news about this bug?

    
    

    
  
With presence of Data Manager in current SeaMonkey versions, is this bug still actual?
Whiteboard: [sg:want P3] → [sg:want P3][2012 Fall Equinox]

    
    

    
  
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?

    
  
Depends on: 1258295

    
    

    
  
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.
Status: NEW → RESOLVED
Closed: 24 years ago → 8 years ago
Keywords: helpwanted
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: