Hi,
Aral wrote: "I've never fully
understood the need for the crossdomain policy file."
I don't have much to add to Michael's response, but
since the thread got so long and meandering, I wanted to make sure Michael's
response was available with a clear subject line. Without this security
policy, the Flash Player would be easy to exploit with
malware.
Arals adds: "It seems to me to be a
artificial restriction aimed at selling more server
licenses."
As the guy whose job it is (among other things) to sell
server licenses -;) that's not on our radar Aral. We do include a
serverside proxy with Flex, but this is not something that is a barrier to
use. Anyone serverside developer could write their own proxy, it is a
pretty minor piece of the product and doesn't require our software at all. We
actively evangelize folks with public APIs like Yahoo, Amazon, FlickR etc to
implement the cross-domain policy file so that no one needs a server side proxy
at all for those. We'll keep doing that.
-David
Crossdomain policy file is necessary for enterprises.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Hansen
Sent: Tuesday, January 31, 2006 7:18 AM
To: Open Source Flash Mailing List
Subject: Re: [osflash] [Slightly OT] Gnash & the security model
Consider this scenario:
Network:
secretary PC <-> Enterprise LAN <-> some security measure(firewall etc) <-> internet
Secretary browse to ' ariaware.com'.
On ariaware.com is a malware flash animation. This flash is downloaded, and executed/running in a web container (e.g. activeX) on the _secretaries computer_ which is _behind_ the firewall.
Now imagine that there's no crossdomain policy file scheme.
Imageine also that the malware swf contains a port scanner implemented via xml socket or similar. It can probe the enterprise LAN, connect and extract information, and finally route that information to ariaware.com. The secretary would never know.
However, if you implement a cross domain policy file scheme, this will never happen, or only if the local servers on the enterprise LAN intend it to happen (opt-in).
Note also that e.g. asp.net does not have this problem since it's all post-back to the server, and nothing runs locally.
It sucks big time, but the security model is vital if flash is not to be banned from enterprise browsers. An alternative would be to make it opt-out, but you'll never get network admins to flush crossdomain files all over the place to block flash from connecting.
cheers
-michael
Most enterprices don't let users be admin. They the it
On 1/31/06, Aral Balkan < [EMAIL PROTECTED]> wrote:Hi Alias,
I've never fully understood the need for the crossdomain policy file. I
think it was Sho who tried to explain it to me in a very technical
manner but either I'm really thick (definite possibility) or I just
don't get the value of something where you essentially need to disable
the security via a crossdomain.xml file to get something like web
services to work without the need of a proxy. It seems to me to be a
artificial restriction aimed at selling more server licenses. It also is
a major handicap for Flash when compared to Java and rules out the
creation of a whole host of applications in Flash (like a POP3/IMAP
email reader that can check email from any domain.) "Sure it'll work,
just ask your ISP to put a crossdomain.xml file in their root... Ummm,
what?"
All that said, I'm personally worried about the impact of several,
incompatible, Flash player implementations and how that will affect the
reputation of the Flash Platform. Currently, Flash is pretty much a
write-once, run-anywhere platform and that's one of its (if not its
greatest) unique selling point. (Maintaining state on the client was
too, but "AJAX" apps can do that too now.) I'm worried that competing
players will confuse developers and users alike. I'm even worried about
the increasing rate of change in the release of Macromedia Players,
especially the pre-release ones (8, followed a few months later by alpha
8.5, beta 8.5?, 8.5?, etc.) I believe that *stability* in the player is
very important.
Aral
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
