crossdomain

[Tzahi Sofer]

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.

[John Kalucki]

Search team is aware of the issue. Working on it. I don't have an
update from them yet.

-John

[johnny...@mac.com]

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

[Raffi Krikorian]

> Also any news on the new location of this file yet?

there won't be a new location of the file - we should be getting it
back live in a bit!

--
Raffi Krikorian
Twitter Platform Team
ra...@twitter.com | @raffi

[codewarrior415]

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.

[John Adams]

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

[codewarrior415]

<?xml version="1.0" encoding="UTF-8"?>
<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/
schemas/PolicyFile.xsd">
<allow-access-from domain="twitter.com" />
<allow-access-from domain="api.twitter.com" />
<allow-access-from domain="search.twitter.com" />
<allow-access-from domain="static.twitter.com" />
<site-control permitted-cross-domain-policies="master-only"/>
<allow-http-request-headers-from domain="*.twitter.com" headers="*"
secure="true"/>
</cross-domain-policy>

Correct me if I am wrong here, but it seems like you guys are allowing
access to yourself only. Can I request for my domain to be added on
this list? So basically you guys are blocking everyone from accessing
your API via Flex or Flash. I don't believe this is the same
configuration as last week. If it was, then our application would not
be throwing errors.

[guytom]

Search API used to be open to Flash (and other) web applications could
use it without using some proxy server.

This change you made is a major change, that now requires all such
flash applications to maintain a proxy server.

Is this a final decision? You should at least notify about something
like this in advance, our applications and many others just wont work!

Guy

[Marauderz]

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.

[codewarrior415]

What are we left to do now?

On Nov 5, 4:08 pm, John Adams <j...@twitter.com> wrote:

[Kent]

Hi John. Twitter definitely had the search.twitter.com domain open
to crossdomain requests to its API for a long time as I've been
building Flash widgets that could talk to it directly (no matter what
domain they had been posted to) since its inception, so this is a real
disappointment that Twitter has decided to remove all access to Flash
widgets and applications. It is very clear why Twitter limits the
crossdomain policy for the twitter.com domain, but it is not at all
clear why you would apply the same policy to the *search* domain. Is
there anything that I can do to get Twitter to reconsider this policy
change?

[Tim Heuer]

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

[Raffi Krikorian]

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.

--

[Tim Heuer]

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

[orian]

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

[bytespider]

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.

> >> 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