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.
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.
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 ;)
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.
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.
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.
Also I notice you say "Back when I experimented.." -- was there a reason it didn't work out in the end?
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.)