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.
Thanks;
– 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
twice...)
Hi,
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 <b>bold<\/
b>"
So it has transformed the "<" and "<" into HTML entities < and >
-
that's another thing than URL escaping.
Hope that clarifies it?
Best wishes,
Björn
