Announcement: JSON responses changing in 30 days (Oct 25th). THIS MIGHT BREAK YOUR APP, PLEASE READ!
2 views
Skip to first unread message
Alex Payne
Sep 25, 2008, 9:11:53 PM9/25/08
to twitter-deve...@googlegroups.com
I've collected feedback on a previously-discussed [1] security issue
concerning JSON responses that are wrapped in user-defined callbacks.
In 30 days (October 25th, 2008), the ability to define callbacks for
all API methods that can potentially return private data will be
deprecated. If your Twitter application relies on these callbacks,
you'll need to update your application to process those responses
another way.
concerning JSON responses that are wrapped in user-defined callbacks.
In 30 days (October 25th, 2008), the ability to define callbacks for
all API methods that can potentially return private data will be
deprecated. If your Twitter application relies on these callbacks,
you'll need to update your application to process those responses
another way.
This change impacts the following API methods:
- /statuses/friends_timeline
- /statuses/user_timeline
- /statuses/show
- /statuses/update
- /statuses/destroy
- /statuses/replies
- /statuses/friends
- /statuses/followers
- /users/show
- /direct_messages
- /direct_messages/sent
- /direct_messages/new
- /direct_messages/destroy
- /friendships/create
- /friendships/destroy
- /account/update_location
- /account/update_delivery_device
- /account_rate_limit_status
- /favorites
- /favorites/create
- /favorites/destroy
- /notifications/follow
- /notifications/leave
- /blocks/create
- /blocks/destroy
Yes, that's most of the methods in the Twitter API. Very few of our
methods are guaranteed never to return the details or status of a
"protected" (private) user. Only methods like
/statuses/public_timeline are safe for user-defined callbacks.
Regarding the other, more obscure JSON security issue discussed in the
aforementioned thread: we'll be changing the structure of JSON
responses to be a Hash in the next major revision of the API to avoid
the Array-overloading vulnerability in older versions of Firefox.
This change is too broad-reaching to accomplish at the same API
endpoints, and we have a major update the API in the works anyway.
Please help spread the word to any other developers you know who make
use of callbacks with their JSON-formatted Twitter API responses.
Thanks much!
[1] http://groups.google.com/group/twitter-development-talk/browse_thread/thread/1f81d8278ed62c3b#
--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x
Xeoncross
Sep 25, 2008, 10:53:32 PM9/25/08
to Twitter Development Talk
I don't see the term "callbacks" defined in the WIKI - as far as I
know
a "callback" is a function triggered by another function. But I don't
see
anything like that in the WIKI...
So does this mean that private things like "location",
"followers_count",
and "user id" will no longer be sent back in the JSON responses?
Will they still be sent back in XML?
Alex Payne
Sep 26, 2008, 1:49:50 AM9/26/08
to twitter-deve...@googlegroups.com
We're not removing any parameters from the JSON responses. The
ability to have user-defined callbacks has been informally documented
in this group, as it's not frequently-used functionality.
ability to have user-defined callbacks has been informally documented
in this group, as it's not frequently-used functionality.
--
jstrellner
Sep 26, 2008, 5:53:13 AM9/26/08
to Twitter Development Talk
Alex, you should include an example of what a "callback" is as it
pertains to twitter. I am sure many developers newer to json may not
know what it is, or if they've had things developed for them, may not
know what to look for to check if this is going to effect them.
I know what json callbacks are; they are a way to tell twitter to
return the json response in a way that is instantly usable in a
javascript environment, but I don't know how it was formatted to
provide an example since we don't use them.
pertains to twitter. I am sure many developers newer to json may not
know what it is, or if they've had things developed for them, may not
know what to look for to check if this is going to effect them.
I know what json callbacks are; they are a way to tell twitter to
return the json response in a way that is instantly usable in a
javascript environment, but I don't know how it was formatted to
provide an example since we don't use them.
Julio Biason
Sep 26, 2008, 5:57:11 AM9/26/08
to twitter-deve...@googlegroups.com
On Fri, Sep 26, 2008 at 7:53 PM, jstrellner <jstre...@urltrends.com> wrote:
> Alex, you should include an example of what a "callback" is as it
> pertains to twitter. I am sure many developers newer to json may not
> know what it is, or if they've had things developed for them, may not
> know what to look for to check if this is going to effect them.
> Alex, you should include an example of what a "callback" is as it
> pertains to twitter. I am sure many developers newer to json may not
> know what it is, or if they've had things developed for them, may not
> know what to look for to check if this is going to effect them.
Well, it's going away anyway, so why that would affect users that
don't know what a callback is? If they don't know, they're probably
not using it anyway.
--
Julio Biason <julio....@gmail.com>
Twitter: http://twitter.com/juliobiason
Santiago Perez
Sep 26, 2008, 8:27:25 AM9/26/08
to Twitter Development Talk
I'm not sure I understand why the callback functionality is any more
insecure than the normal API, couldn't a page simply do AJAX to get
the JSON or XML response parse it with javascript and do anything the
could do with a callback? If this is the case, you're not really
making things more secure, you're just making it a little more
difficult to steal protected information.
> [1]http://groups.google.com/group/twitter-development-talk/browse_thread...
insecure than the normal API, couldn't a page simply do AJAX to get
the JSON or XML response parse it with javascript and do anything the
could do with a callback? If this is the case, you're not really
making things more secure, you're just making it a little more
difficult to steal protected information.
Alex Payne
Sep 26, 2008, 1:05:46 PM9/26/08
to twitter-deve...@googlegroups.com
You're quite right - we're making it more difficult for attackers,
which is better than doing nothing.
which is better than doing nothing.
We'll document the use of callbacks.
spice3d
Sep 26, 2008, 4:52:10 PM9/26/08
to Twitter Development Talk
Santiago: It's not as easy as this with Firefox. Basically in JS
(Javascript), AJAX can't do a cross domain request. As far as I can
determine, anyone using JS to handle the feed client-side is dead.
It's kinda ironic since the JSON container is based on JS.
(Javascript), AJAX can't do a cross domain request. As far as I can
determine, anyone using JS to handle the feed client-side is dead.
It's kinda ironic since the JSON container is based on JS.
jstrellner
Sep 27, 2008, 5:38:37 AM9/27/08
to Twitter Development Talk
So people can check their code to make sure they don't use them... It
better to be safe and provide people with example, so they can check
their code, then to be sorry when the change goes into effect by
having hundreds of twitter users claiming that twitter broke their app
again.
On Sep 26, 2:57 am, "Julio Biason" <julio.bia...@gmail.com> wrote:
> Twitter:http://twitter.com/juliobiason
better to be safe and provide people with example, so they can check
their code, then to be sorry when the change goes into effect by
having hundreds of twitter users claiming that twitter broke their app
again.
On Sep 26, 2:57 am, "Julio Biason" <julio.bia...@gmail.com> wrote:
> On Fri, Sep 26, 2008 at 7:53 PM, jstrellner <jstrell...@urltrends.com> wrote:
> > Alex, you should include an example of what a "callback" is as it
> > pertains to twitter. I am sure many developers newer to json may not
> > know what it is, or if they've had things developed for them, may not
> > know what to look for to check if this is going to effect them.
>
> Well, it's going away anyway, so why that would affect users that
> don't know what a callback is? If they don't know, they're probably
> not using it anyway.
>
> --
> Julio Biason <julio.bia...@gmail.com>
> > Alex, you should include an example of what a "callback" is as it
> > pertains to twitter. I am sure many developers newer to json may not
> > know what it is, or if they've had things developed for them, may not
> > know what to look for to check if this is going to effect them.
>
> Well, it's going away anyway, so why that would affect users that
> don't know what a callback is? If they don't know, they're probably
> not using it anyway.
>
> --
> Twitter:http://twitter.com/juliobiason
virtudude
Sep 28, 2008, 12:06:22 AM9/28/08
to Twitter Development Talk
Will this apply to the search API as well? Please say no. :-)
> [1]http://groups.google.com/group/twitter-development-talk/browse_thread...
Simon Willison
Sep 27, 2008, 9:05:04 PM9/27/08
to Twitter Development Talk
On Sep 26, 2:11 am, "Alex Payne" <a...@twitter.com> wrote:
> I've collected feedback on a previously-discussed [1] security issue
> concerning JSON responses that are wrapped in user-defined callbacks.
> In 30 days (October 25th, 2008), the ability to define callbacks for
> all API methods that can potentially return private data will be
> deprecated. If your Twitter application relies on these callbacks,
> you'll need to update your application to process those responses
> another way.
>
> This change impacts the following API methods:
>
> - /statuses/friends_timeline
> - /statuses/user_timeline
> - /statuses/show
Is there any chance at all we can have a version of user_timeline that
> I've collected feedback on a previously-discussed [1] security issue
> concerning JSON responses that are wrapped in user-defined callbacks.
> In 30 days (October 25th, 2008), the ability to define callbacks for
> all API methods that can potentially return private data will be
> deprecated. If your Twitter application relies on these callbacks,
> you'll need to update your application to process those responses
> another way.
>
> This change impacts the following API methods:
>
> - /statuses/friends_timeline
> - /statuses/user_timeline
> - /statuses/show
only returns public data, and has callback enabled? A new method
called user_public_timeline for example?
Our app http://tweetersation.com/ relies on JSONP callbacks to the
user_timeline API method.
Cheers,
Simon
Simon Willison
Sep 27, 2008, 9:01:29 PM9/27/08
to Twitter Development Talk
On Sep 26, 1:27 pm, Santiago Perez <san...@santip.com.ar> wrote:
> I'm not sure I understand why the callback functionality is any more
> insecure than the normal API, couldn't a page simply do AJAX to get
> the JSON or XML response parse it with javascript and do anything the
> could do with a callback?
No. The same-origin restriction baked in to every browser forbids
> I'm not sure I understand why the callback functionality is any more
> insecure than the normal API, couldn't a page simply do AJAX to get
> the JSON or XML response parse it with javascript and do anything the
> could do with a callback?
XMLHttpRequest calls from working across different domains. JSONP
(JSON with a callback parameter) is a workaround for this limitation -
without the callback (or corresponding old versions of Firefox array
vulnerability) you can't access anything.
spice3d
Sep 28, 2008, 2:38:06 PM9/28/08
to Twitter Development Talk
That's a great idea Simon has. I'm actually unsure what non-public
data the current user feed returns.
> Our apphttp://tweetersation.com/relies on JSONP callbacks to the
data the current user feed returns.
Simon Willison
Sep 28, 2008, 6:41:36 PM9/28/08
to Twitter Development Talk
On Sep 28, 7:38 pm, spice3d <spic...@gmail.com> wrote:
> That's a great idea Simon has. I'm actually unsure what non-public
> data the current user feed returns.
The user_timeline method returns "friends only" tweets if you are
> That's a great idea Simon has. I'm actually unsure what non-public
> data the current user feed returns.
logged in and that person has given you permission to view them.
Cheers,
Simon
Alex Payne
Sep 29, 2008, 1:21:51 PM9/29/08
to twitter-deve...@googlegroups.com
We'll try to allow callback for timelines from public users.
We'll still be allowing callbacks for all Search API results, as all
of that data is public.
--
spice3d
Sep 29, 2008, 5:13:22 PM9/29/08
to Twitter Development Talk
I guess my point is that the tweets are all public and you could
gather it all by going to that person's page and then looking at who
they are following.
gather it all by going to that person's page and then looking at who
they are following.
spice3d
Oct 1, 2008, 6:57:58 PM10/1/08
to Twitter Development Talk
Alex: What exactly do you mean by "timelines from public users". What
will be the difference between this and the current-but-soon-to-be-
extinct friends timeline?
will be the difference between this and the current-but-soon-to-be-
extinct friends timeline?
Alex Payne
Oct 2, 2008, 1:46:03 PM10/2/08
to twitter-deve...@googlegroups.com
I mean that we'll allow callbacks for the /statuses/user_timeline
method for the case that the user whose timeline is being requested
hasn't protected his/her account. This is unrelated to the
/statuses/friends_timeline method.
method for the case that the user whose timeline is being requested
hasn't protected his/her account. This is unrelated to the
/statuses/friends_timeline method.
Does that clear it up?
spice3d
Oct 2, 2008, 8:35:47 PM10/2/08
to Twitter Development Talk
Ah ok. I didn't even know there was such a setting. I just looked and
saw the "Protect my updates" option on the Account Settings page. I'm
assuming this is what you are talking about. I suppose that is a good
compromise. Will this be done prior to callback elimination?
saw the "Protect my updates" option on the Account Settings page. I'm
assuming this is what you are talking about. I suppose that is a good
compromise. Will this be done prior to callback elimination?
Alex Payne
Oct 3, 2008, 1:08:33 PM10/3/08
to twitter-deve...@googlegroups.com
It'll be part of the same change.
spice3d
Oct 24, 2008, 12:19:55 PM10/24/08
to Twitter Development Talk
Tomorrow is D-Day. I hope everyone is prepared...
Alex Payne
Oct 24, 2008, 12:32:48 PM10/24/08
to twitter-deve...@googlegroups.com
Given that tomorrow is a Saturday, we won't be pushing the change just
yet. Think Monday or Tuesday. But it'd be good to be ready by
Saturday!
yet. Think Monday or Tuesday. But it'd be good to be ready by
Saturday!
On Fri, Oct 24, 2008 at 9:19 AM, spice3d <spi...@gmail.com> wrote:
>
> Tomorrow is D-Day. I hope everyone is prepared...
>
--
Reply all
Reply to author
Forward
0 new messages