User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021108 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021108 Guide mozilla over to: http://www.kazaalite.com/ After approximately 8-10 sec. the browser is redirected to a message page at the Anti-Leech.com website informing user that their popups were disabled and thus cannot have access to a webpage. Webpage shouldn't be able to detect that user has popups disabled. Blocking cookies from kazaalite.com and anti-leech.com domain did not solve the problem. Reproducible: Always Steps to Reproduce: 1. Go to http://www.kazaalite.com/ 2. Wait 8-10 seconds. Actual Results: User is redirected to a webpage informing them that their popups are disabled and thus cannot access the webpage, in this case http://www.kazaalite.com/. Expected Results: Disabled popups shoul not be detectable by the page user is visiting and thus should have normal access to the page. If the cookies from kazaalite.com and anti-leech.com are not blocked then going back to http://www.kazaalite.com will immediately yield the access denied message. If the cookies from kazaalite.com and anti-leech.com are blocked then going to http://www.kazaalite.com in the same session is still possible.

To danm. The anti-leech guys detect the lack of a window object returned from window.open....

As a note, I fail to see how we can possibly address this without loading all the content that would go in the popup (which negates most of the benefits of blocking popups).

Boris you make a good point regarding loading the content of the popup. I wonder though if it is at all possible to fake loading content? Main point is to let the server assume content was accepted/loaded but on the client side popup was fully ignored. Ghost popup loading if you will.

> I wonder though if it is at all possible to fake loading content? Not against a determined antagonist (which is certainly what we have here). Eg the script could try to call functions from the newly-opened window or access variables that are supposed to get set in that window and redirect if the functions don't exist or don't return the right thing or if the variable values are not just right... Not to mention setting cookies in the popup and then checking their values. Just faking a window object would fool a casual test, but these guys are making a point of trying to detect popup blocking. We could load all that shtuff and not show the actual window (maybe; I'm not sure we support that architecturally very well), but they you still get issues with cookies just being set, images being fetched, etc. You don't get the annoyance of the actual window opening, but all the other drawbacks of popups are still there... We should think carefully about whether this is a direction we want to go in; I know a lot of people would rather not view the page than have the popups loaded in the background like that. At the same time, bypassing the anti-leech stuff would be nice. ;)

I think going through the full motion of the popup without showing the window itself is rather klunky way of getting this situation fixed. However the points made by Boris can't really be ignored either. I'm going out on a limb here, but could it be possible to creat a temporary sandbox/scratch area for the popup? Let it set cookies, vars etc. in there? THis temporary space exists for a definable amount of time and then is wiped? Feel free to ignore me, I'm just throwing out suggestions. Also on the idea that "people would rather not view the page than have the popups loaded in the background like that", I think this is like saying "people would rather not go to a page made for IE" as opposed to making gecko capable of dealing with MSHTML.

> I think this is like saying > "people would rather not go to a page made for IE" and indeed, many people agree to that statement (assuming of course that the page does not work in mozilla).

As Boris says, anything short of completely loading the popup window can be detected. Presumably the window would at least remain invisible, if popups were "blocked." But invisible windows are considered a security risk. And even that would likely be detectable: I expect window.focus() wouldn't work as expected. It's an arms race and we won't win. As popup blockers gain popularity, obnoxious website authors will work around them. I've already seen two wonderful examples, and I don't consider this website which simply detects popup failure a wonderful example. It's pretty mundane. However, I think I don't care. It's not our goal to try to prevent advertising. The goal of popup blocking, if I may be so bold, is to squelch a remarkably obnoxious form of browser abuse. In time, if we're completely successful in shutting down this abuse (and we're not yet) advertisers will shift completely to new forms and no longer bother even to detect popup failure. These guys are just beginning to figure it out. I'll leave this bug open I guess but I think I can safely say it'll never be addressed.

I agree that this is a social, not a technical, bug. If sites want to stop people who have pop-ups blocked, so be it. Individual users can choose to whitelist that site if they want, or not to go to that site. Simple economics will dictate whether sites will be able to get away with this. Maybe we could also have a "one-time" whitelist feature in the pop-up manager that would erase the cookies of the pop-ups after viewing the site (similar to the proposed sandbox).

I agree that this is a social, not a technical, bug. If sites want to stop people who have pop-ups blocked, so be it. Individual users can choose to whitelist that site if they want, or not to go to that site. Simple economics will dictate whether sites will be able to get away with this. Maybe we could also have a "one-time" whitelist feature in the pop-up manager that would erase the cookies of the pop-ups after viewing the site (similar to the proposed sandbox).

