Closed Bug 36050 Opened 24 years ago Closed 24 years ago

Fix behavior of window.close

Categories

(Core :: Security, defect, P3)

defect

Tracking

()

VERIFIED DUPLICATE of bug 62168
Future

People

(Reporter: kennedyh, Assigned: security-bugs)

References

()

Details

it would be nice if the end-user could control how much access client-side
javascript had to the user's machine:

e.g.

 i'd like to allow updates of window.status and enable rollover menus to work,
 but i would like to be able to say that javascript _cannot_ open new windows,
 and i'd like to set bounds on how much javascripts can allocate resource-wise.

..this would mostly be as a user-side defense against malicious script-writers.

i'm willing to look into doing this myself once javascript is working better in
mozilla, but thought i'd enter this rfe incase someone else has thoughts about
how to do this, if it's even possible, etc.
One for the security guys? Or maybe a DOM0 preference setting?
Assignee: rogerl → norris
Component: Javascript Engine → Security: General
QA Contact: pschwartau → junruh
Already implemented, although we aren't planning to have a UI for the 
preferences anytime soon. 

Look at http://www.mozilla.org/projects/security/components/configPolicy.html in 
particular the use of "window.open".

Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
A place pref("security.policy.strict.window.open", "noAccess");  to stop pop-up 
windows is
http://bolohead.mcom.com/ncryptsvr.htm
Reopening. This does not appear to be working.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reassign to mstoltz.
Assignee: nboyd → mstoltz
Status: REOPENED → NEW
Assigning QA to czhang
QA Contact: junruh → czhang
Nice feature, but not the sort of thing to be adding at this point in the cycle. 
Marking 'Future.'
Target Milestone: --- → Future
Accepting bug.
Status: NEW → ASSIGNED
Need to test configurable security on window.open, etc.
Target Milestone: Future → M18
Reassigning to jtaylor. John, if you haven't yet, could you please write some 
testcases for configurable policies? Try setting default and site-specific 
policies on key properties such as window.open and make sure they're enforced. If 
everything checks out alright, you can close this bug.
Assignee: mstoltz → jtaylor
Status: ASSIGNED → NEW
Adding URL with testcases. First two (window.open and window.close) work, yet 
second two do not. Mitch, do you think a new bug is needed, or just keep this 
open?
Status: NEW → ASSIGNED
-> mstoltz
Assignee: jtaylor → mstoltz
Status: ASSIGNED → NEW
Keywords: nsbeta3
Changing summary. apparently setting some properties to noAccess doesn't work. 
Looking into it.
Status: NEW → ASSIGNED
Summary: [RFE] fine grained control of javascript functionality → Some configurable policies not working
There seems to be a problem with the windowinternal.close policy.

If you do:
w=window.open("http://www.yahoo.com");

Then the security manager won't let you do a
w.close()

because the global variable w is seen as belonging to yahoo.com, and the same
origin check fails. I'm not sure how to deal with this. We could allow
cross-domain access to globals; this is the historic behavior.
Changing description. window.close needs a special security policy (if 
window.opener != self, put up a confirming dialog before closing window, 
otherwise allow). Probably not crucial for shipping, but I'd like a second 
opinion. What do the DOM folks think about this?
Severity: enhancement → normal
Summary: Some configurable policies not working → Fix behavior of window.close
Marking Future as this is an annoyance only, not a privacy or security problem.
Target Milestone: M18 → Future
QA Contact: czhang → junruh
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
Blocks: 32571

*** This bug has been marked as a duplicate of 62168 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → DUPLICATE
Verified DUPLICATE on:
MacOS90 2001-02-13-04-Mtrunk
LinRH62 2001-02-13-06-Mtrunk MOZILLA
Win98SE 2001-02-13-06-Mtrunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.