John, thanks for the response. This makes sense.

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 endpoints. For other
discussions of this please see


On Mar 19, 2:17 pm, John Kalucki <> wrote:
> Currently the Streaming API is primarily intended for service to service
> integrations, and we've provisioned 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
> 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
> Infrastructure, Twitter Inc.
> On Fri, Mar 19, 2010 at 8:55 AM, Orian Marx (@orian) 
> <>wrote:
> > Am I interpreting this correct as saying "out of capacity concern
> > 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 <> 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 Kalucki
> > > Infrastructure, Twitter Inc.
> > > On Wed, Mar 17, 2010 at 10:29 AM, TarGz <> wrote:
> > > > hi,
> > > > I have prevriuosly work on 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
> > > > 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
> > To unsubscribe from this group, send email to twitter-development-talk+
> > or reply to this email with the words "REMOVE
> > ME" as the subject.

To unsubscribe from this group, send email to or reply to this email 
with the words "REMOVE ME" as the subject.

Reply via email to