There is definitely a social aspect to this bug, no doubt about that. However the technical aspect cannot/should not be ignored and that is that websites are able to detect unopened pop-ups. Addressing this technical aspect should not spin off into a social debate about the meta concept of pop-ups and blocking of. It should be focused on the technical feasibility of the whole matter. The whitelist seems like a decent idea, but it sounds like something else that goes under the Tools menu and we don't need another "____ Manager". If we can't accomplish hiding the fact that pop-ups aren't being opened in a somewhat simple manner, then it would surely be worth just throwing out the whole idea and let users decide how to approach this problem with the tools(blocking cookies) already available within Mozilla.

Screw it. This is definitely a social issue and I don't think it warrants any technical changes in the browser. My primary reason for using Mozilla is to avoid invasive and annoying pop-up ads, and to avoid the losing time and bandwidth that they waste. I do not want such content loaded into my browser at any time. Any website that so chooses to employ this type of technology will not be visted by me. It is especially ironic that Kazaalite's page would use this measure since their whole operation involves stripping the ad software out of Kazaa. I remind you that users who choose to view pages like this are free to turn off the pop-up disabling feature.

The bug got slashdotted today: http://yro.slashdot.org/article.pl?sid=02/11/24/2055253 and here's a testbed: http://www.anti-leech.com/theft_example.html On the given test page, the whole scheme depends on javascript: <script type="text/javascript" language="JavaScript" src="http://www.anti-leech.com/antitheft.php?id=demo_the"> </script> UAs with javascript off (e.g. lynx, chimera with js off) seem to "pass" the test. The test is apparently negative only so that if you never run the test, you never get blocked. Naively we could just not run any javascript from anti-leech.com. Hmm... that's annoying, maybe we'll need an "accept/don't accept javascript from certain sites" pref next thing.

I assume that the pop-up detection system has some means of determining if the pop-up comes from direct user interaction or not. Is it possible the same thing could be done for javascripts that forward/alter the page's URL? I'm out on a limb here, because I'm not a big JS user.

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

re comment 12: there is already an RFE about allowing/disallowing scripts (and anything else you can think of) on a per-site basis.

You're right: Bug 148722 : Requesting ability to block scripts by source However I'd prefer a more smart solution along the lines of the pop-up blocking in chimera. Instead of requiring user decisions to decide which sites to block, if it's possible I'd prefer a system like this: if the script modifies the URL of the page AND NOT( the script ran from an onClick handler ) THEN don't modify the URL of the page I think this would work ... this particular system works by loading an iframe that runs the following JS: function imageLoaded() { var url = 'http://www.anti-leech.com/antitheft_test.php?id=demo_the&test=2&cookie=yes'; if (document.images) window.location.replace(url); else window.location.href=url; } So if you don't allow it to set window.location.href then it is harmless AFAICT. How would that affect legitimate JS pages?

I originally filed a bug about this as bug #161209, in which I included a couple URLs for companies selling this "technology", http://www.antiadblocker.com and http://www.antiadbuster.com. It would probably be good to check if these companies do this in the same way, otherwise the method Simon proposes in comment #16 may only force the anti ad blockers to use different methods. The concern some people have of downloaded content for pop ups, which is what they were trying to avoid, is a valid one. I'd see this as a separate clickbox in prefs that allows one to tell Mozilla to download all the content for undisplayed pop ups and allow operations on these windows (stuff like window.focus and window.move would just return as if successful) The window could be hooked to an internal timer to allow it to be automatically closed in a few seconds, just like an annoyed user would do with a popup that was actually displayed. The clickbox pref would allow those for whom the bandwidth is a concern to continue with current behavior, accepting their inability to browse some web sites. Those with faster links may take the new option which would allow them to browse sites using anti ad blockers, which I fear will become more and more widespread, at least in the short to medium term, as website operators frantically chase a failed revenue model.

On a somewhat unrelated note, I am now trying www.kazaalite.com from my office with mozilla 1.2b and popups blocked and I am not getting redirected to antileech.com. I am not exactly sure if the site has changed or its my office proxy which has something to do with it, 'cause when I tried it yesterday from home, I did have this problem

The main kazaalite.com site is down hence the lack of anti-leech stuff. I used kazaalite a few weeks ago and although I got re-directed to the anti-leech page however the download got initiated! Simply disabling JS only works on anti-leech because they haven't put a test to see if you have JS turned on or not (the other sites do). AntiAdBlocker lite can be bypassed by having JS but disabling all the options in the prefs. The full (paid for) version can't be beaten by this trick. I like the idea of comment 16 but do wonder if there would be any further effect on mornal JS pages.

Yes. At least a few of the "top100" sites and many thousands of others would break if we disallowed setting location.href from onload.

