[twitter-dev] Re: crossdomain
Is it possible to use pre-flighting? Sending the OPTIONS method first with the request we intend on performing, and api.twitter.com responding with the appropriate response code if they deem our transaction safe? http://www.w3.org/TR/access-control/ On Nov 7, 4:38 pm, Raffi Krikorian ra...@twitter.com wrote: hi tim. thecrossdomain.xml file is now open an unrestricted to search. in the future, as part of the migration to api.twitter.com for API endpoints, we may consider relaxing acrossdomain.xml policy on that. John I'm with others here that this represents a significant change to the operation of the API and has affected numerous applications and samples, etc. Frankly I wish Twitter would really understand x-domain policy files better. If there is a concern around security, then address it and don't allow *user* changes on the API domain root. I fully understand the reason for x-domain policies as we need them for Silverlight as well -- and appreciate how they help mitigate the attack surface. But especially for Search, which is an unauthenticated API it doesn't make sense. Having twitter segment their API (or provide a different endpoint for RIA clients that has the security risk mitigation in place) seems to make sence. That's exactly what others (Yahoo, Microsoft, etc.) do -- instead of hanging their API off of the end- user application it is segmented (i.e., yahooapis.com or api.twitter.com) so as to help the security threat surface. Twitter doesn't block domains from using the services otherwise and having a x-domain policy in place that is DIFFERENT than what is allowed in the API in general is very confusing to the developer audience. Please change the Search API back ASAP as that in the short-term has the greatest negative effect on a lot of applications that relied on it and are now affected TWICE in one week without notification. Users of the transactional API always knew from the very beginning about the x-domain policy file (even though it, too, went through a change early on), but the Search API hasn't been like this for a long time. Consider your developer audience in the short-term while you consider a longer-term solution. And until then, provide us with a phase-out plan instead of a complete shut-off which negatively affects us and our customers. I understand Twitter is a free service and such has the typical SLA that comes along with free. But it has been an invaluable service to your customers and ours -- I also agree with others that making these announcements BEFORE the changes on status.twitter.com and these lists as well as the official API announce is essential. There has only been answers on these issues based on questions -- nothing pro-active from your team about the changes or what is going on. -th On Nov 6, 7:35 am, Marauderz maraud...@gmail.com wrote: John, Even before last week, our Flash apps could always access search.twitter.com. means that thecrossdomain.xml had always allowed universal access before. So it is NOT the same state that it was last week. The change in thecrossdomain.xml will mean that all the Flash, Silverlight and any other platform that respects acrossdomain.xml file are now essentially broken by this change. I understand the concerns for security, but maybe you could then think of setting up another domain for RIA app search use instead then? In any case, a lot of twitter apps have just been silenced because of thiscrossdomain.xml change. On Nov 6, 8:08 am, John Adams j...@twitter.com wrote: On Nov 5, 2009, at 3:32 PM, codewarrior415 wrote: OK, thecrossdomainpolicy now only allows your flex application to access the API. You are not allowing flex appication access your API? How come the change again today. This morning it was working fine. twitter.com'scrossdomain.xml is exactly the same as it was last week, it was restored from the original configuration. The search.twitter.comcrossdomain.xml policy was incorrectly set to permit from all sites for all actions. We've configured that to be identical to the twitter.com crossdomain.xml to prevent CSRF, session fixation, and attacks on user accounts, which is a major security issue which Facebook and Myspace fell to earlier this week. Could you describe what you are trying to do and we'll research? -john -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: crossdomain
Please keep us updated w/ discussion on relaxing the crossdomain policy on api.twitter.com. Currently it is impossible to build full featured in-browser Flash clients for Twitter without using a proxy, which is part of the reason so many of them are desktop AIR apps. Twitter is doing itself a disservice by blocking API access to a large number of developers. Please see this thread of Flash developers asking for this: http://groups.google.com/group/twitter-development-talk/browse_frm/thread/e35a708400b529b3 On Nov 7, 11:38 am, Raffi Krikorian ra...@twitter.com wrote: hi tim. the crossdomain.xml file is now open an unrestricted to search. in the future, as part of the migration to api.twitter.com for API endpoints, we may consider relaxing a crossdomain.xml policy on that. John I'm with others here that this represents a significant change to the operation of the API and has affected numerous applications and samples, etc. Frankly I wish Twitter would really understand x-domain policy files better. If there is a concern around security, then address it and don't allow *user* changes on the API domain root. I fully understand the reason for x-domain policies as we need them for Silverlight as well -- and appreciate how they help mitigate the attack surface. But especially for Search, which is an unauthenticated API it doesn't make sense. Having twitter segment their API (or provide a different endpoint for RIA clients that has the security risk mitigation in place) seems to make sence. That's exactly what others (Yahoo, Microsoft, etc.) do -- instead of hanging their API off of the end- user application it is segmented (i.e., yahooapis.com or api.twitter.com) so as to help the security threat surface. Twitter doesn't block domains from using the services otherwise and having a x-domain policy in place that is DIFFERENT than what is allowed in the API in general is very confusing to the developer audience. Please change the Search API back ASAP as that in the short-term has the greatest negative effect on a lot of applications that relied on it and are now affected TWICE in one week without notification. Users of the transactional API always knew from the very beginning about the x-domain policy file (even though it, too, went through a change early on), but the Search API hasn't been like this for a long time. Consider your developer audience in the short-term while you consider a longer-term solution. And until then, provide us with a phase-out plan instead of a complete shut-off which negatively affects us and our customers. I understand Twitter is a free service and such has the typical SLA that comes along with free. But it has been an invaluable service to your customers and ours -- I also agree with others that making these announcements BEFORE the changes on status.twitter.com and these lists as well as the official API announce is essential. There has only been answers on these issues based on questions -- nothing pro-active from your team about the changes or what is going on. -th On Nov 6, 7:35 am, Marauderz maraud...@gmail.com wrote: John, Even before last week, our Flash apps could always access search.twitter.com. means that the crossdomain.xml had always allowed universal access before. So it is NOT the same state that it was last week. The change in the crossdomain.xml will mean that all the Flash, Silverlight and any other platform that respects a crossdomain.xml file are now essentially broken by this change. I understand the concerns for security, but maybe you could then think of setting up another domain for RIA app search use instead then? In any case, a lot of twitter apps have just been silenced because of this crossdomain.xml change. On Nov 6, 8:08 am, John Adams j...@twitter.com wrote: On Nov 5, 2009, at 3:32 PM, codewarrior415 wrote: OK, the crossdomain policy now only allows your flex application to access the API. You are not allowing flex appication access your API? How come the change again today. This morning it was working fine. twitter.com's crossdomain.xml is exactly the same as it was last week, it was restored from the original configuration. The search.twitter.com crossdomain.xml policy was incorrectly set to permit from all sites for all actions. We've configured that to be identical to the twitter.com crossdomain.xml to prevent CSRF, session fixation, and attacks on user accounts, which is a major security issue which Facebook and Myspace fell to earlier this week. Could you describe what you are trying to do and we'll research? -john -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: crossdomain
hi tim. the crossdomain.xml file is now open an unrestricted to search. in the future, as part of the migration to api.twitter.com for API endpoints, we may consider relaxing a crossdomain.xml policy on that. John I'm with others here that this represents a significant change to the operation of the API and has affected numerous applications and samples, etc. Frankly I wish Twitter would really understand x-domain policy files better. If there is a concern around security, then address it and don't allow *user* changes on the API domain root. I fully understand the reason for x-domain policies as we need them for Silverlight as well -- and appreciate how they help mitigate the attack surface. But especially for Search, which is an unauthenticated API it doesn't make sense. Having twitter segment their API (or provide a different endpoint for RIA clients that has the security risk mitigation in place) seems to make sence. That's exactly what others (Yahoo, Microsoft, etc.) do -- instead of hanging their API off of the end- user application it is segmented (i.e., yahooapis.com or api.twitter.com) so as to help the security threat surface. Twitter doesn't block domains from using the services otherwise and having a x-domain policy in place that is DIFFERENT than what is allowed in the API in general is very confusing to the developer audience. Please change the Search API back ASAP as that in the short-term has the greatest negative effect on a lot of applications that relied on it and are now affected TWICE in one week without notification. Users of the transactional API always knew from the very beginning about the x-domain policy file (even though it, too, went through a change early on), but the Search API hasn't been like this for a long time. Consider your developer audience in the short-term while you consider a longer-term solution. And until then, provide us with a phase-out plan instead of a complete shut-off which negatively affects us and our customers. I understand Twitter is a free service and such has the typical SLA that comes along with free. But it has been an invaluable service to your customers and ours -- I also agree with others that making these announcements BEFORE the changes on status.twitter.com and these lists as well as the official API announce is essential. There has only been answers on these issues based on questions -- nothing pro-active from your team about the changes or what is going on. -th On Nov 6, 7:35 am, Marauderz maraud...@gmail.com wrote: John, Even before last week, our Flash apps could always access search.twitter.com. means that the crossdomain.xml had always allowed universal access before. So it is NOT the same state that it was last week. The change in the crossdomain.xml will mean that all the Flash, Silverlight and any other platform that respects a crossdomain.xml file are now essentially broken by this change. I understand the concerns for security, but maybe you could then think of setting up another domain for RIA app search use instead then? In any case, a lot of twitter apps have just been silenced because of this crossdomain.xml change. On Nov 6, 8:08 am, John Adams j...@twitter.com wrote: On Nov 5, 2009, at 3:32 PM, codewarrior415 wrote: OK, the crossdomain policy now only allows your flex application to access the API. You are not allowing flex appication access your API? How come the change again today. This morning it was working fine. twitter.com's crossdomain.xml is exactly the same as it was last week, it was restored from the original configuration. The search.twitter.com crossdomain.xml policy was incorrectly set to permit from all sites for all actions. We've configured that to be identical to the twitter.com crossdomain.xml to prevent CSRF, session fixation, and attacks on user accounts, which is a major security issue which Facebook and Myspace fell to earlier this week. Could you describe what you are trying to do and we'll research? -john -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: crossdomain
Thanks Raffi for doing this. Honestly, I really really thank you for this. I would love for the Twitter API team to engage with RIA client providers on establishing open, but secure cross-domain policy files. I know that since crossdomain.xml isn't a standard, each RIA client provider is implementing their own. For Silverlight we have a similar structure, but one that affords pretty good control from the provider while still enabling open access to developers. I would love for you to consider Silverlight's cross-domain policy for api.twitter.com as well. Please feel free to contact me offline and I can provide details on this and help understand the benefits to Twitter and how you can best implement the policy. Thanks again, -th Tim Heuer Microsoft Silverlight On Nov 7, 9:38 am, Raffi Krikorian ra...@twitter.com wrote: hi tim. the crossdomain.xml file is now open an unrestricted to search. in the future, as part of the migration to api.twitter.com for API endpoints, we may consider relaxing a crossdomain.xml policy on that. John I'm with others here that this represents a significant change to the operation of the API and has affected numerous applications and samples, etc. Frankly I wish Twitter would really understand x-domain policy files better. If there is a concern around security, then address it and don't allow *user* changes on the API domain root. I fully understand the reason for x-domain policies as we need them for Silverlight as well -- and appreciate how they help mitigate the attack surface. But especially for Search, which is an unauthenticated API it doesn't make sense. Having twitter segment their API (or provide a different endpoint for RIA clients that has the security risk mitigation in place) seems to make sence. That's exactly what others (Yahoo, Microsoft, etc.) do -- instead of hanging their API off of the end- user application it is segmented (i.e., yahooapis.com or api.twitter.com) so as to help the security threat surface. Twitter doesn't block domains from using the services otherwise and having a x-domain policy in place that is DIFFERENT than what is allowed in the API in general is very confusing to the developer audience. Please change the Search API back ASAP as that in the short-term has the greatest negative effect on a lot of applications that relied on it and are now affected TWICE in one week without notification. Users of the transactional API always knew from the very beginning about the x-domain policy file (even though it, too, went through a change early on), but the Search API hasn't been like this for a long time. Consider your developer audience in the short-term while you consider a longer-term solution. And until then, provide us with a phase-out plan instead of a complete shut-off which negatively affects us and our customers. I understand Twitter is a free service and such has the typical SLA that comes along with free. But it has been an invaluable service to your customers and ours -- I also agree with others that making these announcements BEFORE the changes on status.twitter.com and these lists as well as the official API announce is essential. There has only been answers on these issues based on questions -- nothing pro-active from your team about the changes or what is going on. -th On Nov 6, 7:35 am, Marauderz maraud...@gmail.com wrote: John, Even before last week, our Flash apps could always access search.twitter.com. means that the crossdomain.xml had always allowed universal access before. So it is NOT the same state that it was last week. The change in the crossdomain.xml will mean that all the Flash, Silverlight and any other platform that respects a crossdomain.xml file are now essentially broken by this change. I understand the concerns for security, but maybe you could then think of setting up another domain for RIA app search use instead then? In any case, a lot of twitter apps have just been silenced because of this crossdomain.xml change. On Nov 6, 8:08 am, John Adams j...@twitter.com wrote: On Nov 5, 2009, at 3:32 PM, codewarrior415 wrote: OK, the crossdomain policy now only allows your flex application to access the API. You are not allowing flex appication access your API? How come the change again today. This morning it was working fine. twitter.com's crossdomain.xml is exactly the same as it was last week, it was restored from the original configuration. The search.twitter.com crossdomain.xml policy was incorrectly set to permit from all sites for all actions. We've configured that to be identical to the twitter.com crossdomain.xml to prevent CSRF, session fixation, and attacks on user accounts, which is a major security issue which Facebook and Myspace fell to earlier this week. Could you describe what you are trying to do and we'll
[twitter-dev] Re: crossdomain
OK, the crossdomain policy now only allows your flex application to access the API. You are not allowing flex appication access your API? How come the change again today. This morning it was working fine. On Nov 4, 9:30 am, John Kalucki jkalu...@gmail.com wrote: Search team is aware of the issue. Working on it. I don't have an update from them yet. -John On Nov 4, 8:56 am, Tzahi Sofer tzahi.so...@gmail.com wrote: Hi, I get a 404 on calls to search.twitter.com/crossdomain.xml. It's been like this since last night. any ideas? Thanks, Tzahi.
[twitter-dev] Re: crossdomain
Search team is aware of the issue. Working on it. I don't have an update from them yet. -John On Nov 4, 8:56 am, Tzahi Sofer tzahi.so...@gmail.com wrote: Hi, I get a 404 on calls to search.twitter.com/crossdomain.xml. It's been like this since last night. any ideas? Thanks, Tzahi.
[twitter-dev] Re: crossdomain
Can you guys do a better job of reporting such issues (intentional or not) on the status.twitter.com page? Also any news on the new location of this file yet? Thanks, Johnny On Nov 4, 12:30 pm, John Kalucki jkalu...@gmail.com wrote: Search team is aware of the issue. Working on it. I don't have an update from them yet. -John On Nov 4, 8:56 am, Tzahi Sofer tzahi.so...@gmail.com wrote: Hi, I get a 404 on calls to search.twitter.com/crossdomain.xml. It's been like this since last night. any ideas? Thanks, Tzahi.
