Hi Bjoern,

Short Answer: It's working as designed for security reasons. We don't like it any more than you do.

Long Answer: This has come up on the list quite a bit in the past. Like a great many things spammers, scammers and unkind people are the reason we can't have nice things. When we discussed allowing non-escaped data the main argument against it was that the majority of tweets are displayed via HTML and that failing to do that correctly poses a security risk to everyone. We erred on the side of security and caution, returning the data in a way suitable for display on a web page rather than trusting each and every developer to handle it correctly. That would make each developer a single point of failure for security … and that's a whole lot of possible failure. As it stands now a web developer has to go out of their way to enable XSS attacks in tweets. The feeling was that security should be the default, and disabling should be an exercise left to the reader. We're well aware that this is not ideal, and that it's a bit of a pain for non-web applications. We wish we didn't have to do this sort of thing but sometime you have to find a balance between standards, data purity, and protection.

 – Matt Sanford / @mzsanford
     Twitter Dev

On Jul 17, 2009, at 7:53 AM, Bjoern wrote:

(somehow got the response above as email, too - sorry for replying


look for example at this: http://twitter.com/statuses/show/2689100482.json

My status update was "test html escaping by twitter <b>bold</b>" but
Twitter sends me "test html escaping by twitter &lt;b&gt;bold&lt;\/

So it has transformed the "<" and "<" into HTML entities &lt; and &gt;
that's another thing than URL escaping.

Hope that clarifies it?

Best wishes,


Reply via email to