Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's clickjacking. That was 2008. This is clickjacking with a like button. I wrote about it in early June ( http://www.h-i-r.net/2010/06/viral-like-jacking-on-facebook.... ) and it was already somewhat old-hat by then. In fact, I think I covered the same technical details this person did.

It's not really ingenious. It's just scammy behavior and yet another fine reason to run NoScript.



NoScript isn't a good solution and certainly not a scalable one - most people don't want to browse without js.

It'd be better for browser makers to simply detect clickjacking and block it.

If an element isn't visible to the user (either partially visible or behind other elements), that's probably a good sign it shouldn't be able to receive user actions such as clicks. Especially if it's an iframe.

I hope firefox+chrome do some work on this soon.


NoScript is a specific Firefox extension, not general advice to turn off Javascript. NoScript lets you whitelist trusted Javascript, so when you visit that spam site, its Javascript doesn't run. Meanwhile, when you visit omg-animated-lolcats-yay.com, you notice that the lolcats aren't omg-animated, so you click one button to whitelist the Javascript, and then you get your omg-animated-lolcats forever. Yay!


>> "so you click one button to whitelist the Javascript"

It's amazing how quickly 'click one button to be able to view this website' would irritate the hell out of anyone.

It's certainly an option for geeks or security freakouts, but not really an option for normal people.

Also how would a 'normal' person decide if a website is 'safe' to enable js or not? If you're the kind of person fooled into clicking for 'hot bartenders' and filling out a survey to get access, you're probably not able to decide if you should enable js or not.

The solution isn't to shift responsibility to users, it's to fix the browser flaws that allow clickjacking to happen.

The example given here should be a textbook easy to fix bug in browsers. It's a browser issue which should be high priority.

An iframe which isn't visible to the user, should not be able to receive input from the user.


> It's amazing how quickly 'click one button to be able to view this website' would irritate the hell out of anyone.

Back when I experimented with manually authorizing cookies on all websites I visited, it was surprising how quickly the number of cookie prompts dropped to near-zero. There really aren't that many websites that you visit.


What software did you use for this? I have tried a few cookie blocking extensions for Firefox but haven't found a good one.

Also I notice you say "Back when I experimented.." -- was there a reason it didn't work out in the end?


I was using Konqueror then. The experiment ended when I got another computer or something.


If it's so easy to fix, fix it?


I don't think it's technically hard to fix at all. I think the more likely issue is that it may break badly coded websites that do stupid stuff. Chrome+Firefox should definitely do it though.

You can't really just cop-out that if something is open source then it's not fair game for criticism. Firefox has some big bugs open for months before they get worked on.

To prevent the example cited from working would likely take 10-20 lines of code in webkit/firefox. But it'd likely take a week or so to get up to speed with the project to be able to know where to insert those lines of code. Fixing other methods of hiding an iframe would likely take a bit more thought, but it's hardly rocket science.

I have enough to do without fixing browsers ;)


Firefox has some big bugs open for months before they get worked on.

I have enough to do without fixing browsers.

You explained your own observation.

You can't really just cop-out that if something is open source then it's not fair game for criticism.

Open Source is certainly "fair game for criticism". But you aren't going to get anything out of criticism, because criticism cannot write any code. Open Source is all about people seeing a problem, fixing the problem, and sharing the fix. Nothing more. And it certainly has no obligation to a user who is quick to criticize but slow to fix.

It's the software engineering equivalent of yelling at the TV when the news makes you mad. It's pointless and makes you look insane.


I disagree. For the people working on webkit, the fix is probably an hours work.

For me, it'd likely be a week to get up to speed with the project. So it's more efficient for me, and other users not familiar with the codebase to yell at the developers for a day or two and see if they'll fix it.

I know in open source utopia everyone seamlessly just hops into other projects, fixes a bug, says 'here you go! bye for now', and carries on to the next project, but that doesn't happen in real life.

Who knows though, maybe I'm wrong. Maybe there's a really good reason they allow clickjacking. But I certainly can't see one.


NoScript has click-jacking protection, some XSS protection, and some other things. You could theoretically run it with those things on, but no scripting disabled.

I don't know how good the click-jacking or XSS protection is. For me it has always been a false positive, and usually very quickly fixed and ack'ed in the changelog, and otherwise, I really don't browse the web in such a way that I'm routinely encountering such things. (Plus I do use it with scripting off, so anything like a malicious script to further trigger an XSS elsewhere won't work on me.)

But even if you don't want the script blocking, it can be useful.

(And as others have observed, it is less annoying that you might initially guesstimate. I use it on two machines with no configuration sync'ing, and it still isn't annoying to me.)




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: