What's the rationale behind cross domain policy for silverlight?_问答_开发者

I got a problem when trying to call a remote rest webservice https://stackoverflow.com/questions/5442175/error-on-httpwebrequest

It seems it's due to cross domain policy file missing on the remote server http://forums.silverlight.net/forums/p/183993/419448.aspx

I don't understand the reason to have this file. It doesn't protect the user at all so for what purpose did they create this restriction ?

UPDATE: Reading the explanation from MS I still fail to see how this policy allows user to be more aware since it's all d开发者_开发知识库one on servers side WITHOUT EVER NOTIFYING THE USER OF ANYTHING.

UPDATE: Seems people don't agree so after all my question is not so stupid :) Answer would be Secure the service not the User ? Why on earth would twitter for example would like to protect its service without even wanting it ? If a website would want to protect itself it would just well put some login / password :) It is obvious that a site wants greatest access from browser it doesn't matter if browser uses plugin or not why would the site care ?

It's for security and making you actually OPT IN to allowing it.

MSDN explains it the best so there is no point in me re-wording it:

Using Silverlight version 4 for cross-domain communication requires guarding against several types of security vulnerability that can be used to exploit Web applications. Cross-site forgery is a class of exploits that becomes a threat when allowing cross-domain calls. This exploit involves a malicious Silverlight control transmitting unauthorized commands to a third-party service, without the user's knowledge. To prevent cross-site request forgery, Silverlight allows only site-of-origin communication by default for all requests other than images and media. For example, a Silverlight control hosted at http://contoso.com/mycontrol.aspx can access only services on that same domain by default – for example http://contoso.com/service.svc, but not a service at http://fabrikam.com/service.svc. This prevents a malicious Silverlight control hosted on the http://contoso.com domain from calling unauthorized operations on a service hosted on the http://fabrikam.com domain.

To enable a Silverlight control to access a service in another domain, the service must explicitly opt-in to allow cross-domain access. By opting-in, a service states that the operations it exposes can safely be invoked by a Silverlight control, without potentially damaging consequences to the data that the service stores.

Here is something to consider. Assume a world where Silverlight did not require a web service to opt into being used by a Silverlight client or a indeed a Flash client come to that.

Some malcontent manages to find a weakness in a popular web service API and writes an exploit in Silverlight or Flash. Harm is done and users of this web service are upset. Where might the finger of responsibility get pointed? What happens when it gets into the news that a Silverlight or Flash plugin was the "cause" of some breach? Whose reputation is harmed? Answer: Microsoft / Adobe even though in fact it has nothing to do with them.

Ultimately this is about public relations, about the risk of there being a perceived insecurity where none is really warranted.

By including this opt-in requirement these companies massively reduce the number of services that could possibly be exploited using their plugins. Significantly reducing the risk that their plugin would unfairly be tarnished with an uncalled for reputation. For those that do opt-in the policy files can be pointed at as the responsibility of the service provider who made an informed choice to include such a file.

Ultimately if there is a choice between risking your public perception with 100,000,000 potential users or risk some disgruntlement and bewilderment of some 100,000 potential developers I know which one I would pick.

Imagine you have a webservice, which is on your website, it displays live stocks and you want this website to be used by only your silverlight client.

Now I can write a silverlight client and put it on my website that will fetch data from your website, I can steal your data and users will feel it's my data. As there is no way o determine who is connecting it.

So silverlight loaded from my domain will not connect unless you allow from your domain. This is not for server client security but this is for cross domain security. Same as JavaScript cross domain security that you can not access any objects loaded from different domain.