w00t
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... > > > 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.commaliciousFlash > > > > 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 > > -- > Raffi Krikorian > Twitter Platform Teamhttp://twitter.com/raffi
