moockblog

Great Site Folks! I have another big tits site for you which is really the #1 big tits site - check it out, its full of big tits !! here's the link: Big Tits

Boris rules !

This is giving me a massive headache, even though it's only one app that I'm having trouble with. How does the player find the crossdomain.xml file? What if the server doesn't have an htdocs, but isn't an xml socket server?

yeaph, that sucks... modify sites that you have finished months ago... spend time... talk to your clients and ask for the login/pass for the server to update the files ... lost time, lost money...

Here's an example of the problem...
http://fluid.com/

Now go to

http://www.fluid.com/

and all is well. A bit stupid on Macromedia's part, really. It should be cross-domain, not cross-subdomain. Ah well.

miles:
you're right, my initial blog comment and post was over-generalized. i have already updated all content to be more specific...it's not "all sites that load data" it's "all sites that load data using an absolute url (e.g., someXML.load('http://moock.org/newsfeed.xml')".

Sorry, again. Last post was by me. Referring to the post before that, also by me.

Damn, I need some coffee....

Sorry, my tags didn't come out. They should be:

allow-access-from domain="*.foo.com"

and

allow-acces-from domain="*"

These security restrictions DO NOT affect every single Flash movie on the web that loads external data.

Colin, your problems are with the fact that F7's domain comparison has been tightened. As I understand it, domain comparison is now done on the complete URL, so http://foo.com and http://www.foo.com are now seen as different domains, even if they are the same physical server.

This will be easy to rectify using a cross domain policy setting something like:

If your movie is on www.foo.com and it loads data from www.foo.com all is fine, no changes need to be made.

And as for WebServices, shinstudio, if they are free services open to the public, hopefully the providers will be happy to add a cross domain policy. All they need to do is set:

And this will allow access from any and all domains. If the services are already public domain, they shouldn't have too much of an issue with that.

I'm loading a m3u playlist with absolute path from another
server on one of my sites. that seems to work without any trouble...

My concern is this. What if you have free web service such as "http://www.webservicex.net/stockquote.asmx?WSDL", that's one of free web services which you can make couple gadget out of.

I have pro FMX2 with data binding, web services components, etc, which has web services panel so you can store some web services wsld urls there. However as far as I understand it is total useless unless free web service server offers *CROSS-DOMAIN POLICY*. I doubt that those web service providers are willing to offer that.

Meaning that you have to build your own web services on your server to consume other web services which are maybe free or not and send data to flash.. Or is that to sell Cold Fusion somehow?
That seems to be hassle to me.

I have a BMW right in front of me with key on my hand, but no gas...

Have these geniuses at macromedia done something so we can prevent other sites to directly link to our content, like flash games? ( hotlinking )

htaccess can work to prevent hotlinking of images, but flash player still doen't report refferals so it doesn't work.

This is by far the most common form of content theft on the web. Maybe by version 77 MMedia will get around to doing something about it?

JD: ok we all understand your concerns about exploits... though usually when a security update occurs, there's a security alert explaining more or less the exploit when the fix is published.
In the current case, nobody was informed of a potential exploit - understand me, I don't ask for details, but this release of the player has not been qualified as a critical update from a security point of view.
So why isn't backward compatibility preserved when there's no official alert ?
The way things happen make me feel a bit betrayed... (not to mention the fact that some people who reported this problem before the final release had to accept a NDA which prevented them from discussing the issues regarding these changes - which is IMHO not completely fair )

junior:
thanks for the report about the missing ";". it's fixed now.

jd:
the docs on the mm site about this situation are exemplary. really top notch.

that said, i do actually think the emergency is pretty dire. how many websites include flash content? i have absolutely no idea. let's say 100 million (???). now suppose 10% (big underestimate?) of those sites load data using an absolute url. that's 10 million sites that are now showing confusing dialog boxes to their users. that's 10 million sites that need hand-fixing by developers. i can't think of a more dire situation in the history of flash. we need to do everything we can do to spread the news and importance of the situation. i've already received several messages saying "wow i thought that was an error in the flash player" or "error in my code". god knows what my mom thinks. i think it's easy to say "not that dire" when you think of it as a development problem. but when you realize the effect the situation has on the real people involved, it's definitely dire. at my old web agency we had our share of fickle clients whose stupid ceos might well have canceled an account for something like this (picture stupid ceo's daughter sulking cause she couldn't play corporation's latest promotional game).

Thanks for spreading the word, Colin. The "emergency" may not be that dire, because it takes awhile for consumers to update their software, but still it would be good to accommodate the tighter sandbox on subdomains as soon as possible so that visitors with new Players won't have to click that permission request. Deneb's got source info here:
http://www.macromedia.com/devnet/mx/flash/articles/fplayer_security.html

Tightening a sandbox isn't fun, because it means some existing work will change... that's one of the reasons why starting with a tight sandbox in the first place is usually the stronger strategy. I'm sorry for the hassle anyone has to go through, but if a researcher proves a potential exploit then we've got to choke it off before it becomes an actual exploit. :(

Regards,
John Dowdell
Macromedia Support

I think this applies to remoting calls as well but only if you specify an absolute URL and someone calls your site via a different third-level domain name.

&lt

Sorry, i mean the < not lgt :) (i'm using safari)

You don't have an ; after some of your lgt's on that page, so if you cut and paste it doesn't get the < sign it gets lgt. :)

right, thanks jon. i've adjusted the official warning to include that clarification.

i was afraid of this. however, as long as you *don't* include the "www.whatever.com" you're ok.

I've got several sites that load configuration from "/index.xml" and those are all behaving.

Including a domain name is what will trip the alert.

vera: no, i specifically *don't* mean "from another domain". please read the technote (see link). the security dialog appears even when a site is accessed as "foo.com" and attempts to load data from "www.foo.com" (or vice versa). hence, *every* site that loads data is affected. i don't think this post can generate enough panic. i know it's hard to believe, but *every* flash movie on the web that loads data is affected! pass it on...

Don't you mean "loads XML or variables from another domain" and "controls movies loaded from another domain"? Because as long as they live on the same site, everything is fine. This may be obvious to most people even without mentioning it, but your post might cause more panic than necessary. :)

Well that sucks.