Cross-domain policy file
522 views
Skip to first unread message
zeh fernando
Oct 18, 2010, 3:34:48 PM10/18/10
to Twitter Development Talk
Does Twitter have any plans on when/whether they'll change its current
cross-domain policy file?
http://api.twitter.com/crossdomain.xml does not allow requests from
Flash-based websites and web apps because it restricts response to
twitter.com subdomains.
http://search.twitter.com/crossdomain.xml, however, does allow Flash
requests from any domain.
This policy pretty much renders all Flash calls to the API useless
(unless they're search calls).
One could use proxy scripts, but given the limitations imposed by the
Twitter API (150 calls per IP per hour), it means public websites are
out of luck if they're getting any kind of public data without
authenticating like, say, getting a (public) user timeline.
This has been discussed at length in previous threads.
Change in crossdomain.xml??
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/8d09970f449abc70
Most curiously, the above thread mentions on March 2008 that Twitter
would be moving API calls to api.twitter.com and allowing a more
permissive crossdomain policy file there in a few months. This hasn't
happened, though, since people have continued to be dumbfounded by the
inability to load Twitter data from Flash-based web apps.
Twitter Stream crossdomain.xml
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/fa7c3f42f85b8d3
I think this decision is specially questionable as the cross-domain
restrictions in place do nothing else other than put a tax on what
people can do from Flash-based web apps, but also allow any other
usage from any other technology, be it a security issue or not. In
fact, even using PHP proxies one could make the API calls from Flash
(albeit in a restricted manner) so I can't see a real reason for
singling out/blocking this platform.
Normally, public APIs add no such artificial/ineffective restrictions,
and simply allow any kind of connection (doing their own top of their
own built-in restrictions and rate limiting)...
http://graph.facebook.com/crossdomain.xml - allows connections from
all domains
http://api.flickr.com/crossdomain.xml - allows connections from all
domains
http://api.plixi.com/crossdomain.xml - allows connections from all
domains
http://api.bit.ly/crossdomain.xml - allows connections from all
domains
http://stream.twitvid.com/crossdomain.xml - allows connections from
all domains
...etc etc
So, is there any clear reason why the restriction is still in place?
Or any idea on when this policy will be reviewed?
Thanks,
Zeh
cross-domain policy file?
http://api.twitter.com/crossdomain.xml does not allow requests from
Flash-based websites and web apps because it restricts response to
twitter.com subdomains.
http://search.twitter.com/crossdomain.xml, however, does allow Flash
requests from any domain.
This policy pretty much renders all Flash calls to the API useless
(unless they're search calls).
One could use proxy scripts, but given the limitations imposed by the
Twitter API (150 calls per IP per hour), it means public websites are
out of luck if they're getting any kind of public data without
authenticating like, say, getting a (public) user timeline.
This has been discussed at length in previous threads.
Change in crossdomain.xml??
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/8d09970f449abc70
Most curiously, the above thread mentions on March 2008 that Twitter
would be moving API calls to api.twitter.com and allowing a more
permissive crossdomain policy file there in a few months. This hasn't
happened, though, since people have continued to be dumbfounded by the
inability to load Twitter data from Flash-based web apps.
Twitter Stream crossdomain.xml
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/fa7c3f42f85b8d3
I think this decision is specially questionable as the cross-domain
restrictions in place do nothing else other than put a tax on what
people can do from Flash-based web apps, but also allow any other
usage from any other technology, be it a security issue or not. In
fact, even using PHP proxies one could make the API calls from Flash
(albeit in a restricted manner) so I can't see a real reason for
singling out/blocking this platform.
Normally, public APIs add no such artificial/ineffective restrictions,
and simply allow any kind of connection (doing their own top of their
own built-in restrictions and rate limiting)...
http://graph.facebook.com/crossdomain.xml - allows connections from
all domains
http://api.flickr.com/crossdomain.xml - allows connections from all
domains
http://api.plixi.com/crossdomain.xml - allows connections from all
domains
http://api.bit.ly/crossdomain.xml - allows connections from all
domains
http://stream.twitvid.com/crossdomain.xml - allows connections from
all domains
...etc etc
So, is there any clear reason why the restriction is still in place?
Or any idea on when this policy will be reviewed?
Thanks,
Zeh
zeh fernando
Oct 18, 2010, 4:12:48 PM10/18/10
to Twitter Development Talk
Just to add some other examples of popular API domains:
Youtube API cross-domain policies - allow connections from all (real)
domains
http://gdata.youtube.com/crossdomain.xml
Google search APIs - allow conection from all domains
http://ajax.googleapis.com/crossdomain.xml
Ebay APIs - allow connection from all domains
http://svcs.ebay.com/crossdomain.xml
Delicious APIs - allow connections from all domains
https://api.del.icio.us/crossdomain.xml
Last.fm APIs - allow connections from all domains
http://ws.audioscrobbler.com/crossdomain.xml
Bing Maps APIs - allow connections from all domains
http://ecn.dev.virtualearth.net/crossdomain.xml
See a trend here?
Zeh
On Oct 18, 3:34 pm, zeh fernando <z...@zehfernando.com> wrote:
> Does Twitter have any plans on when/whether they'll change its current
> cross-domain policy file?
>
> http://api.twitter.com/crossdomain.xmldoes not allow requests from
Youtube API cross-domain policies - allow connections from all (real)
domains
http://gdata.youtube.com/crossdomain.xml
Google search APIs - allow conection from all domains
http://ajax.googleapis.com/crossdomain.xml
Ebay APIs - allow connection from all domains
http://svcs.ebay.com/crossdomain.xml
Delicious APIs - allow connections from all domains
https://api.del.icio.us/crossdomain.xml
Last.fm APIs - allow connections from all domains
http://ws.audioscrobbler.com/crossdomain.xml
Bing Maps APIs - allow connections from all domains
http://ecn.dev.virtualearth.net/crossdomain.xml
See a trend here?
Zeh
On Oct 18, 3:34 pm, zeh fernando <z...@zehfernando.com> wrote:
> Does Twitter have any plans on when/whether they'll change its current
> cross-domain policy file?
>
> Flash-based websites and web apps because it restricts response to
> twitter.com subdomains.
>
> http://search.twitter.com/crossdomain.xml, however, does allow Flash
> requests from any domain.
>
> This policy pretty much renders all Flash calls to the API useless
> (unless they're search calls).
>
> One could use proxy scripts, but given the limitations imposed by the
> Twitter API (150 calls per IP per hour), it means public websites are
> out of luck if they're getting any kind of public data without
> authenticating like, say, getting a (public) user timeline.
>
> This has been discussed at length in previous threads.
>
> Change in crossdomain.xml??http://groups.google.com/group/twitter-development-talk/browse_thread...
> twitter.com subdomains.
>
> http://search.twitter.com/crossdomain.xml, however, does allow Flash
> requests from any domain.
>
> This policy pretty much renders all Flash calls to the API useless
> (unless they're search calls).
>
> One could use proxy scripts, but given the limitations imposed by the
> Twitter API (150 calls per IP per hour), it means public websites are
> out of luck if they're getting any kind of public data without
> authenticating like, say, getting a (public) user timeline.
>
> This has been discussed at length in previous threads.
>
>
> Most curiously, the above thread mentions on March 2008 that Twitter
> would be moving API calls to api.twitter.com and allowing a more
> permissive crossdomain policy file there in a few months. This hasn't
> happened, though, since people have continued to be dumbfounded by the
> inability to load Twitter data from Flash-based web apps.
>
> Twitter Stream crossdomain.xmlhttp://groups.google.com/group/twitter-development-talk/browse_thread...
> Most curiously, the above thread mentions on March 2008 that Twitter
> would be moving API calls to api.twitter.com and allowing a more
> permissive crossdomain policy file there in a few months. This hasn't
> happened, though, since people have continued to be dumbfounded by the
> inability to load Twitter data from Flash-based web apps.
>
>
> I think this decision is specially questionable as the cross-domain
> restrictions in place do nothing else other than put a tax on what
> people can do from Flash-based web apps, but also allow any other
> usage from any other technology, be it a security issue or not. In
> fact, even using PHP proxies one could make the API calls from Flash
> (albeit in a restricted manner) so I can't see a real reason for
> singling out/blocking this platform.
>
> Normally, public APIs add no such artificial/ineffective restrictions,
> and simply allow any kind of connection (doing their own top of their
> own built-in restrictions and rate limiting)...
>
> http://graph.facebook.com/crossdomain.xml- allows connections from
> all domainshttp://api.flickr.com/crossdomain.xml- allows connections from all
> domainshttp://api.plixi.com/crossdomain.xml- allows connections from all
> domainshttp://api.bit.ly/crossdomain.xml- allows connections from all
> domainshttp://stream.twitvid.com/crossdomain.xml- allows connections from
> I think this decision is specially questionable as the cross-domain
> restrictions in place do nothing else other than put a tax on what
> people can do from Flash-based web apps, but also allow any other
> usage from any other technology, be it a security issue or not. In
> fact, even using PHP proxies one could make the API calls from Flash
> (albeit in a restricted manner) so I can't see a real reason for
> singling out/blocking this platform.
>
> Normally, public APIs add no such artificial/ineffective restrictions,
> and simply allow any kind of connection (doing their own top of their
> own built-in restrictions and rate limiting)...
>
> http://graph.facebook.com/crossdomain.xml- allows connections from
> all domainshttp://api.flickr.com/crossdomain.xml- allows connections from all
> domainshttp://api.plixi.com/crossdomain.xml- allows connections from all
> domainshttp://api.bit.ly/crossdomain.xml- allows connections from all
zeh fernando
Oct 18, 2010, 4:19:54 PM10/18/10
to Twitter Development Talk
Yahoo! maps APIs - allows all domains
http://local.yahooapis.com/crossdomain.xml
Yahoo! search APIs - allows all domains
http://search.yahooapis.com/crossdomain.xml
http://local.yahooapis.com/crossdomain.xml
Yahoo! search APIs - allows all domains
http://search.yahooapis.com/crossdomain.xml
> Does Twitter have any plans on when/whether they'll change its current
> cross-domain policy file?
>
> http://api.twitter.com/crossdomain.xmldoes not allow requests from
> cross-domain policy file?
>
> Flash-based websites and web apps because it restricts response to
> twitter.com subdomains.
>
> http://search.twitter.com/crossdomain.xml, however, does allow Flash
> requests from any domain.
>
> This policy pretty much renders all Flash calls to the API useless
> (unless they're search calls).
>
> One could use proxy scripts, but given the limitations imposed by the
> Twitter API (150 calls per IP per hour), it means public websites are
> out of luck if they're getting any kind of public data without
> authenticating like, say, getting a (public) user timeline.
>
> This has been discussed at length in previous threads.
>
> Change in crossdomain.xml??http://groups.google.com/group/twitter-development-talk/browse_thread...
> twitter.com subdomains.
>
> http://search.twitter.com/crossdomain.xml, however, does allow Flash
> requests from any domain.
>
> This policy pretty much renders all Flash calls to the API useless
> (unless they're search calls).
>
> One could use proxy scripts, but given the limitations imposed by the
> Twitter API (150 calls per IP per hour), it means public websites are
> out of luck if they're getting any kind of public data without
> authenticating like, say, getting a (public) user timeline.
>
> This has been discussed at length in previous threads.
>
>
> Most curiously, the above thread mentions on March 2008 that Twitter
> would be moving API calls to api.twitter.com and allowing a more
> permissive crossdomain policy file there in a few months. This hasn't
> happened, though, since people have continued to be dumbfounded by the
> inability to load Twitter data from Flash-based web apps.
>
> Twitter Stream crossdomain.xmlhttp://groups.google.com/group/twitter-development-talk/browse_thread...
> Most curiously, the above thread mentions on March 2008 that Twitter
> would be moving API calls to api.twitter.com and allowing a more
> permissive crossdomain policy file there in a few months. This hasn't
> happened, though, since people have continued to be dumbfounded by the
> inability to load Twitter data from Flash-based web apps.
>
>
> I think this decision is specially questionable as the cross-domain
> restrictions in place do nothing else other than put a tax on what
> people can do from Flash-based web apps, but also allow any other
> usage from any other technology, be it a security issue or not. In
> fact, even using PHP proxies one could make the API calls from Flash
> (albeit in a restricted manner) so I can't see a real reason for
> singling out/blocking this platform.
>
> Normally, public APIs add no such artificial/ineffective restrictions,
> and simply allow any kind of connection (doing their own top of their
> own built-in restrictions and rate limiting)...
>
> I think this decision is specially questionable as the cross-domain
> restrictions in place do nothing else other than put a tax on what
> people can do from Flash-based web apps, but also allow any other
> usage from any other technology, be it a security issue or not. In
> fact, even using PHP proxies one could make the API calls from Flash
> (albeit in a restricted manner) so I can't see a real reason for
> singling out/blocking this platform.
>
> Normally, public APIs add no such artificial/ineffective restrictions,
> and simply allow any kind of connection (doing their own top of their
> own built-in restrictions and rate limiting)...
>
> http://graph.facebook.com/crossdomain.xml- allows connections from
> all domainshttp://api.flickr.com/crossdomain.xml- allows connections from all
> domainshttp://api.plixi.com/crossdomain.xml- allows connections from all
> domainshttp://api.bit.ly/crossdomain.xml- allows connections from all
> domainshttp://stream.twitvid.com/crossdomain.xml- allows connections from
> all domainshttp://api.flickr.com/crossdomain.xml- allows connections from all
> domainshttp://api.plixi.com/crossdomain.xml- allows connections from all
> domainshttp://api.bit.ly/crossdomain.xml- allows connections from all
Orian Marx (@orian)
Oct 19, 2010, 3:10:47 AM10/19/10
to Twitter Development Talk
Zeh, thanks for taking the time to bring this issue to light again and
to present so many examples of other significant APIs that do not have
restrictive crossdomain policies. As you note, this issue has been
brought to Twitter's attention several times over the last few years
but to no avail.
For my work I continue to have to rely on a PHP proxy for all calls
between my Flash client and Twitter. This is certainly not ideal.
Team Twitter, it's time for you to address this issue. One of the most
popular clients for Twitter out there, TweetDeck, is built with Flash
technology and yet runs as an AIR app I'm guessing in part because
that has a different security model and does not have to deal with
this. You should recognize that there is a large pool of developer
talent that has, over the years, attempted to build wonderful things
on your platform but have thrown up their hands and left due to
frustration with this crossdomain policy. Please stop treating us as
second class developers.
Thanks,
Orian
to present so many examples of other significant APIs that do not have
restrictive crossdomain policies. As you note, this issue has been
brought to Twitter's attention several times over the last few years
but to no avail.
For my work I continue to have to rely on a PHP proxy for all calls
between my Flash client and Twitter. This is certainly not ideal.
Team Twitter, it's time for you to address this issue. One of the most
popular clients for Twitter out there, TweetDeck, is built with Flash
technology and yet runs as an AIR app I'm guessing in part because
that has a different security model and does not have to deal with
this. You should recognize that there is a large pool of developer
talent that has, over the years, attempted to build wonderful things
on your platform but have thrown up their hands and left due to
frustration with this crossdomain policy. Please stop treating us as
second class developers.
Thanks,
Orian
> Does Twitter have any plans on when/whether they'll change its current
> cross-domain policy file?
>
> http://api.twitter.com/crossdomain.xmldoes not allow requests from
> cross-domain policy file?
>
> Flash-based websites and web apps because it restricts response to
> twitter.com subdomains.
>
> http://search.twitter.com/crossdomain.xml, however, does allow Flash
> requests from any domain.
>
> This policy pretty much renders all Flash calls to the API useless
> (unless they're search calls).
>
> One could use proxy scripts, but given the limitations imposed by the
> Twitter API (150 calls per IP per hour), it means public websites are
> out of luck if they're getting any kind of public data without
> authenticating like, say, getting a (public) user timeline.
>
> This has been discussed at length in previous threads.
>
> Change in crossdomain.xml??http://groups.google.com/group/twitter-development-talk/browse_thread...
> twitter.com subdomains.
>
> http://search.twitter.com/crossdomain.xml, however, does allow Flash
> requests from any domain.
>
> This policy pretty much renders all Flash calls to the API useless
> (unless they're search calls).
>
> One could use proxy scripts, but given the limitations imposed by the
> Twitter API (150 calls per IP per hour), it means public websites are
> out of luck if they're getting any kind of public data without
> authenticating like, say, getting a (public) user timeline.
>
> This has been discussed at length in previous threads.
>
>
> Most curiously, the above thread mentions on March 2008 that Twitter
> would be moving API calls to api.twitter.com and allowing a more
> permissive crossdomain policy file there in a few months. This hasn't
> happened, though, since people have continued to be dumbfounded by the
> inability to load Twitter data from Flash-based web apps.
>
> Twitter Stream crossdomain.xmlhttp://groups.google.com/group/twitter-development-talk/browse_thread...
> Most curiously, the above thread mentions on March 2008 that Twitter
> would be moving API calls to api.twitter.com and allowing a more
> permissive crossdomain policy file there in a few months. This hasn't
> happened, though, since people have continued to be dumbfounded by the
> inability to load Twitter data from Flash-based web apps.
>
>
> I think this decision is specially questionable as the cross-domain
> restrictions in place do nothing else other than put a tax on what
> people can do from Flash-based web apps, but also allow any other
> usage from any other technology, be it a security issue or not. In
> fact, even using PHP proxies one could make the API calls from Flash
> (albeit in a restricted manner) so I can't see a real reason for
> singling out/blocking this platform.
>
> Normally, public APIs add no such artificial/ineffective restrictions,
> and simply allow any kind of connection (doing their own top of their
> own built-in restrictions and rate limiting)...
>
> I think this decision is specially questionable as the cross-domain
> restrictions in place do nothing else other than put a tax on what
> people can do from Flash-based web apps, but also allow any other
> usage from any other technology, be it a security issue or not. In
> fact, even using PHP proxies one could make the API calls from Flash
> (albeit in a restricted manner) so I can't see a real reason for
> singling out/blocking this platform.
>
> Normally, public APIs add no such artificial/ineffective restrictions,
> and simply allow any kind of connection (doing their own top of their
> own built-in restrictions and rate limiting)...
>
> http://graph.facebook.com/crossdomain.xml- allows connections from
> all domainshttp://api.flickr.com/crossdomain.xml- allows connections from all
> domainshttp://api.plixi.com/crossdomain.xml- allows connections from all
> domainshttp://api.bit.ly/crossdomain.xml- allows connections from all
> domainshttp://stream.twitvid.com/crossdomain.xml- allows connections from
> all domainshttp://api.flickr.com/crossdomain.xml- allows connections from all
> domainshttp://api.plixi.com/crossdomain.xml- allows connections from all
> domainshttp://api.bit.ly/crossdomain.xml- allows connections from all
zeh fernando
Oct 19, 2010, 10:53:25 AM10/19/10
to Twitter Development Talk
Thanks for the support Orian. I really want to understand why Twitter
is blocking that kind of cross-domain requests, as I believe it just
makes things more difficult, without really blocking what one would
consider a "security issue".
On Oct 19, 3:10 am, "Orian Marx (@orian)" <or...@orianmarx.com> wrote:
> Zeh, thanks for taking the time to bring this issue to light again and
> to present so many examples of other significant APIs that do not have
> restrictive crossdomain policies. As you note, this issue has been
> brought to Twitter's attention several times over the last few years
> but to no avail.
>
> For my work I continue to have to rely on a PHP proxy for all calls
> between my Flash client and Twitter. This is certainly not ideal.
>
> Team Twitter, it's time for you to address this issue. One of the most
> popular clients for Twitter out there, TweetDeck, is built with Flash
> technology and yet runs as an AIR app I'm guessing in part because
> that has a different security model and does not have to deal with
> this. You should recognize that there is a large pool of developer
> talent that has, over the years, attempted to build wonderful things
> on your platform but have thrown up their hands and left due to
> frustration with this crossdomain policy. Please stop treating us as
> second class developers.
>
> Thanks,
> Orian
>
> On Oct 18, 3:34 pm, zeh fernando <z...@zehfernando.com> wrote:
>
> > Does Twitter have any plans on when/whether they'll change its current
> > cross-domain policy file?
>
> >http://api.twitter.com/crossdomain.xmldoesnot allow requests from
> > domainshttp://stream.twitvid.com/crossdomain.xml-allows connections from
is blocking that kind of cross-domain requests, as I believe it just
makes things more difficult, without really blocking what one would
consider a "security issue".
On Oct 19, 3:10 am, "Orian Marx (@orian)" <or...@orianmarx.com> wrote:
> Zeh, thanks for taking the time to bring this issue to light again and
> to present so many examples of other significant APIs that do not have
> restrictive crossdomain policies. As you note, this issue has been
> brought to Twitter's attention several times over the last few years
> but to no avail.
>
> For my work I continue to have to rely on a PHP proxy for all calls
> between my Flash client and Twitter. This is certainly not ideal.
>
> Team Twitter, it's time for you to address this issue. One of the most
> popular clients for Twitter out there, TweetDeck, is built with Flash
> technology and yet runs as an AIR app I'm guessing in part because
> that has a different security model and does not have to deal with
> this. You should recognize that there is a large pool of developer
> talent that has, over the years, attempted to build wonderful things
> on your platform but have thrown up their hands and left due to
> frustration with this crossdomain policy. Please stop treating us as
> second class developers.
>
> Thanks,
> Orian
>
> On Oct 18, 3:34 pm, zeh fernando <z...@zehfernando.com> wrote:
>
> > Does Twitter have any plans on when/whether they'll change its current
> > cross-domain policy file?
>
zeh fernando
Oct 20, 2010, 1:51:26 PM10/20/10
to Twitter Development Talk
MySpace - allows all domains
http://api.myspace.com/crossdomain.xml
> > >http://api.twitter.com/crossdomain.xmldoesnotallow requests from
> > > domainshttp://stream.twitvid.com/crossdomain.xml-allowsconnections from
http://api.myspace.com/crossdomain.xml
Reply all
Reply to author
Forward
0 new messages