« VideoEgg on TypePad | Main | CF gear photos »
October 25, 2005
Mike's CD project
Mike's CD project: There's a comment in another weblog item here, about security changes in Macromedia Flash Player 8 interfering with an unconnected CD/browser project. I'm not sure who this actually is ("mike@mike.com" isn't real), but I'd like to see the project succeed, and the suffering minimized. This is hard to do because I'm not even sure which of the four sandboxes this project uses... my guess was that it's a CD-delivered SWF, played in a browser, which then attempts to make a remote request and sees a permissions dialog -- but then the subsequent "can't change settings 'cause no connectivity" symptom is hard for me to understand. In general, the most concise "what-to-do" info on this subject is this how-to technote, and the "why" of it is best discussed on this page of Deneb's 9-page overview. (Oversimplified summary: A non-web SWF can access local files, so it shouldn't be able to contact remote servers without your explicit permission.) I'm not really set up to do tech support on this issue, but I'd like to give it a try... what's your real name, and which of the four sandboxes is this project architected to use?
Posted by John Dowdell at October 25, 2005 02:16 PM
Trackback Pings
TrackBack URL for this entry:
http://weblogs.macromedia.com/mtadmin/mt-tb.cgi/6754
Comments
Any idea why MM restricted sockets to below 1024 in 8.5 aswell ;o) (off topic alittle but I just wanted to know) Cheers cam.
[ I think I'm in OT Purgatory today, eh? ;-) When I did a Google search on term "'macromedia flash player' sockets 1024" I pulled up tons with a slightly different sentence structure (strike "to" and "in 8.5"). -jd ]
Posted by: Campbell at October 25, 2005 04:22 PM
While I can't comment on Mike's exact situation, I can understand where the new security settings in Flash 8 can cause issues.
When a client sees a mysterious error message where there was none before, many tend to immediately contact the developer/designer without investigating what the error messages is saying. For many clients, if it worked before and now it is not working, it is "broke" and the developer I paid money to build it must now fix it.
Unfortunately in a web world where bad things happen (spyware, buffer overflows, etc), MM did the right thing and has tried to make the flash player more secure.
As for Mike@mike.com, the flash player was in public beta, so there was time to test this and be ready for any issues. However, since that didn't happen, Mike should probably prepare documentation for his customers on how to properly set up their security settings so their content can work again. A nice video tutorial (Captivate, Camtasia or Wink (free - http://www.debugmode.com/wink/) sent out to all of his customers and made available on his web site would go a long way in reducing customer tension.
Posted by: John Olson at October 25, 2005 04:53 PM
Ok maybe a re word on my comment "why wont MM let me use sockets below 1024?" a http socket is 80 an ssl is 443 etc etc these are some of the more usefull sockets ;o), an to try and keep you out of OT purgatory, I think what MM has done by tightening the security was the right thing to do. Although the average user was never aware of what was going on in the background the development companies were. And if it to become a serious "RIA" (my buzz word for the day) tool it had to make that step.
Posted by: Campbell at October 25, 2005 05:50 PM
Hey jd , its me from Flex.G-uniX.com (rember i was making , atleast finally im being noticed by Macromedia for doing something , i have 2 questions, 1) How did u find out that i was distubuting copies of flash player 8.5 and 2) If i get quality tutorials on my site can i get accepted in the MXNA? , im not trying to act cheesy but I love macromedia lol and its like a goal for me to get accepted in the mxna .
Posted by: Faisal Abid at October 25, 2005 07:57 PM
This is getting a little strange here... I promoted the original OT to a full blog item here, but the comments on this item are going in a third and then a fourth direction.... ;-)
"mike@mike.com", I'd still like to help your project go as smoothly as possible.
John, good call, but I'd still like to make sure he gets to a better place ASAP... also bring functional feedback back into the shop.
(Faisal, I regularly spotcheck weblog searches on "macromedia" via Technorati, Blogpulse, IceRocket and other blogsearch engines... I skip around and try to find commentary through various means.)
Posted by: John Dowdell at October 25, 2005 09:07 PM
John - yep I'm sorry for what I started in the wrong place :-|
But I've emailed you directly rather than carry it on here!
Oh and to John Olson - your suggestions is exactly what I have done - and it does help a little but many clients don't like to/refuse to change security - and many still don't 'get' it! Others refuse to put their whole CD drive in the trusted zone - and I can understand that!
Cheers
Posted by: mike at October 26, 2005 01:01 AM
Campbell, wouldn't your questions on Flash Player 8.5 get more traction at Macromedia Labs?
http://labs.macromedia.com/wiki/index.php/Talk:Main_Page
Posted by: Skip Pickle at October 26, 2005 06:48 AM
Hi Im just discovering this problem too and would be interested in any solution you could post.
I see the Local Content Updater tool updates files so they can get local-with-networking privileges - but is there any way to update them so they get the local-with-filesystem privilege? I may be getting confused - but I just want my flash 7 files to continue calling javascript as they do in flash 7 player - they do not need access to the internet, just the javascript in the same page as the swf (which are on CD). I thought if they didn't need internet access then they could have local access but my tests with flash 8 are all showing the security warning (in fire fox, nothing happens in IE - it fails without explaining)
Thank you
Posted by: Mark Atkins at October 26, 2005 09:50 AM
Scripting between local SWF and local HTML requires that the SWF be in the local-trusted sandbox. This is onerous, but necessary. Local HTML doesn't reliably fit into any sandbox, and so could be used in combination with local SWFs (local-with-filesystem or local-with-network) to violate local security.
Posted by: Ethan Malasky at October 26, 2005 11:04 AM
re: "emailed you directly"
Sorry, that's a no-go, for me. My company email address was exposed during the early internet days, and remains so in list archives, so I get unbelievable tons of junkmail in private email. I'm still getting over a thousand mailing-list messages a day, as well as internal email, so I've got a severe whitelist system in place. Off-list email is among all those Viagra ads. :(
(Ethan, that's one more beer I owe you next time we're at Mars, thanks.... ;-)
Posted by: John Dowdell at October 27, 2005 07:55 PM
Ah well - pretty much the same reason I use a fake email on blogs then? mike@mike.com no longer sounds like a big deal huh? I did wonder why you thought it strange someone would use a fake email on your blog - now I just wonder why you make a big deal about it.
Looks like you wont be helping after all, but thanks for kinda offering.
For anyone else who is interested....
the client has to do the security thing online - there is *no* way around it. You use flash on a CD (or locally at all), then you need to put *explicit* instructions about *new* flash versions as well as older ones.
Shame, and a pain, but that's the way it is. We are now in the min and max version age.
Posted by: mike at October 29, 2005 04:04 PM
I'm still not sure of particulars, but it sounds like a forward-looking question was "If I have to combine local and remote assets in the new Player, then what's the easiest way to handle the security permissions?"
If so, then it sounds like you might have already read these steps, which can be done when you install their new Player (intranet, eg) or as instructions when they visit your site in the new Player (internet, usually).
http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=4c093f20#allowing
Posted by: John Dowdell at October 29, 2005 08:50 PM
OK John, I'm going to quit this now as it's probably not helping either of us too much! As I said, I do appreciate it that you actually bothered taking time out to think about it.
So as a last note - I have read pretty much everything I can find - including what you linked to.
But really it's still not what I had problems with! I fully understand the need to up security, especially with the local + remote access.
However - my problem is with CD based content with *no* need to access the internet - not at all - but rather have the ability to call local javascript - ie. in the same html page that holds the flash content, all of which (in this project) is on the CD. Say for example you had flash content that was just a button that simply called a javascript function that put up an alert. And that's it - nothing else - you just want the flash to call the javascript and no more than that - never once attempting to hit the internet. Well that's the equivalent - and it's that level of limitation that I have the problem with. Especially given the client gets no notice that it's flash 8 stopping it if they use IE - to the client nothing happened - it's broken. If it consistently told them it was blocked by flash and they could do something about it we might get somewhere, but to silently stop what once worked is a major problem for me. Non-tech people (and even some tech people!) could easily think they have a broken product. I could have put some readme file on the CD's explaining this as a workable problem - but the CD's have been made and used over the last 3 years - I didn't know when flash MX came out this would happen!
Anyway - that was it, and I'll just have to get on with it I guess.
But thanks again for your help.
Mike.
Posted by: mike at October 30, 2005 04:29 PM