The Internet Explorer pop-up blocker follows guidelines, not rules

Here's a question that came in from a customer (paraphrased):

Hello, we are developing an ASP.NET application and are running into problems with the pop-up blocker introduced in Windows XP Service Pack 2. Where can we get a full description of the rules that control whether a pop-up will be blocked so we can make sure our pop-ups are let through?

There is no full description because that would make the pop-up blocker useless. Suppose a formal description were available. Somebody studies the formal description and finds a loophole in the pop-up blocker and exploits it. (Indeed that is precisely what this customer is trying to do!) The browser team finds the same loophole and tries to plug it. The exploiter says, "Uh uh, according to your formal description, the XYZ technique avoids all the checks and therefore must not be blocked." A bug has become a feature.

What you do have is a guiding principle: "Pop-ups are allowed if they were triggered by an explicit user input." For example, if the user clicks a button or link, you can display a pop-up in response to that click. React to the click when it is clicked. The click isn't a coupon you can save and then spend later. You have to do it when the click happens.

Consequences of this guiding principle:

  • Don't "forward" the click through redirects. Again, the browser won't necessarily make the connection between the redirect and the click.
  • Don't set a timer and then display the pop-up later, because the browser won't necessarily make the connection between the call to from your timer and the user click action from long ago. (Arguably, the user won't make the connection either!)

The point is, you get your chance when the click happens. If you blow it, then it's gone.

If you are implementing an ActiveX control, you need to make sure to forward QueryService calls through your site chain so that when your control decides to perform a navigation, the navigation object can connect back to the web browser's pop-up blocker to determine whether the navigation should be allowed or blocked.

In the future, new rules may be invented to plug additional holes in the current implementation, but the guiding principle will still govern. Stick to the principles and you'll be fine.


I reiterate that the reason for not disclosing the "official rules" is not for security reasons. (Indeed the word "security" never appears in the article.) The reason is that making the rules official means that you can never change them. And the IE team wants to reserve the right to change the rules. Notice that the customer was looking for a guarantee that their pop-up algorithm will always be permitted in current and future versions of IE. In other words, they wanted a promise that the rules would never change.

Some people have mentioned that Firefox has disclosed their rules for pop-up blockers. Has Firefox also promised never to change their rules? What happens if Firefox makes a change, and a site that used to be allowed is now blocked? Can the site sue Firefox for violating its own rules?

You can find loopholes in even the simplest rules. "If the user physically clicks the mouse button over a link element that is enabled, visible, and all that good stuff, and the link is marked to open in a new window, then it will open in a new window." Sounds like a pretty fair rule, but are you willing to guarantee that this behavior will always be permitted in all future versions of the Web browser?

I'm glad you think so, because there's a loophole in that rule. But since you made the guarantee, you can't close the loophole.

Comments (52)
  1. Vic says:

    And have all sites that use popups get through the blocker, making it useless?

  2. Firefox is open source and has a popup blocker.  I wonder how many people use the source to find work-arounds.

  3. Mike Diack says:

    Dwayne is dead right. “Security through obscurity” has not been a raging success for Microsoft thus far and I’m certain that a competent reverse engineer could figure out the algorithms anyway, making the idea of keeping it secret to keep it secure entirely moot.

    I’ve seen several instances of both IE and Firefox not blocking successfully, so clearly neither is perfect.


  4. Nathan says:

    @Mike, you want your cake and to eat it.

    You’re saying "because popups get around IE, it must be a bad blocker."

    Yet you want to require IE to document (and thus codify) how it’s blocking works. Ray’s point is that by doing so (for that customer), MS is locked into never improving their popup blocking because to do so might break REALLY-IMPORTANT-CUSTOMER Y’s application that relies on sneaking around the way the popup blocker works.

    MS carries enough cruft in the OS for compatibility, and Ray’s documented plenty of it here.

  5. Kip says:

    "MS carries enough cruft in the OS for compatibility, and Ray’s documented plenty of it here"

    Helping Raymond out here… nothing on this site constitutes official documentation from Microsoft.

  6. Daniel says:

    I believe there is a very simple solution for the customer request: if their pop-up are really useful for the users, they should have no problems in convincing the users to turn off the pop-up blocker for their site (both IE7 and Firefox allow  exceptions for the pop-up blocker, not sure about older IE and other browsers).

    Anything else is just a pray in the dark. The user should always have the final saying in pop-up blocking.

  7. CGomez says:

    I believe this is being wrongly confused as being a security issue.

    This isn’t about exploiting the pop-up blocker to gain privilege.  It’s about cheating the pop-up blocker’s intent.

    Microsoft implements a pop-up blocker to try and prevent unwanted and annoying pop-ups.  by providing guidelines, they are saying "Here’s how you can make sure your important and useful pop-ups can still be allowed." (assuming the user does not have High blocking on).

    If the algorithm used to decide whether to block a pop-up HAS TO CHANGE, then they can do so… still following the guidelines they laid out in the first place.  To make hard and fast rules simply means they’ve created a compatibility constraint that can’t ever be changed to keep up with the spirit of the pop-up blocker.

    This is incorrectly labeled as a security issue.

    "The user should always have the final saying in pop-up blocking."

    The user does.  I set my pop-up blocker to High… blocks all popups.  Seems like more than enough final say.

  8. Jess Sightler says:

    I don’t buy it either.  There may be reasonable reasons not to disclose the method used, but not being able to change them is a really bad reason.  Firefox doesn’t really have a choice, since the code is avaialable anyway.

    Whether it is documented or not does not affect whether it is subject to change.  In some ways, its easier to document that something IS subject to change than it is to never say anything and let the user assume one way or the other.

  9. anonymous says:

    I really don’t get it why they put the popup blocker there in first place, since it’s trivial to circumvent:

    • Install malware through the obvious security design choices^W^W "vulnerabilities" in IE.

    • use MessageBox() and alikes

  10. Dusty says:

    @Mike and Dwayne:

    I think that you are missing the entire point of the post.  The problem is not that the pop-up blocker functions better or worse because you don’t know the internals.  It is that the developers of IE wish to reserve the right to change the way it functions in the future.  And if they were to post documentation on how it works they have effectively established a contract on how it will work in the future.  This is different from "security through obscurity".


    So you are saying that it would be okay to read MSDN documentation about a feature and have the feature function differently?

  11. David Walker says:

    Thanks, Raymond, this is a very well-written and easy to understand description.

    I like the comment that a click is not a "coupon" to be saved and spent later.

  12. zzz says:

    If only I could define some sites to use tighter setting than others. The blocker works fine most of the time but few popular sites make you click to get X and then use that click to give you Y as a pop up.

    This is mostly an issue for IE users as the site stays popular because Firefox etc users have better ability to block the popups and thus keep using and keeping the site popular regardless of it’s ill behaviour in IE.

  13. Simon says:

    A few years ago, official documentation stated that will open a window. Nowadays it doesn’t.

    Things change.

    Document it and change it in the next version if you want to.

  14. AdamT says:


    Well said!  I hate pop-ups.  What really annoys me is a site like where I actually can’t choose ‘Open in new Window/Tab’  I have to click on the javascript pop-up link to see details of the car.

    One thing that would be really nice to have on the context menu of a browser would be ‘Open in THIS Window’.

  15. JenK says:

    Popup blockers should be able to block ALL popups. I care about my own browsing convenience, not the "needs" of web developers. I don’t think I’m uncommon in this way.

    And yes, I like the line "The click isn’t a coupon you can save and then spend later."

    (FYI, most of my company’s web clients want their sites to work in IE and aren’t willing to pay for me to also test in Firefox. So I use Firefox for reading newspapers and IE for work. Firefox’s popup blocker is NOT perfect either.)

  16. bd_ says:

    Hm, the loophole is that the new window can be a popup ad, and there can be an onclick script to set window.location to the page the user intended to go to. Right?

  17. John says:

    That sounds like a garbage excuse.  Surely over the past 20 years Microsoft has documented some behavior that was later changed, right?  If so (and I am positive it is so), I think your argument is without merit.  Either way, what’s wrong with documenting the (changes in) behavior for each release?  Then when a new release comes out they can document the changes (if any) in behavior.  What is so hard about that?  That’s the method that basically every software development house on Earth uses.

  18. Ulric says:

    The tons of commenters above miss the point:

    this isn’t about not documenting how the popup blocker works,

    it’s about not fully and precisely documenting when it DOESN’T work.  

    The guidelines are documented: popups are accepted when they are user-initiated.

    Are there times when this system fails due to implementation?  Not documented.

  19. fdiv says:

    RC: "Can the site sue Firefox for violating its own rules?"

    Thank you for asking. I can think of several things that would happen:

    1. A workaround would be published in no-time to help users of the site.

    2. The lawsuit would be (humorously) ridiculed on /.

    3. The lawsuit would be (intelligently) ridiculed on Groklaw

    4. /. would post about Groklaw (commenters scream dupe)

    5. …Time passes on…

    6. Mozilla wins the case (the cheering, though definately present, is nothing but another noise in the background)

  20. Marc K says:

    It sounds, to me, like Raymond answered the customer’s question fully with "Pop-ups are allowed if they were triggered by an explicit user input."

  21. Karellen says:

    Just a thought, could the IE team do it the other way round and list the circumstances under which a pop-up should be guaranteed to pop-up? Like the guiding principle, but a bit more rigorous. Then, say that IE’s pop-up behaviour in any other circumstance is version-dependent (equivalent of C’s “unspecified” behaviour) and may be subject to change.

    White-hats get a list of ways they could do what they wanted, and the IE team are free to add more items to the list in future to *increase* the number of things that work.

    (Presumably the team would add to the list after having had the method “unofficially” work in IE for a while, giving them time to evaluate the behaviour and get advice or feedback from security types/grey hats/other browser vendors?)

    Or does that run into the same problems as listing disallowed behaviours/complete algorithm?

    [It’s the same problem. Somebody will find a loophole in the “guaranteed pop-up” rules. -Raymond]
  22. Dwayne says:

    “Suppose a formal description were available. Somebody studies the formal description and finds a loophole in the pop-up blocker and exploits it.”

    Raymond, it sounds like you’re making the same excuses that we too often hear from cryptographic snake-oil salesmen.  Why wouldn’t Kerckhoffs’ Principle apply to popup blockers?

    Heck, the free-software browsers that *introduced* the concept of popup blocking have never needed to hide how they work.  Why should IE?

  23. steveg says:

    It sounds, to me, like Raymond answered the customer’s question fully with "Pop-ups are allowed if they were triggered by an explicit user input."

    Such as adding to the list of sites allowed to create pop-ups. If the user needs to have those pop-up windows, they can. If they don’t need those pop-ups, then the design is flawed.

    And I’m pleading stupid. What’s the flaw in the rule Raymond postulated?

  24. Dave says:

    Lacking formal documentation, users are reduced to using the current behavior as the documentation and building those assumptions into their apps. Then a future blog will complain that users used undocumented behavior–of course they did, it’s all they had.

    For example, IE7’s popup blocker will block *all* popups (even ones responding to user input) when set to High. At the moment IE7 does not block window.alert() or window.confirm() calls, even when set to High. I use this as a safety net by checking for null and doing an alert() that their blocker is set to High. However, I realize actions like this can only embolden the terrorists, so I apologize.

  25. AdamT says:

    Much as I like Firefox (using it to post this message), I have to side with Raymond on this issue.

    There’s a fine line between security through obscurity and not revealing the exact inner workings of your application for fear that miscreants would misuse it.

    Anyone who doubts this should contact various Anti-Virus vendors and ask them for their heuristic scanning algorithms.

    Also, to quote Raymond himself, it’s not ennough to say that X is bad, you have to say what would be better.  I doubt that revealing the exact subroutine would make the world a better place.  If this were to be done, and every site with more concern for revenue than usability decided to start flooding the web with pop-ups, how would you suggest IE determine the difference between ‘good’ pop-ups and ‘bad’ pop-ups?  Remember you have to document this and make it available to all.

    Maybe a comment like this…?

    /* If you are a bad guy, please stop reading

    * and delete this file right now.  Thanks.


  26. Leo Davidson says:

    By not guaranteeing anything they’re almost saying that if you want to be sure your site won’t break with future version of IE then you cannot use pop-ups at all.

    Actually, I am 100% in favour of that. I hate all pop-ups. If I want to create a new top-level window (or a new tab or whatever) then *I* will create one using the tools the browser provides me to do so. I don’t need that choice about whether I open a new window or reuse the current window taken away from me and I don’t believe a document inside a document viewer should be able to open desktop objects like new windows.

  27. Andy Simpson says:

    People use the phrase "security through obscurity" so often they forget it’s shorthand for "Security *only* through obscurity is no security at all".

    Obscurity is always useful to have as part of a complete security system. Makes it that bit harder to break if you have to figure out what you’re trying to break is first.

    Security is like building a castle. You build a moat, and walls, and keep. Then you station men on the walls with arrows and boiling oil. Individually, none of them are impregnable, but together they’re a very formidable defence.

    Anyways, Dusty is right on the money. Setting down firm rules then makes those rules inflexible. People will write to them as closely as they can. Guidelines encourage people towards good behaviour.

  28. CornedBee says:

    There is nothing wrong with publishing documentation on the rules – all you have to do, really, is adding a disclaimer that the describes stuff is *subject to change* and everyone stupid enough not to realize this is on their own.

    I see a much more important problem, here: there is just no use in publishing such documentation.

    Publishing documentation on blocking has two possible purposes:

    1) Allow legitimate pop-ups reliable ways to get through. HOWEVER, because of above disclaimer, these ways are *not* reliable, and this use is shot.

    2) Once an pop-up got past your defences, make it easy to track down the reason. Since IE is not open-source, the use is limited: users cannot submit patches to fix the loopholes. At best they can point out in a bug report where the loophole is. Chances are, they won’t.

    The gain is simply not worth it.

  29. Cheong says:

    For Firefox, if there’s some website that worked around it’s popup blocker, you can use adblock plugin to block it. In fact you can even block frames or images that contain advertisements with it. Both mechanisms work together effectively to close any loophole that would exist(requires action of the user, through).

    I hope that functionality could be found built-in in IE too.

  30. Luis says:

    You can write that the specification will certainly change in the future, that it should be  used at the developer’s own risk, that in order to use it you must send a statement signed with your own blood to Microsoft, the US Attorney General and the Pope, and the important client will have no grounds to sue Microsoft (and will use that specification).

    And then, a simple user installs the new version of IE, the application doesn’t work, and whose fault is it (at least for the user)?

    Want to guess?

    "Microsoft and their new faulting version of IE!@!#$!@!". The user complains in his blog, some other user post the article to Slashdot and soon it is a well known fact that the latest version of "MS IE is the biggest piece of waste material since the Edsel!", no matter that the developer accepted the fact that he used a change-prone specification.

    By the way, do you remember when some Malware vendor complained that Microsoft Vista was harming his business by not allowing users to install software by default?

    Nitpickers: faulting version and waste material should be replaced by more colloquial versions

  31. prasun says:

    The loophole is that some sites create pop-ups when a user click was not intended to create pop-ups. For example,  I like to select words or lines while reading and such a click opens ad windows on some sites.

  32. Drak says:

    I can only say I am quite thankful for the popup blocker in IE, and I think it works quite well. We use popups in our products to show progress for certain things, and we can just tell the customer to allow popups from our product site (which is on their intranet, most commonly).

    Seems good enough to me. I don’t believe internet sites can’t get away without using poups except on clicks. Progress bars can be made quite nicely using xml postback (what some people seem to nee to give a fancy name ;) and without the use of popups.

  33. Drak says:


    I think you could build an IE add-in to do that aswell, maybe someone already has?

  34. Mr Cranky says:

    This article reduces to nothing for the following reasons (in no particular order).  

    Documentation is not a legal contract.

    Web developers can cry, kick, scream, and moan, but so what?  They have no standing as IE customers.

    You completely specified IE’s pop-up blocking behavior.  What more could you say, unless you actually intended to code some loopholes?

    You answered the question in the most appropriate way… by publicly ridiculing him.  But for a direct answer, I’d suggest "Only pop-up licensees ($100,000/year), get guaranteed* bypass."

    Firefox’s pop-up blocker works at least as well as IE’s, yet the source is publicly available.  So what are you** hiding anyway?


    *No actual guarantee is offered or implied.

    **Not you personally.  And I realize you’re not an IE developer/designer.  It’s a rhetorical question anyway.  Give me a break, willya?

  35. db48x says:

    I think Microsoft only has this problem because they’ve been so good at maintaining backwards compatibility with previous versions of Windows that people assume that something that is documented will never be changed in the future. Firefox certainly doesn’t have that problem, and yet nowhere in the docs have they had to explicitly say that what they’re documenting is subject to future change.

  36. Triangle says:

    Just make it so that the user can configure wether or not to block every possible kind of popup, and can do so on a per-site basis, and have the defaults be “none on any site”.

    Then you don’t have to document squat, the user gets more control over their machine, the annoying popups can be blocked, and the useful ones can be let through. Everyone wins.

    [There are still losers, such as the Web sites that relied on pop-ups, particularly those that based their business model around it. And as we saw earlier, if Microsoft does something that causes you to lose money, you sue. -Raymond]
  37. Neil says:

    Just say, "The pop-up will pop up if, according to whatever advances in artificial intelligence have been made at the time, the browser believes that the user wants it to pop up."

    And is it pop-up or popup, anyway?

  38. Jonathan says:

    My bank’s online statement site has a section on how to allow pop-ups on its particular domain. This is the correct model of user/site trust: If the user trusts the site and cares enough about the site to bother doing this, the the site should be allowed to issue pop-ups. This is also called opt-in.

    And it seems that the customer is looking for an obligation. Not necessary a legal one, where breakage may result in legal action*. Official documentation is also an obligation, where breakage results in exact documentation of the breakage, providing workarounds for existing customers following the documentation, support for pre-breakage versions for N years, etc.

    The fact that one can look through Mozilla’s pop-up blocker code doesn’t constitute any form of obligation. Reverse-engineering undocumented behavior from the source comes with an inherent no-guarantee – the user of such behavior is well aware that it may change at any moment.

    * IANAL

  39. Ring Zero says:

    Simon said it best. used to open a window, according to the documentation. Now it doesn’t–the IE team changed the rules. I doubt anybody sued MS over this.

  40. Igor says:

    Nag, nag, nag… used to open a window, complete new window with menus, status bar, address bar, title bar, etc which can fit on user screen. Then some nasty idiots decided to start opening windows which have no controls, no feedback and take over the whole screen plus some extra so you can’t move it to reach the close button.

    As that started to happen more and more often, began punishing that user-unfriendly behavior.


    Law says you can own a gun, but if you shoot someone with it, and it is not in self-defense then you can’t own a gun anymore, and you go to jail.

    That doesn’t mean the rules have changed because they were there all the time — it was you who stepped out of bounds.

    All of you open-source evangelists can stick your heads where the sun doesn’t shine — you guys do not have any responsibility towards your customers, actually no one could enforce it upon you, because you work for free so you better shut up about "security through obscurity" already.

  41. Peter says:

    "My bank’s online statement site has a section on how to allow pop-ups on its particular domain. This is the correct model of user/site trust"

    Yes, it is, but unfortunately it’s not the correct model of site design any more. Web designers need to get used to the fact that popup blockers are a fact of life – I dunno what the figures are, but I wouldn’t be surprised to hear that 50% of web users have some sort of popup blocker.

    To paraphrase Raymond, they had their chance and they blew it. Users got sick of being bothered by hordes of crappy popups to make the site a buck, and took back control of it.

    I know that sometimes a popup window is really what you want, but 99.998% of the time I see popup links on the internet it’s not. If I want to keep your poxy site open, I will open a new tab (which incidentally javascript ‘links’ interfere with), but don’t assume you know better than me how I want my windows arranged.

    Strikes me that this is pretty much what’s happened on the desktop; once upon a time applications were trusted to do almost anything. Then they abused it, and now they can’t do things like add themselves to the Start menu pin list. There are a small number of cases where that might be nice, but the overwhelming majority wouldn’t be, so it’s disallowed. Frankly it’s probably lucky for websites that popup blockers have heuristics as clever as they are – personally I could imagine worse solutions than just disabling altogether, although I know Microsoft/Mozilla/whoever would never have gone down that route.

  42. Matthwe says:

    Excellent article Raymond. Its a shame that most of the posters didn’t read it before replying. :)

  43. Igor says:

    Peter said: "…(which incidentally javascript ‘links’ interfere with)…"

    On a side note, this is one of the things where experts writing XHTML 1.0 and 1.1 specification screwed up. They abolished target="blank" attribute and thus forced web designers to use javascript links if they want to be XHTML compliant _and open links in a new window.

    There are many legitimate reasons why web designers would want another window opened.

    The most obvious is to load images from a gallery in a new window so that user can avoid waiting for the browser to recheck 50+ thumbnails when they click the back button.

    Another one is if the link takes you off the site and it has a form. If a user fills and submits that form there is no way back because usually they get "warning: page has expired".

    Everyone keeps telling you "do not break back/forward navigation with new windows" but clearly there are many situations where back button is broken by itself.

    In my opinion there is no need for and I would completely and intentionally break it in next browser version so it returns random number every time.

    target="_blank" should return in XHTML 2.0 and it should be the only allowed way to open a new window. That way non-user initiated popups wouldn’t even exist.

    Moreover, whole that back/forward paradigm sucks because it enforces linearity — that is the way software and computers work, not human brain.

    That is also why I don’t like wizards — if you make a mistake on page 3 (out of 10), you have to go back several times and then forward several times instead of being able to directly access the page you need. It is completely obvious that the user interfaces are designed by complete morons these days.

  44. Medinoc says:

    When talking about the target attribute, I think removing it was a good id, and returning it would be a very, very bad one.

    However, a "defaulttarget" attribute AND an "open to THIS window / open in a new window/tab" menu option pair would be great: The attribute would just change which of the options would be the default one…

  45. Peter says:

    Igor: I disagree, "target" was originally designed for frames, which are best left dead. _blank and cohorts are better than Javascript because you can still open them in new tabs*, but still it implies that the web designer somehow knows better than me where my windows should go. There is an easy way to open a link in a new window – I haven’t seen any browser that provides an easy way to force one to open in the same window if I want it to.

    The gallery thing is an interesting example, and edging towards the 0.002% I mentioned before, but I’d still live with it – most browsers will reload pages instantly on pressing back. I’ve also seen it solved by some witty Javascript, but that does potentially confuse people if they adventure with the back button.

    * I have a Firefox extension that tries to do that for Javascript links, but it only works about 50% of the time – I suspect the other half are too twisted for it to follow.

  46. Igor says:

    Peter said : "I disagree, "target" was originally designed for frames, which are best left dead."

    I was talking specifically about targets with underscore, not the frames. I agree that FRAMESET should die but so should IFRAME, no point in killing one and leaving the other.

    Peter said : "but still it implies that the web designer somehow knows better than me where my windows should go"

    Sometimes they do know better and when they you believe they do not you can always override it by right-clicking on the link and using another action from the menu.

    I am just saying that javascript links are evil by design because designer using them doesn’t leave you any means of control. You can’t override it, and you can’t see where it leads without looking at the source code. By removing target attribute all web designers who want to be compliant are forced to use them. In my opinion using javascript links is just a pointless obfuscation, nothing more.

    Peter said : "I haven’t seen any browser that provides an easy way to force one to open in the same window if I want it to."

    Actually in IE you can drag the link and drop it on the title bar of the same window and it will open there regardless of the target attribute setting, but with javascript there is no way to do it.

    What I am saying is that people should really reconsider target atrribute instead of blindly associating it only with frames (which are bad) and ditching it in favor of javascript links.

  47. Kuwanger says:


    Law says you can own a gun, but if you shoot someone with it, and it is not in self-defense then you can’t own a gun anymore, and you go to jail.

    That doesn’t mean the rules have changed because they were there all the time — it was you who stepped out of bounds."

    Um, that’s a pretty bad analogy.  And I’m not sure you can really make a good gun analogy.  The issue is, can be used for good or evil.  But, enough people were using for evil that Microsoft decided (quite reasonably, I’d say) that it should change to hamper the evil that could be done with it.

    Of course, the people doing good with it might very well become upset because they’re effectively punished for the evil of others.  Relying upon a mechanism that was probably not a good idea in the first place was probably not a good idea in the first place.  If the customer is always right, though, you have to make allowances for the stupid customers.  Perhaps that truth will motivate Microsoft to think harder before introducing stupid features that have to be supported indefinitely for at least some segment of their customer base.

  48. David Walker says:

    I like Neil’s paraphrase of Raymond’s guiding principle:  "The pop-up will pop up if, according to whatever advances in artificial intelligence have been made at the time, the browser believes that the user wants it to pop up."

  49. Hieronymous Coward says:

    @Everyone who says "security through obscurity" is bad.

    I presume you don’t object to the phrase "Your papers, please." Trying to secure your liberty by obscuring your identity is very silly.

    Also, can I have a list of the dates that you will be on vacation? And a map of your house with locations of valuable possessions marked? While we’re at it, can you post your credit card number and PIN codes here?

    (Not that Mr. Chen’s post had anything to do with security.)

  50. Kuwanger says:

    "Trying to secure your liberty by obscuring your identity is very silly."

    Unless it’s a liberty to obscure your identity, which it is.

  51. Igor says:

    Kuwanger said : "Um, that’s a pretty bad analogy"

    Um, that’s pretty good analogy because good people can still own a gun — it is not completely forbidden and it most likely never will be.

    The same thing really goes for popups. They aren’t forbidden for everyone, good people can still call and the windows will pop up.

    Bad people on the other hand can’t own guns and can’t call without being punished.

  52. Kuwanger says:

    "The same thing really goes for popups. They aren’t forbidden for everyone, good people can still call and the windows will pop up.

    Bad people on the other hand can’t own guns and can’t call without being punished."

    So, Microsoft first lets everyone go around and use however they please (but they might have to get a permit first), and if they happen to abuse that liberty, Microsoft bans them from using completely?  No, was changed to prevent many of the bad acts of the bad people (banned all the handguns and machine guns*) and that can end up hurting people who weren’t abusing  The fact that people can create a bubble to reverse that (declare one’s home a soverign nation and allow all types of guns to be used**) doesn’t negate that (gun law) was changed, effecting not just the "bad people" but also the "good people".

    *Not a great analogy, but they’re the most commonly demonized forms of guns.

    **And this is one reason the gun analogy breaks down.  Microsoft isn’t the law, so extrapolating "bans" is incredibly difficult; also, Microsoft does go out of its way to allow for people to counter changes so programs don’t break, while governments are more willing to make sweeping changes that hurt some people because those who are hurt represent a minority (ie, they’re not as strictly driven by monetary considerations).  Now, the externalities of changes and stricter gun laws could be something to compare.  But, that’s merely a small section of the bigger picture.  In short, not everything can be turned into a gun or car analogy.

Comments are closed.

Skip to main content