On Feb 21, 2014, at 9:43 PM, dangerwillrobinsondan...@gmail.com wrote: > They're pointing out valid security issues which are true on all platforms. … > On any platform, you will need to basically install and run a root kit.
This is not the case on Windows. It provides the ability to block certain things which public API on OS X does not. We however would like to have an app on OS X that provides the same capabilities as the app on Windows. It is pretty much going to be a major fail if we have to tell large institutions that their students cannot use their Macs for taking tests, because this one hole that test providers want prevented is a trivial matter to block on Windows, but cannot be done on OS X. One reason I’ve continued to pursue this issue is that because it is hard for me to fathom that over the matter of exposing knobs and switches in public API which I have good reason to believe already exist in private API, that the preference would be to leave OS X as a non-option for these kinds of use-cases. > \You can use the Quartz Display Services API to control the attached displays > (see the "capture" functions for capturing control of the Already using it. Capturing all displays allows us to display above other apps, preventing other apps and other monitors from displaying other apps. It does nothing to affect screen capture, screen recording, remote desktop, etc. > It is impossible to verify a system is not compromised when the system is > outside of physical control at any time prior to running or installing your > app. ... > If they've been convinced of anything else, either they've been lied to by > others or they listened to people who really didn't understand security > fundamentals. ... > If they're really aware of these issues, then they should have established > guidelines on acceptable risks that are not severe enough to them to spend > money on, redesign for, or spend time on. I appreciate the sentiment, and the thoughts about security theory and philosophy. But no one has lied or misled anyone. The test content providers have a very understandable request: just don’t allow test content to be lifted quickly and en masse with minimal effort. Even Apple’s own engineers I spoke to agreed this was reasonable. None of them attempted to position the problem as being unsolvable, or unreasonable, or in violation of a deeper security theory which needed to be explained to a CEO which just forked out 6 figures to have a high-quality industry certification exam created. > At the end of the day though, on any platform, it is possible another process > is running and recording the display stream, input stream, or network traffic > or disk or memory writes before your process runs. Unless it is the Apple DVD player, which seems to secure its content just fine. > You'd do well to analyze what processes could and should be running while > yours runs and limit it to that as well. (Whitelisting) > A DTS incident might help you to find out what that might need to be. We’ve been doing this for years, and it is something we want to get away from. It is a flawed approach on a number of levels, and a constant headache, and also one that directly opposes the aims of sandboxing / Mac App Store. If it can be done in OS X…that’s an answer. If it cannot be done in OS X….that’s also an answer. But telling the client they are unreasonable to want to prevent their test content from being copied — not an answer. The solution might not be immediately apparent or easy, but hey, that’s just new a new problem to solve. B _______________________________________________ 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
