A long long time ago, we had getNetText and postNetText in Shockwave. We could save little text files in a specific folder. While the Sunder development, each shockwave movie had the option to exist in global space and have access to another SW movie's vars.
Just to do a test of intermovie communication I did a simple polling set of routines to simulate a song playing back with a volume knob and a graphic equalizer back in 1996. http://www.director-online.com/buildArticle.php?id=37 http://web.archive.org/web/19991005142636/http://www.blacktop.com/zav/shockwave/ (I doubt this will even work today.) When this was done, we had turned off that option due to security concerns. We didn't even give a user an option to open it up so that multiple shockwave movies on a page could communicate without having to go through the file system. This was simply done to try to make sure that we didn't create a method for people to write viruses in Shockwave or mess with another movie running in another session without its permission. Sadly, I think that sandboxing is going to be a requirement in iOS (and Mac OS) for security reasons and for other "system integrity" reasons. On May 29, 2012, at 10:17 AM, Mikkel Islay wrote: > > On 29 May 2012, at 01:59, Graham Cox wrote: > >> Nobody has written a better analysis, critique and alternative suggestion >> for sandboxing than Wil Shipley: >> http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html > > An interesting post, but his arguments against sandboxing, I think. > Shipley argues from the pretense that App Sandboxing is a technology intended > to shield the user form the intentions of the software developer. That is of > course not the case. From the docs: "App Sandbox provides a last line of > defense against stolen, corrupted, or deleted user data if malicious code > exploits your app." > Of course App Sandboxing will have bugs, and no doubt someone might write an > arbitrarily sophisticated malware app which could make it past the review, > but is that an argument against sandboxing? It is intended to secure apps > (and users) after deployment. Recently someone posted a link to a blogpost, > describing manipulation of the ObjC-runtime to attack third-party apps on > compromised iOS-devices. App sandboxing is meant to limit the effectiveness > of that type of attack on OS X. Is that a important or credible type of > attack on OS X? Shipley's arguments all but ignores that question. > The post makes a lot of the weaknesses of app curation, but they are besides > the point. The (relative) merits of sandboxing remain the same, irrespective > of whether it functions in conjunction with the App Store or not. The > argument that app curation is imperfect, doesn't impact the efficacy of > sandboxing against attacks against apps. > Using MacDefender as an example of malware, sandboxing does not deal with, is > a bit of a straw man argument. MacDefender was a phishing scam. App > Sandboxing is not particularly effective against programs designed to fool > users into taking actions which are against their best interest. It was not > really designed to be. > > Mikkel > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
