The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

How on earth can closing a window be any greater a security risk than creating one?
For that matter, how is closing a standard window any greater a risk than closing a popup window or a window opened with target="_blank"?

How does someone 'close a browser window' maliciously?

The Mac platform seems to have resisted pretty well the hoards of hackers despite having such enormous 'security flaws' as allowing this feature to be used consistantly regardless of how that window was created.

For some reason, I simply can't credit 'window.close()' with the capability of becoming the hackers new best friend.

It was designed specifically to be a security thing in ie.
If there is only one url in the browser history - the window would close without prompting. Otherwise it assumes that you're not in control of the window.

I'm not sure why Mac decided this needn't be the case.

note that calling the window.close() on an HTML application (HTA) - will NOT prompt - because an HTA is a trusted source.

I'm not sure of all the implications and ways you could exploit this - but i've read several articles over the years which went through good reasoning for the logic.

I'm not sure that this is the answer you wanted - but to be honest i'm struggling to think of examples right now - my mind's on other things

Users become suspicious and distrustful of software that do things behind their back - spyware apps that track user movements or send private documents back to HQ, ActiveX controls that install themselves and reconfigure your dialup networking settings (rerouting your calls through a $10/min phone line in Russia), and software that "phones home" to check your serial or for updates without asking...

Browsers, being windows into the WWW need to be trusted by the user, and protect him and his computer from malicious software, so there is a standard security model which is designed to do just that, and restrict JavaScripts from doing certain things - for example, scripts aren't able to change your homepage URL without causing a user prompt, nor can they add themselves as a favourite without asking.

Another of these restrictions is to prevent windows from closing windows that they haven't opened themselves. This is because it is assumed that if a script within a given window opens a new window, it is safe for it to close it again. However, if scripts had the abiity to close other windows which it had not itself opened, then there are many ways that this behaviour could be exploited to annoy the user.

Here's a couple off the top of my head...
1) A page could close all other windows apart from itself

2) A page on one company's web site could close any windows which contained its competitors' web sites

3) A malicious popup could use the onMouseOver event to spawn a new copy of itself somewhere else on the screen when a user moved over it and then close itself down, thereby evading a novice user's attempts to close it down (you could of course still close it via the taskbar).

Now I'm not saying that this is a MAJOR, life threatening vulnerability that could be exploited to actually cause harm to a user's PC, but it could be used to bring about events that would irritate the user, and possibly affect the user's enjoyment of other web sites. It simply would be (and currently is) one more tool in the malicious coder's armoury...

The Mac platform seems to have resisted pretty well the hoards of hackers despite having such enormous 'security flaws' as allowing this feature to be used consistantly regardless of how that window was created.

Originally Posted by Bill Posters

How has the Mac platform been adversely affected by the freedom it enjoys in this respect?

I don't use Macs and don't read Mac-related web sites, so you'll have to check those out for yourself, but I suspect that since only <5% (a guess) of the world's PCs are Macs, malicious script coders simply haven't been bothered to target them specifically...

So, in essence (if not fact), there's no "security" issue at all, then- just a nuisance one.

Just as I thought.

Hopefully now you'll stop overstating the problem by selling it as a security risk and thereby creating unnecessary concerns in cases where common sense practice and user-friendliness is the issue.

Re: Mac.
Even at 5% it's likely that many malicious scripters would have focussed on the mac as an 'easy target' if the closing windows thing was the kind of issue you say it is.

I think much of the problem is what we assume from the term 'malicious'.
To me that implies real hacking scripts by those hoping to wreak real havoc or damage or hoping to gain access to something private and confidential.
I wouldn't elevate the closing of windows to ebing anything worse than stupid nuisance or off-putting. There are plenty of those sort of things in use on websites today that will stop me returning to a site. Whilst they are a temporary, one-off p.i.t.a, I wouldn't call any of them security risks.

If you look earlier in the thread, I had meant to refer to it being part of the JavaScript security model, but had omitted the word "model" out of the sentence, which perhaps gave rise to some (understandable) misinterpretation...