I'd like to relate an bit of end-user experience. I hope this doesn't waste your time (please just skip this comment if you couldn't care less about end users). About a year ago, I installed Mozilla on Robin's (my girlfriend) computer. She had previously been using Netscape 4.7 unless a site specifically depended on IE. A week ago, she mentioned "I didn't realize how bad the web had become" when she spent some time browsing websites at work. She liked Mozilla before, but now she's really got an appreciation for the hard work that's gone into making Mozilla such a great browser. I personally agree that annoying ads are a social problem, but to end users what matters is that Mozilla makes the web a nicer place to visit. Much nicer than using IE. I hope the technical decision making process on this "bug" can keep end users in mind, whatever the final result may be. That's all.

There are few more simple ways to block our anti-popup. Lets say, we'd and _next_ (sic) pref to preferences. (block location.href from specific domains). So. Webmaster send us only a cookie, and on any subpage we can see only text "this site is blocked". Easy? Or lets say, we'd add some "temp area" and load popup there (without showing it to user) and on this popup there is button. Without pushing this button you're not able to work with main page.

I think this is going to be a lost cause unless some 'miracle' solution is concocted. Have a look at this DevEdge article: http://devedge.netscape.com/viewsource/2002/popup-control/ Netscape itself is advocating the detection of popups. Maybe its best to mark this bug Won't Fix. Any input?

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

A suggestion from a user on Slashdot which sounds pretty good: Rather than having window.open() return a null handle, have it return a real handle, but simply don't create the window. Better yet, have it optionally load the contents of the window, so the remote site never even knows that the window simply was never popped up.

Unfortunately it's not all that useful a suggestion: see comment 4 and comment 12

I meant comment 7 rather than 12

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

In order to correct this kind of problem (where we need to load the entire popup to stop detection) we cannot 'win' the war, because there will always be a technical solution to anything we do except those things which defeat some of the main purposes of popup blocking (bandwidth reduction, annoying window removal). We can't win, but we can make it so expensive to do that it isn't worth detecting. Right now most methods cost them nothing - the work is all performed on the client side. We need to move the popup killer dectection to the server side and waste their server resources and bandwidth instead of our own. Right now it is all done through javascript. By disabling javascript features on a per site basis (as is done with window.open inside onload events) we can make it more expensive. This needs to be completed with a javascript preparser. We need a seperate module with user definable rules which can have things like disallow address redirection in onload events, disallow (or jail) cookies, etc. This will slow down javascript execution (there are ways around some of the efficiency loss) but would only be performed on certian sites. It would enable rule sets to be distributed quickly without rebuilds, and users could tweak their own rules. It could even be considered a greater feature, allowing users to add code to webpages (perhaps for annotations, advanced menus, site editing and control, etc). Those interested would keep the rulesets updated, and chances are it would be good enough - it would be to expensive for the majority of sites to start doing advanced server side scripting since not all users would keep the rule sets updated. It could even be tested as a simple perl/php/etc proxy which changes the web pages on the fly as the browser loads them. -Adam

For reasons that others have described above, I vote to wontfix this. As Dan said in comment 7, we can't prevent all advertising, only stop a particularly egregious form of browser abuse. The ultimate answer is "don't visit the site that annoys you."

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

I'm against this proposal. There are legitimate uses for pop-up windows. Since so many users have popup blocks, or might be on a marginal system, it is valid for a site that legitimately uses pop-ups to detect if they are working. If they are not working, they can warn users that they are missing content. I have generated pop-ups from mouse rollovers, to give the user a large box with more info and a graphic image. These can not be displayed just using title="xxxx". Pop-ups are especially nice when screen real estate is tight, because they can be offset from whatever area is currently the focus. (used onmouseoff to close them automatically, so just one shows at any given time) (if you know of any other way to implement this besides popups, please tell me) for some applications, the designer (not the user) should have the choice that if popups are not working, to exit rather than offer only partial functionality.

About comment 29, as far as I understand it: Mozilla does already have the capability of disabling individual window properties and functions by domain. A third-party could always step up with a list of rules using these capabilities in an attempt to acquire greater control over website behaviour, but this isn't something mozilla.org itself wants to be involved with. If you really want to try this, you may need even more control than CAPS allows. Please file a new bug specifically for that. About comment 32: windows opened in mouseover event handlers are blocked by default in recent builds. For your scheme to work the user must allow popup windows on your site. But that would seem to be what you're talking about, knowing to display a warning to users with popups disallowed. About comment 30: comment 4 and comment 7 still apply. It really isn't possible to fix this bug. A website will always be able to detect whether the window was opened and loaded with the expected content. The only practical way to address this issue is to actually load blocked popups but not display them. But since Mozilla has never allowed a website to open invisible windows for security concerns, I don't see that happening. So honestly, this bug won't be fixed. Closing.