I believe it boils down to actual experience and not any hypothetical reasoning, even though my reasoning appears to be correct (as far as I can tell)

If actual experience has shown that the way Flash is doing it is indeed better and leads to higher market penetration for Flash compared to ActiveX then we may throw the counter argument (not matter how valid it may seem) in favor of the successful track record of the current approach, not that an outsider's argument could change anything so basic.

I guess experience always trumps logic ...

(self inculcation in progress)


dos dedos <[EMAIL PROTECTED]> wrote:
That is the reverse of the common philosophy on this issue.

Usually, the end user is "trusted" with the decision because the assumption is that end user is A) not stupid and B) not evil.

Defending all servers out there against the threat of an attack by all Flash clients (irrespective of their intent) means that all Flash clients are presumed guilty unless the server owner decides that they're not, but it is the end user who is able to judge whether a given Flash client is to be trusted or not. The server owner has no way of knowing because they're not the ones downloading the Flash content, the users are.

So if the server owner (e.g. Amazon.com) decides to allow Flash clients to use its API but then they get hacked from a Flash client then they are to blame. And the chance that they would get hacked by a malicious Flash client is higher than the case where the end users get to judge whether a given Flash client can be trusted to exceute or not.

Not trying to be a pain in the butt with my counter argument but I'm trying to probe the status quo to make sure that it makes sense.

:)

dos




Roger Gonzalez <[EMAIL PROTECTED]> wrote:
If I have a server that I want to protect, I don't care whether your SWF is signed, and I don't care whether you granted it permission, I don't want you connecting to me.
 
It doesn't matter what YOU want to approve, it matters what the SERVER wants to approve.
 
-rg


From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of dos dedos
Sent: Monday, March 27, 2006 8:27 PM
To: [email protected]
Subject: RE: [flexcoders] Re: Flex 2: about "potential" HTTPService timeout/security issues ...


In your example the SWF should not be allowed to connect to any server other than the server it was served from! That's by default.

That is unless it is a SIGNED SWF where the end user may allow or deny it's request to execute with full permissions.

If it works for Java and ActiveX it would work equally well for Flash ...

I'm interested in understanding why the way it's done in Flash may be better ...

dos

Roger Gonzalez <[EMAIL PROTECTED]> wrote:
You have the purpose backwards.  (There's an entirely different mechanism for what trust you want to grant to a particular SWF.)
 
The point is for a server owner to prevent you from distributing a SWF that can act as a distributed denial-of-service attack on a server.
 
Consider the case of some web forum that lets you upload a SWF as an image.  Every person who visits the page runs that SWF.  It wou! ld thus be bad if the SWF was allowed to connect to some site that the SWF author wanted to crash.
 
Dig it?
 
-rg
 
 

From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of dos dedos
Sent: Monday, March 27, 2006 7:58 PM
To: [email protected]
Subject: RE: [flexcoders] Re: Flex 2: about "potential" HTTPService timeout/security issues ...

(I'm still in complaining mode)

ActiveX and Java used applet signing to solve this ...

Wouldn't it be better to "respect" the end user's right to choose whether or not to trust a given Flash app to do what it's suppose to do rather than to force the user to install crossdomain on their machine ! or force teh sys admin (in case of LAN) to install cross domain inside the LAN?

How about some security through democracy?

How many times does the average person click OK on a signed applet or ActiveX permission screen and end up regreting it?

dos




Ted Patrick <[EMAIL PROTECTED]> wrote:
1. Delegate security to the server side on a domain/subdomain basis.

2. Enable high and low ports access.

3. Prevent Flash Player from being used as "denial of service" toolset.
Crossdomain.xml has really improved things, it was a great addition to the player at the release of Flash Player 7. I complained about it but eventually I saw the light.

Cheers,

Cynergy Systems, Inc.
Theodore Patrick
Sr. Consultant
[EMAIL PROTECTED]
tel: 1.866.CYNERGY
http://www.cynergysystems.com



________________________________________
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of dos dedos
Sent: Monday, March 27, 2006 6:14 PM
To: [email protected]
Subject: RE: [flexcoders] Re: Flex 2: about "potential" HTTPService timeout/security issues ...

thanks!

bwt, does anyone know what is the security scenario that promoted the introduction of the crossdomain requirement? it would be educating to know

Carson Hager <[EMAIL PROTECTED]> wrote:
You will need a crossdomain file.
�
�

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.2/293 - Release Date: 3/26/2006



Blab-away for as little as 1�/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.


New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low rates.


Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.

YAHOO! GROUPS LINKS





__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com




YAHOO! GROUPS LINKS




Reply via email to