Another thought here. If it was possible to close a window - ie the parent window and not popups - it would be possible for some one to plant a javascript to close a top level document on load thus stopping people viewing a website 8)

They'd need to hack past a firewall proberly though this has been known to happen before they could change/upload the modified webpage, no ?

We need this ability to stop javascript closing the parent window - it's there for our protection and anything that bypasses this is bad 8)

In the end you do not mess the user about is what I'm saying I suppose, right ?

Another thought here. If it was possible to close a window - ie the parent window and not popups - it would be possible for some one to plant a javascript to close a top level document on load thus stopping people viewing a website 8)

Presumably this would only occur once the user has visited the second website (i.e. the one that contains the javascript).

The facillity to close the current, other or opener windows without question neccessarily means that the page containing the window.close()or opener.close() script would be either closing itself or closing the page containing the incoming link.
In the case where it is closing itself, surely it cannot be deemed malicious to close one's own site window.
In the instances where 'site A' links (via '_blank') to 'site B' which then closes the window containing 'site A' it would be prudent of 'site A' to remove links to the latter.

---

If I was to visit a site that closed windows containing other sites (possibly with competing content) then I would simply not visit the second site again.
I think by creating the alert for all instances of a certain nature it only serves to obstruct those who may wish to use the feature for legitimate reasons.
As a veteran mac* user I've yet to visit a single site that has used the opportunity 'maliciously'.
(* mac doesn't question the closure of any windows whatsoever)
During my intermittent forays into PC/Win use, I've only ever experienced the closing window alert as a nuisance that interupts the flow of my workflow/browsing.

They'd need to hack past a firewall proberly though this has been known to happen before they could change/upload the modified webpage, no ?

Hacking is hacking and should be dealt with as a threat in itself without creating barriers towards legitimate uses of commonplace functions.

We need this ability to stop javascript closing the parent window - it's there for our protection and anything that bypasses this is bad 8)

You already have the ability to prevent parent/opener windows from being closed. You simply disable javascript in your browser prefs.
If you find you appreciate certain javsacript functions but not others then surely it would not be too hard to implement discressionary javascript disabling in the same way as non-IE browsers (and 3rd party tools) can be set to prevent automatically-triggered popups, whilst allowing manually-triggered popups.

What we "need" should be up to the user, not the browser developer.
The point I'm making is that closing parent windows is obstructed by default.
It should be handled in the same way as popups are increasingly being handled.

In the end you do not mess the user about is what I'm saying I suppose, right?

And what I'm saying is that we should have this simple facility made available to our sites. It should be used at 'our' discretion (taking into consideration the likely un/popularity of its use) and either permitted or prevented according to each user's individual preferences.

All I ask/expect is that site authors and site users are allowed to make these kinds of lasting (but reversible) decisions for themselves (via the browser's prefs) rather than having MS force the question on them every time.

Anything that gets in the way of the users' individual preferences is 'messing the user about'.

(Given that absence of native popup blocking prefs in all versions of IE and the shoddy implementation of other web technologies in IE/Win, I'm not overly convinced that MS place any greater emphasis on their users' choice than those who may use window manipulation scripts maliciously.)

The bottom line is: offer the choice to accept or prevent window closures to the individual as a user preference. That way the site author gets the opportunity to provide their site experience in its 'ideal' form and the user still gets the final say.

Surely this would be (a darn sight closer to) the perfect solution for everyone.

Most home users wouldn't know the first thing about what options to set, so even if the options were there, the defaults would need to be set to what we have in IE now.

Furthermore, as we all know, coding JavaScript is difficult enough as it is already - having to detect which JavaScript/CSS/DOM capbabilities the client has - without adding yet more options which may or may not be enabled and would need to be handled in scripts.

Therefore, I don't see this being very practical (or desirable, from a developer's perspective) to implement and think that the current approach works fine.

In PC IE I could have my site change your default homepage to my page which automatically closes itself. Therefore whenever you run IE it closes itself.

This is different on Mac IE because if the window closes itself the application is still open and I can just change my default page in preferences. Plus I don't think Mac IE allows a site to change your default homepage.

Maybe this is why they implemented a prompt on closing a parent window.

...Maybe this is why they implemented a prompt on closing a parent window.

So, in essence MS has implemented one problem and then used an inflexible condition to address the 'side-effects' created by the problem.
Why not implement a better model to begin with such as that used by Mac OS? The thinking in favour of MS's approach can only be described as skewed from the outset.

As mentioned, the closure of the last remaining window does not close the app on a Mac. If the closure alert in Windows is meant to address the fact that apps are closed when the last remaining window is closed*, then surely implementing the Mac OS model would provide a better 'please everyone' solution than its own.
(* a model I've always found not only pointless, but also extremely frustrating in practice)

You never hear Mac users complaining about the 'issues' raised by the MS apologists here. There's a good reason for that.

The facility to automatically add a page to the favourites or even as the default homepage are both 'real' user-unfriendly practices that are more deserving enemies of user-friendliness than the window closing 'issue'. And yet, despite their frequent abuse, they are still permitted (notably exclusively!) by IE/Win.

Most home users wouldn't know the first thing about what options to set, so even if the options were there, the defaults would need to be set to what we have in IE now.

The popularity of Google bars and popup blockers demonstrate that users are already delving into browser customisation en masse.
Given the popularity of changing desktop wallpapers, icons and screensavers amongst even the most basic level users, we can presume a sufficient level of awareness of customisation features.

Given that users are capable of disabling cookies, javascript and plugin content (as we are so often reminded by usability/accessibility 'gurus') then it is surely within their capabilities to set one more preference with regard to their browsing experience.
Let's not forget that many users prefer browsers other than Internet Explorer precisely because they offer the customisation features they want.

The 'ignorance' of the user is looking a little threadbare as an argment in favour of the status quo.

Offering the choice would at least be a start.
I'm in favour of having such a pref set to allow windows to close without warning by default. In the absence of a user preference the author's preference should be given its chance. (I feel similarly towards the default-'on' bias regarding MSIE's 'focus border'.)

Frankly, I'm sick and tired of this attitude that says we cannot do anything they may require that users engage their brains for even a second.
You may prefer the notion of working towards perpetuating the 'ignorance' of users, but I personally would rather see them given the choice of how their OS and browsing experience is handled.
It may be too much to hope for that users will universally be expected to use their brains from time to time, but I'd at least appreciate the opportunity to offer the choice to those who already have looked into the OS/browser prefs panel.

Furthermore, as we all know, coding JavaScript is difficult enough as it is already - having to detect which JavaScript/CSS/DOM capbabilities the client has - without adding yet more options which may or may not be enabled and would need to be handled in scripts.

Nonsense on both counts.

From a website author's perspective- why would we need to do anything to pre-assess the DOM capabilities of the user agent?
We'd simply implement the basic window.close() script and let the browser handle it according to the user's prefs.
We, as authors, don't need to code anything differently to how we are coding now.

From a user's perspective- popup blockers are the most popular 3rd party browser tool being downloaded from software download resources.
Native popup blocking is a facility that many users cite in their particular browser choice.
It seems that a great many users are perfectly capable of obtaining, installing and implementing a customisation tool that improves their browsing experience.

Therefore, I don't see this being very practical (or desirable, from a developer's perspective) to implement and think that the current approach works fine.

Given that Internet Explorer is the only major browser without any form of native popup blocking (or any other discretionary javascript customisation) I doubt strongly that practicality and developer capability is the issue.
Given that IE is becoming increasingly marginalised with regard to its feature set I'd also say that your statement about 'desirability' is also a red herring.

---

As said before, the bottom line is that the choice does not exist. While the choice does not exist those users who would prefer to have windows closed without interuption are being 'messed about' by MS's unilateral inflexibility.