FlashPlayer 8.5 will support binary sockets, which (I think) wont check 
for crossdomain.xml.
crossdomain.xml is in no way security. It's merely prevents 'the regular 
user' from consuming other people's services, but I doesn't stop a 
malicious user.

In any case, client-side security is no security and should reside on 
the server. Compare it to a "don't walk on the grass"-sign. It keeps the 
good people on the right path, but won't stop someone who intentionally 
want to do it anyway.

Evert

Michael Hansen wrote:
> Crossdomain policy file is necessary for enterprises.
>
> Consider this scenario:
>
> Network:
> secretary PC <-> Enterprise LAN <-> some security measure(firewall 
> etc) <-> internet
>
> Secretary browse to ' ariaware.com <http://ariaware.com>'.
>
> On ariaware.com <http://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 <http://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 <http://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] 
> <mailto:[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
>     osflash@osflash.org <mailto:osflash@osflash.org>
>     http://osflash.org/mailman/listinfo/osflash_osflash.org
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> osflash mailing list
> osflash@osflash.org
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>   


_______________________________________________
osflash mailing list
osflash@osflash.org
http://osflash.org/mailman/listinfo/osflash_osflash.org

Reply via email to