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/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.... > >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. > > > > On Mon, Apr 12, 2010 at 5:04 AM, Martin Heidegger <mastakan...@gmail.com > > >wrote: > > > > > To me this step makes very few sense. > > > > > 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 > > > > > > > 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 > > > > > > > > > ofcrossdomain.xml > > > > > > > > > > Did you have plan to put ahttp:// > > > > 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 > > > > > > > > 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. > > > > > -- > > > > To unsubscribe, reply using "remove me" as the subject. > > > > -- > > > Raffi Krikorian > > > Twitter Platform Teamhttp://twitter.com/raffi > > -- > Raffi Krikorian > Twitter Platform Teamhttp://twitter.com/raffi
