Closed Bug 230500 Opened 21 years ago Closed 21 years ago

New method of unsolicited popup advertisements bypasses blocker

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 227338

People

(Reporter: ashibaka, Assigned: jag+mozilla)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030 Firebird/0.7+ (Mike Tigas (Nova); MNG; Ox,G6) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030 Firebird/0.7+ (Mike Tigas (Nova); MNG; Ox,G6) Websites under the Lycos network (Lycos, Angelfire, and Tripod) have a new method of popup blocking that works by infesting ALL links on the page with a Javascript that opens popups. Mozilla is tricked into thinking that the user is requesting the popup to be opened, but actually the user is trying to visit an external page. Since the popup comes at the same time as the newly loading, non-Lycos page, the user will often assume that the popup ad is coming from the new page. Reproducible: Always Steps to Reproduce: 1. Disable cookies-- the script uses cookies so that only one popup opens per day. 2. Click the first link and no popup will open. 3. Click the second link and a popup advertisement will open. 4. Click the third link and a popup advertisement will open. (Note: Lycos' popup code is subject to change) Actual Results: The second two links open unsolicited popup ads. Expected Results: Mozilla should block unsolicited popup ads. Discussion thread at http://forums.mozillazine.org/viewtopic.php?t=44398 Suggested fix, maybe: - Disabling access to document.getElementsByTagName('A') when the page loads (is there any legitimate use for it?) - Not allowing tags to be modified when the page loads (again, any legitimate use?) Suggested workarounds for endusers: - Set a cookie for .angelfire.com named "ExitPage", with the value "viewed", that doesn't expire - Simply disable Javascript, or turn off all popup windows - Disable access to document.getElementsByTagName on Lycos using CAPS - Void functions named buildExitHandler on Lycos
I see this bug. My build ID is: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040104 Firebird/0.7+
Probably the same as bug 226962.
Assignee: general → jag
Component: Browser-General → XP Apps
QA Contact: general → pawyskoczka
Unfortunately, there is really no way to tell that this is abusive -- this technique is used by far too many respectable sites (cnn, new york times, weblogs, etc).
This is bug 227338 (it helps to search for closed bugs when you're looking for duplicates :-)). As I said in that bug, this script is equivalent to simply writing a web page with click handlers that open new windows. These aren't really popups. And as Boris said, I think it's impossible to distinguish between these pseudo-popups and genuine content. If we hamstring script in the name of "popup" protection, people will simply begin hardcoding these click handlers. Worse, we become incompatible with legitimate websites. It's out of the question. And obviously, we can't hardcode into the client the voiding of functions named buildExitHandler on Lycos sites. Also, on the subject of guarding against document.getElementsByTagName('A'), note that the site mentioned in bug 227338 uses document.links. However, as the practice becomes more common, it gets more annoying. See bug 227338 comment 2. Also see bug 197919, which suggests Mozilla make click handlers subject to popup protection. That too would solve this problem, for now. *** This bug has been marked as a duplicate of 227338 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.