Twitter Stream crossdomain.xml
TarGz
I have prevriuosly work on twittearth.com and now I work a project
that use the stream API.
The stream API work very well, it is very responsive and powerfull and
help me build a realtime geolocated search tool...
The bad sing is that my Flash app only work offline because of the lak
of crossdomain.xml
Did you have plan to put a http://sream.twitter.com/crossdomain.xml
file live soon ? because I love to share my tools with the world.
Thank per advance for your answer(s)
Looking forward for your reply
John Kalucki
-John Kalucki
http://twitter.com/jkalucki
Infrastructure, Twitter Inc.
Orian Marx (@orian)
we're currently blocking Flash developers"? The crossdomain.xml issue
has been extremely frustrating across all of Twitter's service
endpoints and if I'm interpreting this post correctly this just adds
to a series of poor choices Twitter has made in regard to Flash
developers in my opinion. If this service needs to be limited for
capacity reasons it should be limited in the same way regardless of
what technology you are using to make requests of the API.
-Orian Marx
Flex Developer
On Mar 17, 1:50 pm, John Kalucki <j...@twitter.com> wrote:
> It's in the code, but turned off out of an abundance of caution for capacity
> reasons. Given our current plans, it's going to be a little while longer
> before we can turn this on.
>
> -John Kaluckihttp://twitter.com/jkalucki
> Infrastructure, Twitter Inc.
>
>
>
> On Wed, Mar 17, 2010 at 10:29 AM, TarGz <julien.ter...@gmail.com> wrote:
> > hi,
>
> > I have prevriuosly work on twittearth.com and now I work a project
> > that use the stream API.
> > The stream API work very well, it is very responsive and powerfull and
> > help me build a realtime geolocated search tool...
>
> > The bad sing is that my Flash app only work offline because of the lak
> > of crossdomain.xml
>
> > Did you have plan to put ahttp://sream.twitter.com/crossdomain.xml
John Kalucki
A single Hosebird process can pump out a lot of data. A cluster of them is a bit like a bull in a china shop. We want to avoid a success catastrophe where a set of popular clients releases all at once and inadvertently overwhelms the service and potentially knocks integrations and/or non-trivial slice of www traffic offline. This would be bad for everyone, including open experimental access. So, among a dozen other disabled features, crossdomain.xml is also off on stream.twitter.com.
We're working on this right now. Please have patience.
The crossdomain.xml policy on other endpoints is the doing of others, and I don't remember all the details. Please trust that the policies chosen were made with user privacy and user security as the primary concerns.
-John Kalucki
To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Orian Marx (@orian)
While I do trust that the existing crossdomain.xml policies were
implemented out of a *concern* for user privacy and security, I don't
believe they should remain as they currently are, and while the issue
has been repeatedly brought to attention in this forum it has never
had an official response other than "we're thinking about it". I think
a lot of Flash developers have been very patient with Twitter in this
regard. Keep in mind we're not talking about some particular service
call on an API being unavailable, but rather the entire non-search
Twitter API.
Twitter has addressed security concerns very well through OAuth. There
is really no reason Flash apps should be restricted if they are making
OAuth calls to the new api.twitter.com endpoints. For other
discussions of this please see
http://groups.google.com/group/twitter-development-talk/browse_frm/thread/e35a708400b529b3
and http://groups.google.com/group/twitter-development-talk/browse_frm/thread/d3230be66c27c88e?hl=en&tvc=1
-Orian
On Mar 19, 2:17 pm, John Kalucki <j...@twitter.com> wrote:
> Currently the Streaming API is primarily intended for service to service
> integrations, and we've provisioned stream.twitter.com as such. We've also
> opened it up for all sorts of open-ended experimentation as well. However,
> we've asked large-scale deployments, such desktop apps and widgets, to hold
> off on releasing products against the Streaming API until we can provide a
> few more features (oAuth, etc.), provide sufficient capacity, and fully
> isolate desktop traffic from integration traffic.
>
> A single Hosebird process can pump out a lot of data. A cluster of them is a
> bit like a bull in a china shop. We want to avoid a success catastrophe
> where a set of popular clients releases all at once and inadvertently
> overwhelms the service and potentially knocks integrations and/or
> non-trivial slice of www traffic offline. This would be bad for everyone,
> including open experimental access. So, among a dozen other disabled
> features, crossdomain.xml is also off on stream.twitter.com.
>
> We're working on this right now. Please have patience.
>
> The crossdomain.xml policy on other endpoints is the doing of others, and I
> don't remember all the details. Please trust that the policies chosen were
> made with user privacy and user security as the primary concerns.
>
Martin Heidegger
This API is already public - all data served by this api is public -
flash programmers or not.
Programmers start to create "twitter.api" proxys infrastructure that
reads data from this api
and serves just to work around the crossdomain.xml. It is also
possible to work-around this
with javascript bridges. With some around-the-corner-thinking most
flash applications should
work.
To me this is unnecessary hazzle for a lot of developers that doesn't
really stop them doing anything
that they would without this restriction (well - it might reduce the
responsetime and the quality of their applications).
And for what? To avoid or some temporary load difficulties? This API
is online/live for more
than a year now. I hope you reconcider opening it soon.
yours
Martin.
On Mar 19, 8:53 pm, "Orian Marx (@orian)" <or...@orianmarx.com> wrote:
> John, thanks for the response. This makes sense.
>
> While I do trust that the existingcrossdomain.xml policies were
> implemented out of a *concern* for user privacy and security, I don't
> believe they should remain as they currently are, and while the issue
> has been repeatedly brought to attention in this forum it has never
> had an official response other than "we're thinking about it". I think
> a lot of Flash developers have been very patient with Twitter in this
> regard. Keep in mind we're not talking about some particular service
> call on an API being unavailable, but rather the entire non-search
> Twitter API.
>
> Twitter has addressed security concerns very well through OAuth. There
> is really no reason Flash apps should be restricted if they are making
> OAuth calls to the new api.twitter.com endpoints. For other
> discussions of this please seehttp://groups.google.com/group/twitter-development-talk/browse_frm/th...
> andhttp://groups.google.com/group/twitter-development-talk/browse_frm/th...
>
> -Orian
>
> On Mar 19, 2:17 pm, John Kalucki <j...@twitter.com> wrote:
>
> > Currently the Streaming API is primarily intended for service to service
> > integrations, and we've provisioned stream.twitter.com as such. We've also
> > opened it up for all sorts of open-ended experimentation as well. However,
> > we've asked large-scale deployments, such desktop apps and widgets, to hold
> > off on releasing products against the Streaming API until we can provide a
> > few more features (oAuth, etc.), provide sufficient capacity, and fully
> > isolate desktop traffic from integration traffic.
>
> > A single Hosebird process can pump out a lot of data. A cluster of them is a
> > bit like a bull in a china shop. We want to avoid a success catastrophe
> > where a set of popular clients releases all at once and inadvertently
> > overwhelms the service and potentially knocks integrations and/or
> > non-trivial slice of www traffic offline. This would be bad for everyone,
> > including open experimental access. So, among a dozen other disabled
> > features,crossdomain.xml is also off on stream.twitter.com.
>
> > We're working on this right now. Please have patience.
>
> > Thecrossdomain.xml policy on other endpoints is the doing of others, and I
> > don't remember all the details. Please trust that the policies chosen were
> > made with user privacy and user security as the primary concerns.
>
> > -John Kaluckihttp://twitter.com/jkalucki
> > Infrastructure, Twitter Inc.
>
> > On Fri, Mar 19, 2010 at 8:55 AM, Orian Marx (@orian) <or...@orianmarx.com>wrote:
>
> > > Am I interpreting this correct as saying "out of capacity concern
> > > we're currently blocking Flash developers"? Thecrossdomain.xml issue
Raffi Krikorian
- there should be a very permissive crossdomain.xml file on search.twitter.com;
- the firehose does not host a crossdomain.xml file for its production usage; and
- twitter.com and api.twitter.com have restrictive crossdomain.xml files.
--To unsubscribe, reply using "remove me" as the subject.
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
Orian Marx (@orian)
I believe it is possible to do nasty things using the crossdomain.xml
file, just as it is possible to do nasty things with lots of other
approaches. My understanding is that having a separate domain for the
api now significantly reduces any security risks of placing an
unrestricted policy file on that domain. The main issue I think was
that when the api was served off of www.twitter.com malicious Flash
code could potentially get at user's cookies from any browser sessions
from visiting www.twitter.com. There aren't any cookies kept for
visits to api.twitter.com. Oh and lets not forget OAuth has been added
now. These policies were in place since before OAuth was in effect I
believe.
Here are two resources that should be passed to your security team:
http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html
http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html
I will definitely be pushing for this to be addressed at Chirp, so it
would be great if someone could start looking into it now :-)
On Apr 12, 10:03 am, Raffi Krikorian <ra...@twitter.com> wrote:
> - there should be a very permissive crossdomain.xml file on
> search.twitter.com;
> - the firehose does not host a crossdomain.xml file for its production
> usage; and
> - twitter.com and api.twitter.com have restrictive crossdomain.xml
> files.
>
> to my understanding (but correct me if i'm wrong), it is possible to do some
> nasty things regarding cookies between web applications when crossdomain.xml
> files get involved. twitter.com will probably remain to have a restrictive
> policy, but we have wanted for a while (but haven't gotten around to it yet)
> to do a security audit of api.twitter.com before relaxing the file there. i
> apologise for the inconvenience.
>
Raffi Krikorian
Orian Marx (@orian)
you're not convinced will remain secure. Just remember you and I
started this conversation six months ago ;)
http://groups.google.com/group/twitter-development-talk/browse_frm/thread/d3230be66c27c88e
On Apr 12, 11:43 am, Raffi Krikorian <ra...@twitter.com> wrote:
> as i said, unfortunately, i'm not comfortable relaxing the crossdomain file
> on api.twitter.com until we more carefully analyze our own stack that is
> running there. we completely agree with your statements here, and we will
> gladly listen to anybody who wants us to relax the file -- but, you're all
> preaching to the choir :P we want to relax the file! to be responsible, we
> need to carefully analyze our stack and write a few test cases first.
>
> On Mon, Apr 12, 2010 at 8:34 AM, Orian Marx (@orian) <or...@orianmarx.com>wrote:
>
>
>
>
>
> > I'm no security expert, but this continues to make little sense to me.
> > I believe it is possible to do nasty things using the crossdomain.xml
> > file, just as it is possible to do nasty things with lots of other
> > approaches. My understanding is that having a separate domain for the
> > api now significantly reduces any security risks of placing an
> > unrestricted policy file on that domain. The main issue I think was
> > that when the api was served off ofwww.twitter.commalicious Flash
> > code could potentially get at user's cookies from any browser sessions
> > from visitingwww.twitter.com. There aren't any cookies kept for
> > visits to api.twitter.com. Oh and lets not forget OAuth has been added
> > now. These policies were in place since before OAuth was in effect I
> > believe.
>
> > Here are two resources that should be passed to your security team:
> >http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy....
Raffi Krikorian
Orian Marx (@orian)
On Apr 12, 12:29 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> yup - totally :P just giving you an update that its been low on our
> priority list :P
>
> twitter now has a dedicated security manager, so i have just elevated this
> to his attention.
>
> On Mon, Apr 12, 2010 at 9:27 AM, Orian Marx (@orian) <or...@orianmarx.com>wrote:
>
>
>
>
>
> > Totally understood. You shouldn't be relaxing any security on anything
> > you're not convinced will remain secure. Just remember you and I
> > started this conversation six months ago ;)
>
> >http://groups.google.com/group/twitter-development-talk/browse_frm/th...
Martin Heidegger
yours
Martin
On 12 Apr., 18:29, Raffi Krikorian <ra...@twitter.com> wrote:
> yup - totally :P just giving you an update that its been low on our
> priority list :P
>
> twitter now has a dedicated security manager, so i have just elevated this
> to his attention.
>
> On Mon, Apr 12, 2010 at 9:27 AM, Orian Marx (@orian) <or...@orianmarx.com>wrote:
>
> > Totally understood. You shouldn't be relaxing any security on anything
> > you're not convinced will remain secure. Just remember you and I
> > started this conversation six months ago ;)
>
>
> Erfahren Sie mehr »