Thanks everyone. I didn't have all of the information regarding the
clickjacking incidents and only saw the effects of the script
changes. I agree that the iframe restriction was the best and easiest
thing for Twitter to implement.
On Feb 15, 12:24 pm, John Adams j...@twitter.com wrote:
I'm
I hope Twitter will reconsider these changes. With My Tweeple, I was
able to provide a preview of a user's updates by displaying the page
in an iframe. It was very convenient for the user to review someone's
tweets before deciding to follow someone. It also appears that
Twummize.com no longer
Actually, forcing an app to use the API is better for Twitter. You get
the data directly, and the system doesn't spend any time rendering the
HTML. Less data from us = less time tying up server resources.
There's no reason why you can't write a small amount of code to fetch
a user's
Supposedly there are a couple of methods of blocking Twitters JavaScript but
I can't find the page anymore. My recollection is they mostly relied on
vulnerabilities in IE... Kind of ironic actually. I would not recommend this
method as it probably could get you banned from Twitter.
On Sun, Feb
I'm fairly certain we've patched the IE vulnerability, and that it
only affected users on IE6. I'd have to ask our UX team, though.
-j
On Feb 15, 2009, at 12:19 PM, Abraham Williams wrote:
Supposedly there are a couple of methods of blocking Twitters
JavaScript but I can't find the page
Because if the click-jacking incident yesterday it seems you've added
something like:
//![CDATA[
twttr.form_authenticity_token =
'966f6780e3bb206fe5f451d9ea40407f6532277f';
if (window.top !== window.self) { setTimeout(function()