Fair enough. It may not be the first time they do it and maybe it's not a
Macromedia vs Adobe thing (it seems as though they used to be more careful
about backwards compatibility in the past, though).
(And by the way, what I said about crossdomains was not 100% accurate as I
messed up with the FP actual versions, but hopefully you got the idea and
the example is still valid)

Anyway, I still stand by my point. They should take backwards compatibility
more seriously. Even a fallback dialog box like the one implemented when
crossdomain got stricter in FP7 would be better than just breaking it.


Cheers
Juan Pablo Califano.


2008/10/17, Zeh Fernando <[EMAIL PROTECTED]>:
>
> Please read my post again. While I agree this is not the way most updates
> were made in the past, this is the way *certain* security updates were done
> in the past. Most notably:
>
> http://www.adobe.com/devnet/flash/articles/fplayer_security.html
>
> Read specially page 3. This was a big issue at the time and one that
> affected me directly; I had a socket server running on a server and all of
> a
> sudden it wouldn't work anymore. I couldn't publish a crossdomain.xml file
> on the socket server because it did not have an http server, so there was
> no
> obvious solution to the problem.
>
> There's plenty of examples of changes that maintained backwards
> compatibility. I never said anything to the contrary. My point is that
> there
> are also examples that *did* break backwards compatibility, that one being
> the most notable I can remember. And I honestly don't think this has
> anything to do with Macromedia or Adobe "styles".
>
> Zeh
>
>
> On Fri, Oct 17, 2008 at 6:10 PM, Dave Segal <[EMAIL PROTECTED]> wrote:
>
> > Actually this is not the way security updates were made in the past. With
> > other updates, for instance the introduction of and multiple changes to
> > the "allowDomain" rules, backward compatibility was maintained for older
> > versions.
> >
> > I agree with Juan, breaking a feature that has been supported for years
> is
> > a serious lack of respect for users of the platform. I guess it's time to
> > start looking at the alternatives to Flash that are out there.
> >
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Zeh
> > Fernando
> > Sent: Friday, October 17, 2008 4:25 PM
> > To: Flash Coders List
> > Subject: Re: [Flashcoders] Flash 10 file upload
> >
> > The problem is if they took that approach, the vague security hole would
> > continue to exist - a potential exploit would simply need to compile for
> > an
> > old version of the player.
> >
> > It's awful, but I wouldn't really say it's an "stupid" decision. As soon
> > as
> > they decided to cripple the functionality, making it global is the only
> > way
> > to go. It's a no-win situation. This is also the way certain similar
> > security decisions have been made in the past.
> >
> > I think the only real solution would be to let it work as usual, BUT add
> > an
> > optional checkbox to the file browsing dialog that would let the user
> > disable further dialogs from that Flash movie (or at least THEN make it
> > respond to events only), in the same vein Google Chrome does with
> > Javascript
> > dialog popups. It works very well to combat the focus-stealing exploits,
> > and
> > I'm not sure why Adobe didn't take that route instead.
> >
> >
> > Zeh
> >
> > On Fri, Oct 17, 2008 at 4:47 PM, Juan Pablo Califano <
> > [EMAIL PROTECTED]> wrote:
> >
> > > Not that it doesn't work, necessarily, but now the browse() method will
> > > only
> > > be callable in response to a user action, not programatically.
> > >
> > > http://theflashblog.com/?p=423
> > >
> > > In my opinion, this change would be ok if it were applicable only to
> > swf's
> > > compiled for version 10 or greater, but changing an existing API in a
> > > way that deliverately breaks existing content that has been working for
> > > years is a stupid decision and a serious lack of respect to users of
> the
> > > platform (end users and developers), to say the least.
> > >
> > >
> > > Cheers
> > > Juan Pablo Califano
> > >
> > >
> > > 2008/10/17, Merrill, Jason <[EMAIL PROTECTED]>:
> > > >
> > > > HOLD THE PHONE.  So are you saying FileReference upload no longer
> > works
> > > in
> > > > AS2/AM1 published .swfs in Flash 10?????  If so, that IS VERY BAD and
> > > will
> > > > break many applications.
> > > >
> > > > Jason Merrill
> > > > Bank of America
> > > > GCIB & Staff Support L&LD
> > > > Instructional Technology & Media
> > > > Join the Bank of America Flash Platform Developer Community
> > > > Are you a Bank of America associate interested in innovative learning
> > > ideas
> > > > and technologies?
> > > > Check out our internal  Innovative Learning Blog & subscribe.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED] [mailto:
> > > > [EMAIL PROTECTED] On Behalf Of Dave Segal
> > > > Sent: Friday, October 17, 2008 2:18 PM
> > > > To: 'Flash Coders List'
> > > > Subject: [Flashcoders] Flash 10 file upload
> > > >
> > > > The new Flash 10 security restriction on file upload and lack of
> > backward
> > > > compatibility is killing me.  What was Adobe thinking unleashing this
> > > > nightmare and breaking working applications? Is there any quick fix
> > for
> > > > this besides recoding old swfs?
> > > >
> > > > _______________________________________________
> > > > Flashcoders mailing list
> > > > Flashcoders@chattyfig.figleaf.com
> > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > > >
> > > > _______________________________________________
> > > > Flashcoders mailing list
> > > > Flashcoders@chattyfig.figleaf.com
> > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > > >
> > > _______________________________________________
> > > Flashcoders mailing list
> > > Flashcoders@chattyfig.figleaf.com
> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > >
> > _______________________________________________
> > Flashcoders mailing list
> > Flashcoders@chattyfig.figleaf.com
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > _______________________________________________
> > Flashcoders mailing list
> > Flashcoders@chattyfig.figleaf.com
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> _______________________________________________
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Reply via email to