Re: Sandboxing. WTF?
Re: Sandboxing. WTF?
- Subject: Re: Sandboxing. WTF?
- From: Alex Zavatone <email@hidden>
- Date: Tue, 29 May 2012 17:51:06 -0400
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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden