Its very good to hear, I hope he will be able to adress that soon.

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 ;)
>
> >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+
>
> ...
>
> Erfahren Sie mehr »

Reply via email to