I don’t like the idea of deleting random files on the user’s computer as it could cause major problems. You could take the snapchat approach and just send notifications to the proctor when files are created during a test.
Thanks, Jon On Feb 22, 2014, at 1:54 PM, Matt Gough <devlists...@gmail.com> wrote: > OK, > > So lets assume that you can’t actually prevent the screen being captured. > Maybe a solution would be to prevent that captured data from surviving very > long. > > e.g Install an FSEvents watcher and look out for image and movie files being > created on the entire disk. Then delete them while your app is doing its > testing. > > > M > > On 22 Feb 2014, at 05:38, Bradley O'Hearne <br...@bighillsoftware.com> wrote: > >> >> 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/devlists.mg%40googlemail.com >> >> This email sent to devlists...@googlemail.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/jhull%40gbis.com > > This email sent to jh...@gbis.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
