Slashdot Mirror
The Java Popup you Can't Stop
An anonymous reader writes "In his brand new hackademix.net blog, Giorgio Maone, known as the author of the NoScript security extension for Firefox, reveals how popup blockers can be easily circumvented using Java. Worse, popups opened this way are really evil, because they can be sized to cover the whole desktop (the wet dream of any phisher) and cannot be closed by user (the wet dream of any web advertiser).
Impressive demos available, all cross-browser and cross-platform, in the best Java tradition: 'Write once, hack anywhere' "
For the love of all that is holy, please don't promote this story to the /. frontpage. The less advertisers that are made aware of this the better.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
this is a real slashdot article, and not some clever cross site full screen javascript faux article out to steal my cookies, hmmm? if i hit submit i might-
oh shit
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
I'd really like to see counter methods posted as (special) comments under articles like these. "Links to: How to prevent this". It would be really nice if we could use our mod points to "mark" a comment as a solution that an administrator could then move it to the top. Why the administrator involvement? Simple, to prevent the teams of people who go around and exploit this type of function on Yahoo. This would still allow Slashdot to work off the same random moderator point system it has while keeping some semblance of order. They could play around with how many mod points a comment needs before it can before an admin is notified.
Just a thought.
If he were selling his software commercially, or people were being directed from the Slashdot front page to a page full of ads, then you might have a point, but that's not the case here. The guy has made an obviously useful tool, gives it away for free, and is warning about an obviously relevant threat. The most he's likely to get out of this is a few small donations or a few more page hits on his site, perhaps making enough to cover the server costs for hosting a popular Firefox extension for a while and a bit of beer money. I think your post is way over the top.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
There are people who still browse with java switched on?! That is SO 1990's.
Didn't you read the headline? You can't stop these things. Heck, the demo popped up an unkillable window on my AmigaOS box, and no JVM even exists for that...
The one sure way to endear me to a product and cause me to whip out my credit card is to pop up a window over my entire screen that I cannot remove. This type of "in your face" advertising is exactly what reluctant consumers like myself need.
FAQs are evil.
Would like to share some specifics. Disassembled the bytecode using javap and used my rusty JRE assembler 'skillz' to understand it, but well, since he seems to have compiled it with full debug options, any idiot can find it ut by staring at the output for a sec.
1. It doesn't use any "go fullscreen" API
2. It's a failure of assuming sum of parts of software is as secure is as its components. It can be "less" secure than any of the component taken in isolation. Point in case is the set of APIs used:
a) Toolkit.getScreenSize(): Used to find size of desktop. Nothing evil here
b) Window.setBounds(): Used to set size of window. Nothing evil, except set it larger than screen size, hence hiding the applet warning by moving it "off screen"
c) Window.setAlwaysOnTop(): Used to set the window on top. Essential for displaying "Modal" dialog boxed like error boxes. Nothing sinister here.
However, the shit happens because all the things taken together can be dangerous. Specially, passing "System Modal" to setAlwaysOnTop().
I don't see an obvious "fix" except the following hurdles that can be presented to unsigned applets (and hence breaking a lot of hobby games, apps etc)-
1. Validate applet size to be always significantly less than screen size
2. Remove support for "System Modal" for unsigned applets for "setAlwaysOnTop". Application modal is fine, system modal is not.
Any more ideas shall be appreciated.
Oh, and I again despise him for an irresponsible disclosure and presenting the hack in easily reverse engineered, fully functional code.
- mritunjai
I don't see an obvious "fix" except the following hurdles that can be presented to unsigned applets (and hence breaking a lot of hobby games, apps etc)-
1. Validate applet size to be always significantly less than screen size
2. Remove support for "System Modal" for unsigned applets for "setAlwaysOnTop". Application modal is fine, system modal is not.
I would expect that "System Modal" should be forbidden from any applet, even if it is signed. After all, it is running in a browser, not directly in the OS, so Application modal should be sufficient. In fact, one can argue that if you are writing an applet and you need System Modal functionality, then you are probably using the wrong technology anyways and should consider alternatives.
Applets were designed to be sandboxed. System Modal should have been forbidden from the beginning anyways.