Closed Bug 181035 Opened 22 years ago Closed 20 years ago

website detects popups as being disabled and blocks user

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: keyoar, Assigned: danm.moz)

References

(Blocks 1 open bug,
URL
)

Details

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....
Assignee: asa → danm
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Target Milestone: --- → Future
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. ***
Blocks: popups
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Product: Browser → Seamonkey
Status: RESOLVED → VERIFIED
Whiteboard: closeme 2009-11-12
Whiteboard: closeme 2009-11-12
You need to log in before you can comment on or make changes to this bug.