You're probably right. It's easiest just to investigate any alarmingly high impressions:liking ratio and see if something phishy is happening.
Then again... the fact that I could unwillingly goatse all of my contacts (even if you prevent it from happening to too many people afterwards) makes me not want to stay signed in, at least until I can opt out of "liking" things.
It's late and I'm going to sleep... I'll reply in full tomorrow. Specifically, I think requiring javascript might not be that much of a detriment, especially if it alleviates any possibility and concern of fb getting embarrassed by a surge of clickjacking attacks.
As per the user experience concerns... the js solution wouldn't result in any worse UX for slow users than the iframe currently does. Either way, it's 1 round trip request needed to display the button, and 1 round trip request to ensure the button click goes through. In your case it's a round trip to load the iframe, a round trip once it's clicked. In my case, 1 round trip to get the JS, which displays the button, and 1 round trip to send the click event (the changing of the button can be client side and appear instant).
The main concern with a non-iframe solution is that the host page can really try to screw with your button.. you'd need to make it an image and ensure it's being displayed correctly (correct size, correct src, etc). But, again, I think it's entirely possible with not-too-much code.
Then again... the fact that I could unwillingly goatse all of my contacts (even if you prevent it from happening to too many people afterwards) makes me not want to stay signed in, at least until I can opt out of "liking" things.
It's late and I'm going to sleep... I'll reply in full tomorrow. Specifically, I think requiring javascript might not be that much of a detriment, especially if it alleviates any possibility and concern of fb getting embarrassed by a surge of clickjacking attacks.
As per the user experience concerns... the js solution wouldn't result in any worse UX for slow users than the iframe currently does. Either way, it's 1 round trip request needed to display the button, and 1 round trip request to ensure the button click goes through. In your case it's a round trip to load the iframe, a round trip once it's clicked. In my case, 1 round trip to get the JS, which displays the button, and 1 round trip to send the click event (the changing of the button can be client side and appear instant).
The main concern with a non-iframe solution is that the host page can really try to screw with your button.. you'd need to make it an image and ensure it's being displayed correctly (correct size, correct src, etc). But, again, I think it's entirely possible with not-too-much code.
Alright, I'm going to sleep for real.