Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 23, 2014, at 11:13 PM, Bradley O'Hearne  
wrote:

> So I’ll try the Developer Program support phone number tomorrow, but beyond 
> that, there’s not much left to try. The DTS web form seems to be the only 
> game in town.


…and the end of the matter: I got through to DTS. After a brief exchange, here 
was the resolution: 

"Please file a bug listing all of this out and send me the bug number. “

Except that my original question started with…the fact that already had filed a 
bug, and had sent DTS the bug number.

fin

Brad


___

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

Re: Disabling screen capture

[Jeffrey Oleander]

On 2014 Feb 21, at 18:24, Scott Ribe wrote:
On Feb 21, 2014, at 2:26 PM, Bradley O'Hearne 
 wrote:
Industries such as medical (HIPAA), legal, government, education, 
military defense, etc. all have such security needs.


The only way I can see for the app under discussion to work is to 
create kiosks with human proctors, and not use the network.  The video 
surveillance won't suffice to stop the cheating.  But if you're going 
to do it that way, why use the computers at all?  Might as well go back 
to paper as we do with election ballots.  I'd even recommend privacy 
shields around each test-taker, require that devices be in opaque 
containers, etc.


I can see why such tests need to be secure, because I've seen the 
articles about College Board test questions being collected, posted on 
the net, and crowd-sourcing of answers, which people then memorized.  
That was about a decade back though, and they pulled the on-line tests, 
and probably caught and penalized a tiny fraction of those involved.



Well, there's certainly no such need for HIPAA compliance...


Correct.  Because HIPAA is Orwellian.  It says it's to protect patient 
privacy, but makes sure privacy is violated, instead.  It was to 
facilitate federal government snooping into individual medical records 
(or at least their software snooping), and cross-border processing, 
while putting on a nice face to the victims.  I've consulted for some 
of the state "medical cost containment" people, and they yearn for a 
fool-proof way to integrate all such records so that no one's medical 
history gets through the cracks (e.g. matching up ambulance/EMT contact 
with hospital admission & treatment, with rehab center admission and 
treatment and out-patient treatment... despite people giving variants 
of their names, refusing to give Socialist Insecurity Numbers or 
intentionally making "mistakes" or making up new ones on the spot in an 
effort to preserve some shred of privacy), but despite having nearly 
full access to people's DNA, we still have some slim shreds of privacy 
left.


___

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

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 21, 2014, at 9:13 PM, Bradley O'Hearne  wrote:

> I’ve spent the last hour trying to post an issue to DTS via the Apple Mac 
> Developer Program Member Center….no dice. Despite the fact I have all fields 
> filled out, I keep getting the error message: 
> 
> “We are unable to process your request. Please enter all required data.”
> 
> If anyone has any insight how to get past this, let me know.


An update on the matter of contacting DTS, an FYI for those unaware (I wasn’t). 
Since I cannot submit an issue via the DTS submission form, and I haven’t heard 
back from Developer Program support, I decided to take another list member’s 
suggestion and contact DTS directly at the d...@apple.com email address. I 
received an auto-reply from DTS which started: 

"Our support model has changed. DTS is longer accepting support requests via 
email. All new support inquiries must be submitted via web form.”

So I’ll try the Developer Program support phone number tomorrow, but beyond 
that, there’s not much left to try. The DTS web form seems to be the only game 
in town.

Brad
___

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

Re: Disabling screen capture

[Bradley O'Hearne]

…actually, I will respond to this one last issue, as this was a legit technical 
suggestion. We actually looked into this route of detecting screenshots when 
they are done, but we shied away from doing this, for a couple of reasons: 

- It appeared there would be other kinds of headaches that would arise, such as 
conflicting with things like Dropbox and other apps which performed automated 
importing of images. 

- Contrary to the direction the discussion in this thread ended up skewing, we 
do not desire to muck with anything in the system. We want a contained 
environment for our app only when it runs which affects only the presentation 
of its runtime, and once the app is exited, everything is as-is before the app 
was launched. We’d like to not to change system settings or anything like that 
— case and point: we don’t kill running apps which would help a user to cheat 
on a test (like web browsers), we just capture displays and present full-screen 
in front of all other apps. We aren’t really opposed to any particular service 
or app running, we just don’t want it to be affect our app or delivered content.

Likewise, we preferably wouldn’t even really need to block Airplay or remote 
desktop, we just don’t want our app window visible on remote systems if those 
are launched (which appears to be possible with private API, which we don’t 
want to use). 

If I could engineer an ideal solution, whether it be dealing with screenshot 
hotkeys, or having your app’s window content included / not included on Airplay 
/ remote desktop transmission, it would be a scenario where: 

- There would be no need to affect *any* system-wide settings.
- An app could merely opt-in/opt-out for its content/windows to be included / 
excluded in screenshots, Airplay, remote desktop, etc. 

Pretty simple…just a way for an app to say “hey, don’t include me in those 
things”. 

Anyway, thanks for the suggestion…that’s out-of-the-box thinking…. :-)

Brad

On Feb 23, 2014, at 12:55 PM, Lee Ann Rucker  wrote:

> defaults write com.apple.screencapture location ~/Pictures/
> 
> (Putting things on my virtual desktop is as pointless as writing it directly 
> on my real one - I have so many files/papers open, it's effectively lost. 
> Clutter is good!)
> 
> - Original Message -
> From: "Scott Ribe" 
> To: dangerwillrobinsondan...@gmail.com
> Cc: "Cocoa Cocoa-Dev" , "Uli Kusterer" 
> 
> Sent: Sunday, February 23, 2014 7:34:22 AM
> Subject: Re: Disabling screen capture
> 
> On Feb 22, 2014, at 10:09 PM, dangerwillrobinsondan...@gmail.com wrote:
> 
>> How would you know what files to watch for?
>> File extensions are really unreliable means of knowing content types. 
> 
> Because the built-in screen shot functionality uses a really obvious naming 
> convention, and drops the files right on the desktop.
> 
> -- 
> Scott Ribe
> scott_r...@elevated-dev.com
> https://urldefense.proofpoint.com/v1/url?u=http://www.elevated-dev.com/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=okMPNGFUKXrHSbrOAT9XNeQdIjGNVTw5j1gvS7usIww%3D%0A&s=7e66c99913f6bb2753fe9dcf021a967b45836f322ee10ab166c537a0989c0423
> (303) 722-0567 voice
> 
> 
> 
> 
> 
> ___
> 
> 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://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=okMPNGFUKXrHSbrOAT9XNeQdIjGNVTw5j1gvS7usIww%3D%0A&s=5d99c2586f58d86c4f66c18ffbb4582f690e848e5ffa4041add2177a769ca0c2
> 
> This email sent to lruc...@vmware.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/brado%40bighillsoftware.com
> 
> This email sent to br...@bighillsoftware.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

Re: Disabling screen capture

[Lee Ann Rucker]

defaults write com.apple.screencapture location ~/Pictures/

(Putting things on my virtual desktop is as pointless as writing it directly on 
my real one - I have so many files/papers open, it's effectively lost. Clutter 
is good!)

- Original Message -
From: "Scott Ribe" 
To: dangerwillrobinsondan...@gmail.com
Cc: "Cocoa Cocoa-Dev" , "Uli Kusterer" 

Sent: Sunday, February 23, 2014 7:34:22 AM
Subject: Re: Disabling screen capture

On Feb 22, 2014, at 10:09 PM, dangerwillrobinsondan...@gmail.com wrote:

> How would you know what files to watch for?
> File extensions are really unreliable means of knowing content types. 

Because the built-in screen shot functionality uses a really obvious naming 
convention, and drops the files right on the desktop.

-- 
Scott Ribe
scott_r...@elevated-dev.com
https://urldefense.proofpoint.com/v1/url?u=http://www.elevated-dev.com/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=okMPNGFUKXrHSbrOAT9XNeQdIjGNVTw5j1gvS7usIww%3D%0A&s=7e66c99913f6bb2753fe9dcf021a967b45836f322ee10ab166c537a0989c0423
(303) 722-0567 voice





___

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://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=okMPNGFUKXrHSbrOAT9XNeQdIjGNVTw5j1gvS7usIww%3D%0A&s=5d99c2586f58d86c4f66c18ffbb4582f690e848e5ffa4041add2177a769ca0c2

This email sent to lruc...@vmware.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

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 22, 2014, at 10:09 PM, dangerwillrobinsondan...@gmail.com wrote:

> There is no Cocoa to this. This is OT. 

That is absolutely not true, it is *entirely* a question of Cocoa API, but….

> Thread should end.

…I’ll actually request the thread end, because it has unfortunately been 
swallowed by emotions, rather than holding to the simple question of nuts and 
bolts. This was nothing more than a question of can the machine (OS X) be made 
to do function X. I went further to describe the actual use-case, as that is a 
common first question received when seeking a solution, for the purposes of 
illustrating the need and the challenge — not for instigating a discussion of 
how unreasonable my clients are, how the use-case is suspicious and must be in 
some way nefarious, etc. Debating the merits of the use-case was not the point 
— the potential function of the machine was the point. 

Not all security measures are useless just because there’s another potential 
breach elsewhere, or because an underground cabal operating in a secret lair 
within a volcano can crack it using a satellite orbiting the Earth. I am not 
tasked with solving all of those issues, even if they are legitimate issues. I 
am tasked with solving exactly the functions I asked about — which are direct 
no-ops for large customer contracts.

I’ve got a fair pulse on the mailing list response, which in general is “you’re 
dumb for asking” (points for consistency — it was much the same when I posted 
about this a year ago). I’m not that cynical, I see the merits in the need (and 
for that matter, Apple’s own engineers did too when we sat down and discussed 
it in person). Furthermore, solving the problem brings keeps this app on OS X, 
and allows a large number of educational and professional users around the 
world to use Macs for their needs, rather than have these institutions / 
organizations have to tell their testers “you must run Windows”. 

Secure, remote testing isn’t going away — it is a huge market only in its 
infancy — and if anyone wonders how OS market share swings, this is an example 
— ignoring market needs. So in the future, if you are getting a Master’s 
degree, and your college tells you that a Windows PC is a pre-requisite, well, 
you can dig up this thread in the Cocoa-dev archives and have an example of why 
requirements like that come to be. 

If it is up to me, that won’t be the case — I’m the eternal optimist, and hope 
to solve the problem in a manner acceptable to content providers, and keep 
people testing on Macs. I still can’t post a DTS issue, and I’ve had no 
response yet from Mac Dev Program support, but hopefully I’ll eventually get 
through and get some help there. 

Thanks for the folks who responded offline. Your feedback was extremely 
helpful. 

Cheers,

Brad



___

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

Re: Disabling screen capture

[Mills, Steve]

On Feb 23, 2014, at 11:32, "Kyle Sluder"  wrote:
> 
> Control-Shift-3 puts the screenshot on the pasteboard

Command-control-shift-3.

Steve via iPad

___

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

Re: Disabling screen capture

[Kyle Sluder]

On Feb 23, 2014, at 7:34 AM, Scott Ribe  wrote:
> 
>> On Feb 22, 2014, at 10:09 PM, dangerwillrobinsondan...@gmail.com wrote:
>> 
>> How would you know what files to watch for?
>> File extensions are really unreliable means of knowing content types.
> 
> Because the built-in screen shot functionality uses a really obvious naming 
> convention, and drops the files right on the desktop.

Control-Shift-3 puts the screenshot on the pasteboard.

--Kyle Sluder
___

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

Re: Disabling screen capture

[Geert-Jan Korsbø Nilsen]

An app that deletes files on another persons Mac, blocks certain functions of 
the OS, and reports stuff really sounds like a trojan to me. I guess Apple has 
done a lot to prohibit this kind of behaviour from apps, so even if the app 
made by the thread-starter is legit, the mechanics would be useful for someone 
developing malware. In my opinion, the greater good of protecting the masses 
outweigh the commercial interest of the thread-starter, and Im certain Apple 
would never let an app like this be distributed through the Mac App Store, nor 
help with developing it.

But if the thread-starter really needs this kind of capability, there are 
enough forums out there with the clientele and the proper competence to help 
getting something like this done.

Talk to the ppl behind MacKeeper for example, they know their way around the 
shady parts of the community… ;)


On 23 Feb 2014, at 05:35, Scott Ribe  wrote:

> On Feb 22, 2014, at 10:31 AM, Uli Kusterer  
> wrote:
> 
>> Just using Mac OS X Kiosk mode would probably be even closer. :-) But 
>> judging from the login terminals at 1 Infinite Loop, Kiosk mode doesn’t turn 
>> off screen shots.
> 
> I feel dirty for saying this ;-) But if you can't disable screen shots, how 
> about: using fsevents to watch for the files to be created, and delete them. 
> (Or, in this case raise a big fat alarm so the proctor will know.)
> 
> I know, pure evil ;-)
> 
> 
> -- 
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-dev.com/
> (303) 722-0567 voice
> 
> 
> 
> 
> 
> ___
> 
> 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/gert%40yuppielabel.com
> 
> This email sent to g...@yuppielabel.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

Re: Disabling screen capture

[Michael Starke]

On 23.02.2014, at 17:16, Etienne Samson  wrote:

> Le 23 févr. 2014 à 16:34, Scott Ribe  a écrit :
> 
>> On Feb 22, 2014, at 10:09 PM, dangerwillrobinsondan...@gmail.com wrote:
>> 
>>> How would you know what files to watch for?
>>> File extensions are really unreliable means of knowing content types. 
>> 
>> Because the built-in screen shot functionality uses a really obvious naming 
>> convention
> 
> I'm raising a *localized* flag here. Unless you plan for English-only 
> businesses, you'll have to account for that.

Sorry if this doesn't apply to the use-case as I've not been following the 
discussion closely.
What did pop to mind is that you can set the name, location and format of the 
screenshot via preferences. This might also work against this solution.

___m i c h a e l   s t a r k e 
   geschäftsführer
   HicknHack Software GmbH
   www.hicknhack-software.com
   
___k o n t a k t
   +49 (170) 3686136
   cont...@hicknhack.com
   
___H i c k n H a c k   S o f t w a r e   G m b H
   geschäftsführer - maik lathan | andreas reischuck | michael starke
   bayreuther straße 32
   01187 dresden
   amtsgericht dresden HRB 30351
   sitz - dresden


___

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

Re: Disabling screen capture

[Etienne Samson]

Le 23 févr. 2014 à 16:34, Scott Ribe  a écrit :

> On Feb 22, 2014, at 10:09 PM, dangerwillrobinsondan...@gmail.com wrote:
> 
>> How would you know what files to watch for?
>> File extensions are really unreliable means of knowing content types. 
> 
> Because the built-in screen shot functionality uses a really obvious naming 
> convention

I'm raising a *localized* flag here. Unless you plan for English-only 
businesses, you'll have to account for that.

Regards,
Etienne Samson
--
samson.etie...@gmail.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

Re: Disabling screen capture

[Scott Ribe]

On Feb 22, 2014, at 10:09 PM, dangerwillrobinsondan...@gmail.com wrote:

> How would you know what files to watch for?
> File extensions are really unreliable means of knowing content types. 

Because the built-in screen shot functionality uses a really obvious naming 
convention, and drops the files right on the desktop.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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

Re: Disabling screen capture

[Jonathan Hull]

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  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  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
> 
> 
> 

Re: Disabling screen capture

[Uli Kusterer]

On 23 Feb 2014, at 11:20, Uli Kusterer  wrote:
> On 23 Feb 2014, at 06:09, dangerwillrobinsondan...@gmail.com wrote:
>> There is no Cocoa to this. This is OT. 
>> Thread should end. 
> 
> What is it with you and this thread?

 Sorry, I shouldn’t have written it like that. And particularly not under a 
reply to dangerwillrobinsondanger, who actually offered a few suggestions.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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

Re: Disabling screen capture

[Uli Kusterer]

On 23 Feb 2014, at 06:09, dangerwillrobinsondan...@gmail.com wrote:
> There is no Cocoa to this. This is OT. 
> Thread should end. 

What is it with you and this thread? He’s already stated his requirements and 
asked for workarounds and solutions. The only people dragging this discussion 
kicking and screaming away from Cocoa is those people that keep showing up 
without any suggestions for solution, telling someone who says it’s OK to mimic 
the way Windows does it for his use case he can’t possibly be right.

You have no idea what kind of test he is administering. You have no idea what 
his legal/project requirements are in detail. Offer a solution and point out 
the caveats. It is his decision whether he will implement your suggestion, and 
also his responsibility if he doesn’t research his approach correctly. That’s 
why he gets paid.

Why don’t you leave the decision what is OT to the list admins and consider the 
beam in your eye instead of the mote in others’?

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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

Re: Disabling screen capture

[dangerwillrobinsondanger]

> On 2014/02/23, at 13:35, Scott Ribe  wrote:
> 
> I feel dirty for saying this ;-) But if you can't disable screen shots, how 
> about: using fsevents to watch for the files to be created, and delete them. 
> (Or, in this case raise a big fat alarm so the proctor will know.)
> 
> I know, pure evil ;-)
> 
> 
> -- 
> Scott Ribe
How would you know what files to watch for?
File extensions are really unreliable means of knowing content types. 

At the end of the day, BYOD for this is like a take home test where you take a 
proctor with you. Regardless of platform. 
You simply cannot create a controlled environment in an environment you don't 
control. 
This kind of testing is done in a controlled facility for that reason. 

No platform consumers use meets this criteria even if somebody thinks it does. 

There is no Cocoa to this. This is OT. 
Thread should end. 
___

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

Re: Disabling screen capture

[Scott Ribe]

On Feb 22, 2014, at 10:31 AM, Uli Kusterer  wrote:

> Just using Mac OS X Kiosk mode would probably be even closer. :-) But judging 
> from the login terminals at 1 Infinite Loop, Kiosk mode doesn’t turn off 
> screen shots.

I feel dirty for saying this ;-) But if you can't disable screen shots, how 
about: using fsevents to watch for the files to be created, and delete them. 
(Or, in this case raise a big fat alarm so the proctor will know.)

I know, pure evil ;-)


-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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

Re: Disabling screen capture

[Matt Gough]

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  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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Disabling screen capture

[SevenBits]

On Feb 22, 2014, at 12:28 PM, Uli Kusterer  wrote:

> On 21 Feb 2014, at 23:30, SevenBits  wrote:
>> Well, yes, but Apple has the source code to OS X. There’s an important 
>> difference in that users cannot simply just delete important OS components. 
>> In some other operating systems (e.g Linux) everything works with packages 
>> and you can simply uninstall packages that are not required, like web 
>> browsers and networking capability.
> 
> Last I checked, ProSoft sold an OS X boot disk containing a minimal OS X and 
> Data Rescue+ on it. So at least some third parties are permitted to do 
> something like that. It’s still all at Apple’s discretion, but it’s worth 
> getting in touch with Apple and trying to get that, if it solves your problem.

I’ve heard of that as well. They probably signed some sort of deal with Apple, 
like some companies have done with Microsoft to redistribute Windows’ files 
with third-party restoration DVDs.

> 
> Cheers,
> -- Uli Kusterer
> “The Witnesses of TeachText are everywhere...”
> http://zathras.de
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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

Re: Disabling screen capture

[Uli Kusterer]

On 22 Feb 2014, at 00:56, Ron Hunsinger  wrote:
> Parental controls with a Simple Finder is pretty close to kiosk mode.

 Just using Mac OS X Kiosk mode would probably be even closer. :-) But judging 
from the login terminals at 1 Infinite Loop, Kiosk mode doesn’t turn off screen 
shots.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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

Re: Disabling screen capture

[Uli Kusterer]

On 21 Feb 2014, at 23:30, SevenBits  wrote:
> Well, yes, but Apple has the source code to OS X. There’s an important 
> difference in that users cannot simply just delete important OS components. 
> In some other operating systems (e.g Linux) everything works with packages 
> and you can simply uninstall packages that are not required, like web 
> browsers and networking capability.

 Last I checked, ProSoft sold an OS X boot disk containing a minimal OS X and 
Data Rescue+ on it. So at least some third parties are permitted to do 
something like that. It’s still all at Apple’s discretion, but it’s worth 
getting in touch with Apple and trying to get that, if it solves your problem.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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

Re: Disabling screen capture

[Uli Kusterer]

On 21 Feb 2014, at 22:26, Bradley O'Hearne  wrote:
> This is an app that the user has willfully installed, and has willfully 
> launched, fully knowing its function and purpose. The app does nothing until 
> the user launches it, the user can exit the app at any time, and no 
> restriction remains after the user exits the app. It is a completely 
> voluntary, user-inititiated launch of a temporary environment, which provides 
> the opportunity for the user to take an online test remotely. 

 So that means you don’t have to go through the app store? In that case, you 
could maybe disassemble DVD Player.app and check how that does it … ? The OS 
definitely has the feature in DVD Player, iTunes and QuickTime Player.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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

Re: Disabling screen capture

[Brad O'Hearne]

Sent from my iPad

> On Feb 22, 2014, at 12:27 AM, "Gary L. Wade"  
> wrote:
> 
> You did go to this page, right?
> 
> https://developer.apple.com/membercenter/index.action#requestTechSupport
Yep, that's the one.

> I remembered one form on the site, not this one, that I had to submit by 
> deleting all the data and doing it again. Some freaky web page issue; I think 
> it was a phone number field that kept trying to be reformatted but in a way 
> the back end didn't like it, so I turned off JavaScript while filling it in 
> and then submitted it. If things still don't work, try emailing 
> d...@apple.com and explain this issue and your real issue.

Yeah, I have a strong suspicion that there is a bug in the web page, and I'd 
lay money that it is due to the apostrophe in my last name. I deal with this 
problem continually -- web developers who script with single quotes don't allow 
for last names with a single quote (apostrophe) in them, and thus their string 
processing is abruptly terminated early and appears as if data wasn't sent, 
when it actually was. The "enter all required data" points pretty strongly to 
that being the case here. I'd guess I encounter this problem about half the 
time on web sites, and often just going and altering my last name to remove the 
apostrophe solves the problem. Unfortunately, it appears the you can't change 
your name in your Dev account profile anymore -- that requires contacting Dev 
program support as well. So I filled out yet another form for Dev program 
support, which luckily allowed me to submit. Hopefully we can get the problem 
ironed out quickly.

> --
> Gary L. Wade (Sent from my iPhone)
> http://www.garywade.com/
> 
>>> On Feb 21, 2014, at 8:13 PM, Bradley O'Hearne  
>>> wrote:
>>> 
>>> On Feb 21, 2014, at 3:02 PM, Jens Alfke  wrote:
>>> 
>>> The best answer I’ve seen is that you’ll need to file a DTS support 
>>> incident and go through those official channels.
>> 
>> I’ve spent the last hour trying to post an issue to DTS via the Apple Mac 
>> Developer Program Member Center….no dice. Despite the fact I have all fields 
>> filled out, I keep getting the error message: 
>> 
>> “We are unable to process your request. Please enter all required data.”
>> 
>> If anyone has any insight how to get past this, let me know.
>> 
>> Thanks, 
>> 
>> Brad
>> 

___

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

Re: Disabling screen capture

[Gary L. Wade]

You did go to this page, right?

https://developer.apple.com/membercenter/index.action#requestTechSupport

I remembered one form on the site, not this one, that I had to submit by 
deleting all the data and doing it again. Some freaky web page issue; I think 
it was a phone number field that kept trying to be reformatted but in a way the 
back end didn't like it, so I turned off JavaScript while filling it in and 
then submitted it. If things still don't work, try emailing d...@apple.com and 
explain this issue and your real issue.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On Feb 21, 2014, at 8:13 PM, Bradley O'Hearne  
> wrote:
> 
>> On Feb 21, 2014, at 3:02 PM, Jens Alfke  wrote:
>> 
>> The best answer I’ve seen is that you’ll need to file a DTS support incident 
>> and go through those official channels.
> 
> I’ve spent the last hour trying to post an issue to DTS via the Apple Mac 
> Developer Program Member Center….no dice. Despite the fact I have all fields 
> filled out, I keep getting the error message: 
> 
> “We are unable to process your request. Please enter all required data.”
> 
> If anyone has any insight how to get past this, let me know.
> 
> Thanks, 
> 
> Brad
> 

___

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

Re: Disabling screen capture

[Scott Ribe]

On Feb 21, 2014, at 10:38 PM, Bradley O'Hearne  
wrote:

> This is not the case on Windows. It provides the ability to block certain 
> things which public API on OS X does not.

His point was that counting on that is not reliable.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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

Re: Disabling screen capture

[Bradley O'Hearne]

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

Re: Disabling screen capture

[dangerwillrobinsondanger]

> On 2014/02/22, at 11:13, Bradley O'Hearne  wrote:
> 
>> On Feb 21, 2014, at 3:02 PM, Jens Alfke  wrote:
>> 
>> 
>>> On Feb 21, 2014, at 1:26 PM, Bradley O'Hearne  
>>> wrote:
>>> 
>>> If that is the case, then once I can officially confirm this, then I’ll 
>>> drop the pursuit.
>> 
>> The key word is “officially”. There’s not really any point to discussing it 
>> here. We already had this exact same discussion a few months ago and nothing 
>> came of it; I’m not sure why you’re asking again and expecting more.
> 
> The last time I posted about this issue was 3/5/2013. There are several 
> reasons why I’m asking again: 
> 
> - I have since spoken directly with Apple engineers who said the use-case was 
> legit, and there was an outside possibility this might appear in later OS X 
> releases.
> 
> - The issues has been open in Apple radar since June 2013 ― I hadn’t seen any 
> movement, and wondered if perhaps someone else was aware of a change which 
> would positively affect the situation. 
> 
> - There has been a major OS X release since then (Mavericks). 
> 
> - The original discussion netted no definitive answer. 
> 
> - This has become a significant issue to my client’s product design and 
> strategy, and is becoming an obstacle to gaining business with certain 
> customers on OS X.  
> 
> …and I do expect that given a year of time, it is within the realm of 
> possibility that Apple has encountered others with similar needs to ours, and 
> may have made some changes we could benefit ― likewise, that there are others 
> on this list which may have encountered the same problem and tried to solve 
> it (which by virtue of some offline responses I’ve received, is indeed the 
> case). 
> 
> If the use-case isn’t your bag, no worries, just don’t reply. But don’t be 
> cynical and try to kill conversation because it isn’t your thing. That not 
> only doesn’t help my immediate question, but keeps others from posting their 
> issues who don’t really want to get roasted (which also by virtue of offline 
> responses I’ve received, is indeed the case). 
> 
Hi Brad

Nobody is trying to attack you here. 
They're pointing out valid security issues which are true on all platforms. 
This kind of topic comes up annually at least on this list. Often from folks 
who haven't really done a full analysis and they often come away from the list 
responses feeling a bit bruised. Many of the first responders on the list are 
very very seasoned developers. They're just trying to help. They're not ego 
driven but quality driven folks. 

On any platform, you will need to basically install and run a root kit. 
Meaning you need to install software that runs as root. 
That is not a usual Cocoa user experience, but it's the right path for this 
scenario.  

You can use the Quartz Display Services API to control the attached displays 
(see the "capture" functions for capturing control of the display) and you can 
use CGEvent APIs to control input via event taps. 
That will get you part of what you need for UI and input control. 
The I/O Kit framework will allow you to control hardware at a low level. Kernel 
level stuff. Not simple. But possible to basically prevent undesired hardware 
events to some degree. 

Let's not side step any of the other security concerns though. 
The classic saying "Boot access is Root access" should sum up much of it. 
Any other admin or root process outside of your visibility and control is a 
potential risk that must be evaluated and should be checked. 
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. 
That's what people are getting at. 
Again, platform agnostic. 

On some level you place a certain amount of trust and agreement in the user. 
Installing a root kit is your best bet in terms of software solutions on any 
platform and, really, physically controlling hardware is the best of all. Your 
clients need to know that. 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. 

People here are exactly pointing these things out for the benefit of all on the 
list. 

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. 

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. 

That will require custom software on any platform.

Basically, without managing a way to make sure a system (any platform) is 
cle

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 21, 2014, at 3:02 PM, Jens Alfke  wrote:

>  The best answer I’ve seen is that you’ll need to file a DTS support incident 
> and go through those official channels.

I’ve spent the last hour trying to post an issue to DTS via the Apple Mac 
Developer Program Member Center….no dice. Despite the fact I have all fields 
filled out, I keep getting the error message: 

“We are unable to process your request. Please enter all required data.”

If anyone has any insight how to get past this, let me know.

Thanks, 

Brad

___

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

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 21, 2014, at 3:02 PM, Jens Alfke  wrote:

> 
> On Feb 21, 2014, at 1:26 PM, Bradley O'Hearne  
> wrote:
> 
>> If that is the case, then once I can officially confirm this, then I’ll drop 
>> the pursuit. 
> 
> The key word is “officially”. There’s not really any point to discussing it 
> here. We already had this exact same discussion a few months ago and nothing 
> came of it; I’m not sure why you’re asking again and expecting more.

The last time I posted about this issue was 3/5/2013. There are several reasons 
why I’m asking again: 

- I have since spoken directly with Apple engineers who said the use-case was 
legit, and there was an outside possibility this might appear in later OS X 
releases.

- The issues has been open in Apple radar since June 2013 — I hadn’t seen any 
movement, and wondered if perhaps someone else was aware of a change which 
would positively affect the situation. 

- There has been a major OS X release since then (Mavericks). 

- The original discussion netted no definitive answer. 

- This has become a significant issue to my client’s product design and 
strategy, and is becoming an obstacle to gaining business with certain 
customers on OS X.  

…and I do expect that given a year of time, it is within the realm of 
possibility that Apple has encountered others with similar needs to ours, and 
may have made some changes we could benefit — likewise, that there are others 
on this list which may have encountered the same problem and tried to solve it 
(which by virtue of some offline responses I’ve received, is indeed the case). 

If the use-case isn’t your bag, no worries, just don’t reply. But don’t be 
cynical and try to kill conversation because it isn’t your thing. That not only 
doesn’t help my immediate question, but keeps others from posting their issues 
who don’t really want to get roasted (which also by virtue of offline responses 
I’ve received, is indeed the case). 

Brad 
___

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

Re: Disabling screen capture

[Ron Hunsinger]

On Feb 21, 2014, at 2:30 PM, SevenBits  wrote:
> Well, yes, but Apple has the source code to OS X. There’s an important 
> difference in that users cannot simply just delete important OS components. 
> In some other operating systems (e.g Linux) everything works with packages 
> and you can simply uninstall packages that are not required, like web 
> browsers and networking capability.

Who said anything about needing the source to the OS?

The "it" that I said was doable was the business of booting off a disk image. 
That's just a couple of calls to hdiutil and friends.

To prepare the disk image, copy into it all of /System except the 
screen-sharing parts. (It might be enough just to leave out the parts of 
/System/Library/Launch{Agents,Daemons} that enable features you don't want 
enabled.) Do not copy anything from /Applications. (Not copying 
/Applications/Utilities/Grab.app disables the screen-capture keyboard 
shortcuts.)

It is true that you cannot just delete important OS components. That's why I 
suggested instead either hiding them (with a virtual filesystem) or omitting 
them (by not copying them to a disk image). Neither screen sharing nor screen 
capture is an "important OS component", so that's OK. And the originals are 
still in place, so a simple restart brings everything back to normal. 


Another possibility is to require the testee to log into an ad hoc user 
account, one in which you are free to disable undesirable features, either via 
parental controls or by manipulating that user's launch services database to 
disable keyboard shortcuts. That reduces the problem to making sure the user is 
actually logged in as the user you control. (Or not. Let them know up front 
that if they launch your app under their own user account, it WILL be left with 
diminished capabilities.) Parental controls with a Simple Finder is pretty 
close to kiosk mode.

Consider using launchctl to stop dangerous (to you) daemons, like screen 
sharing. Leave out the -w flag to make the suspension temporary, so the user 
can always get back to full functionality with a simple restart, even if a bug 
in your app prevents you from cleaning up.

-Ron Hunsinger
___

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

Re: Disabling screen capture

[Scott Ribe]

On Feb 21, 2014, at 2:26 PM, Bradley O'Hearne  wrote:

> Industries such as medical (HIPAA), legal, government, education, military 
> defense, etc. all have such security needs.

Well, there's certainly no such need for HIPAA compliance...

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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

Re: Disabling screen capture

[Ron Hunsinger]

On Feb 21, 2014, at 1:26 PM, Bradley O'Hearne  wrote:
> I believe it would be much more accurate to say that this is a fundamental 
> issue of whether OS X provides an app the ability to secure its content or 
> not. If the answer is that having an app on OS X is synonymous with having 
> the content it delivers  available to any other app on the machine, or other 
> machines, or copied and broadcasted anywhere and everywhere, then that is an 
> answer which has significant limitations to what types of use-cases OS X is 
> appropriate for, relating very directly to security. 

Have you considered running a stripped-down copy of OS X? That is, make a 
bootable disk image containing your app and enough of the OS to run it, and 
then booting off that disk image. The disk image would not contain a web 
browser, screen-sharing software, screen-capturing, or any of the features that 
are causing you problems. It could unmount (or prevent from mounting) all other 
disk volumes.

I know it's possible: that's essentially how the OS X installers work. The 
installer mounts a disk image (copying it into a RAM disk), and boots from 
that, with the purpose being to allow the original disk to be completely erased 
and/or allow the previously running instance of OS X to be completely replaced 
in situ.

If you need a network connection, you'd probably need to copy the user's 
network settings into the disk image before booting from it (and after 
verifying that it hasn't been altered in any other way).

If Apple won't allow you to copy the OS, even temporarily, another approach 
might be to create a virtual filesystem that acts as an overlay on top of the 
boot volume, making files of your choosing appear to be absent. Then boot off 
that filesystem. You wouldn't be copying anything, so there shouldn't be any 
licensing issues.

I'm not sure how well that would play with FileVault, and there are a lot of 
other thorny issues to work out, but it's an approach you might want to 
consider.

-Ron Hunsinger
___

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

Re: Disabling screen capture

[SevenBits]

On Feb 21, 2014, at 5:19 PM, Ron Hunsinger  wrote:

> 
> On Feb 21, 2014, at 1:26 PM, Bradley O'Hearne  
> wrote:
>> I believe it would be much more accurate to say that this is a fundamental 
>> issue of whether OS X provides an app the ability to secure its content or 
>> not. If the answer is that having an app on OS X is synonymous with having 
>> the content it delivers  available to any other app on the machine, or other 
>> machines, or copied and broadcasted anywhere and everywhere, then that is an 
>> answer which has significant limitations to what types of use-cases OS X is 
>> appropriate for, relating very directly to security. 
> 
> Have you considered running a stripped-down copy of OS X? That is, make a 
> bootable disk image containing your app and enough of the OS to run it, and 
> then booting off that disk image. The disk image would not contain a web 
> browser, screen-sharing software, screen-capturing, or any of the features 
> that are causing you problems. It could unmount (or prevent from mounting) 
> all other disk volumes.
> 
> I know it's possible: that's essentially how the OS X installers work. The 
> installer mounts a disk image (copying it into a RAM disk), and boots from 
> that, with the purpose being to allow the original disk to be completely 
> erased and/or allow the previously running instance of OS X to be completely 
> replaced in situ.

Well, yes, but Apple has the source code to OS X. There’s an important 
difference in that users cannot simply just delete important OS components. In 
some other operating systems (e.g Linux) everything works with packages and you 
can simply uninstall packages that are not required, like web browsers and 
networking capability.

Just because it’s possible for Apple doesn’t mean that it’s possible for us. 
For example, how would you remove the WiFi network applet from the status bar?

> 
> If you need a network connection, you'd probably need to copy the user's 
> network settings into the disk image before booting from it (and after 
> verifying that it hasn't been altered in any other way).
> 
> If Apple won't allow you to copy the OS, even temporarily, another approach 
> might be to create a virtual filesystem that acts as an overlay on top of the 
> boot volume, making files of your choosing appear to be absent. Then boot off 
> that filesystem. You wouldn't be copying anything, so there shouldn't be any 
> licensing issues.
> 
> I'm not sure how well that would play with FileVault, and there are a lot of 
> other thorny issues to work out, but it's an approach you might want to 
> consider.
> 
> -Ron Hunsinger
> ___
> 
> 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/sevenbitstech%40gmail.com
> 
> This email sent to sevenbitst...@gmail.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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

Re: Disabling screen capture

[Jens Alfke]

On Feb 21, 2014, at 1:26 PM, Bradley O'Hearne  wrote:

> If that is the case, then once I can officially confirm this, then I’ll drop 
> the pursuit. 

The key word is “officially”. There’s not really any point to discussing it 
here. We already had this exact same discussion a few months ago and nothing 
came of it; I’m not sure why you’re asking again and expecting more. The best 
answer I’ve seen is that you’ll need to file a DTS support incident and go 
through those official channels.

—Jens
___

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

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 21, 2014, at 12:24 PM, Kyle Sluder  wrote:
> On Fri, Feb 21, 2014, at 10:35 AM, Bradley O'Hearne wrote:
>> I’ll also add (not for the purposes
>> of inciting a religious debate, but for the purposes of perspective and
>> comparison), that this is one area of security where OS X surprisingly
>> gives ground to Windows. Windows exposes more ability to easily turn off
>> various features that affect this use-case. 
> 
> I think you've hit upon the issue. "The ability for remote parties to
> disable portions of your computer's functionality" does not fall under
> the umbrella of what Cupertino would consider a "security feature."

Hey Kyle — that may be. My only direct indication from anyone at Apple were 
some engineers in the WWDC 2013 labs who worked on Mavericks, who indicated 
they thought it to be a valid use-case they’d like to address. But that may 
have been their personal opinion, and not that of their team. 

On your comments, I don’t think they accurately characterize the scenario. 
There’s no nefarious, remote entity in play here. This is an app that the user 
has willfully installed, and has willfully launched, fully knowing its function 
and purpose. The app does nothing until the user launches it, the user can exit 
the app at any time, and no restriction remains after the user exits the app. 
It is a completely voluntary, user-inititiated launch of a temporary 
environment, which provides the opportunity for the user to take an online test 
remotely. 

I would not frame this use-case with the words

> "The ability for remote parties to
> disable portions of your computer's functionality”

I believe it would be much more accurate to say that this is a fundamental 
issue of whether OS X provides an app the ability to secure its content or not. 
If the answer is that having an app on OS X is synonymous with having the 
content it delivers  available to any other app on the machine, or other 
machines, or copied and broadcasted anywhere and everywhere, then that is an 
answer which has significant limitations to what types of use-cases OS X is 
appropriate for, relating very directly to security. 

Industries such as medical (HIPAA), legal, government, education, military 
defense, etc. all have such security needs. Maybe you are right, and OS X isn’t 
intended to address these use-cases. If that is the case, then once I can 
officially confirm this, then I’ll drop the pursuit. 

Brad
___

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

Re: Disabling screen capture

[Kyle Sluder]

On Fri, Feb 21, 2014, at 10:35 AM, Bradley O'Hearne wrote:
>  I’ll also add (not for the purposes
> of inciting a religious debate, but for the purposes of perspective and
> comparison), that this is one area of security where OS X surprisingly
> gives ground to Windows. Windows exposes more ability to easily turn off
> various features that affect this use-case. 

I think you've hit upon the issue. "The ability for remote parties to
disable portions of your computer's functionality" does not fall under
the umbrella of what Cupertino would consider a "security feature."

--Kyle Sluder

___

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

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 21, 2014, at 11:07 AM, Jim Zajkowski  wrote:

> It sounds like the computers are owned by the people taking the test,
> and are not owned by the testing center.

Thanks for the reply, Jim. That’s correct, this is an app that runs on the 
test-taker’s computer. 

> How is the test data delivered to the client?

Network - SSL.

> What's to prevent someone from grabbing network traffic and memory of
> the test application in the background?

That could be done. But at the present, that is not an immediate concern. The 
risk of the average test-taker breaching security by dumping memory and sifting 
through the mess to reconstruct test questions while they are on live video and 
have no access to any other app while the test is running is a lot different 
than doing a screen shot or air playing the entire screen to an Apple TV in 
another room. 

Every high-tech bank vault can be breached. But that doesn’t mean it isn’t a 
good idea to put a lock on the front door of my house. 

Brad
___

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

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 21, 2014, at 11:24 AM, Jens Alfke  wrote:
> On Feb 21, 2014, at 9:55 AM, Bradley O'Hearne  
> wrote:
> 
>> when the app runs, it has to temporarily take control of their machines, 
>> deliver a test such that the user doesn’t cheat (by having other apps like a 
>> web browser available), and the test content isn’t copied
> 
> This sounds like a completely impossible situation. How do you prevent the 
> user from opening a web browser on their phone or tablet, or on another 
> computer nearby? Or from calling someone to get answers, or having someone 
> nearby to give them answers?
> 
> The only solution seems to be on-site human proctoring.

They are proctored in real-time by human proctors via video the entire time. 
Proctors can kill the test at any point if the user exhibits behavior that is 
not allowed, other people are present, or any test aids are present or used 
during the test. There is fair argument that it is actually more secure than 
the classroom environment, but that is another conversation entirely.

This model is already in place and working — a number of companies have been 
offering this service for years. I’ll also add (not for the purposes of 
inciting a religious debate, but for the purposes of perspective and 
comparison), that this is one area of security where OS X surprisingly gives 
ground to Windows. Windows exposes more ability to easily turn off various 
features that affect this use-case. 

Brad

___

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

Re: Disabling screen capture

[Jens Alfke]

On Feb 21, 2014, at 9:55 AM, Bradley O'Hearne  wrote:

> when the app runs, it has to temporarily take control of their machines, 
> deliver a test such that the user doesn’t cheat (by having other apps like a 
> web browser available), and the test content isn’t copied

This sounds like a completely impossible situation. How do you prevent the user 
from opening a web browser on their phone or tablet, or on another computer 
nearby? Or from calling someone to get answers, or having someone nearby to 
give them answers?

The only solution seems to be on-site human proctoring.

—Jens
___

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

Re: Disabling screen capture

[Jim Zajkowski]

It sounds like the computers are owned by the people taking the test,
and are not owned by the testing center.

How is the test data delivered to the client?

What's to prevent someone from grabbing network traffic and memory of
the test application in the background?

--Jim

On Fri, Feb 21, 2014 at 12:55 PM, Bradley O'Hearne
 wrote:
> On Feb 21, 2014, at 10:08 AM, Uli Kusterer  
> wrote:
>
>> On 21 Feb 2014, at 17:54, Bradley O'Hearne  wrote:
>>> - A kiosk-type environment isn't some kind of wacky edge use-case. The 
>>> question really distills down to whether or not OS X provides APIs that 
>>> allow an app to facilitate a secure kiosk-type environment. Maybe the 
>>> design philosophy behind OS X is opposed to this scenario / use-case. I 
>>> hope that isn't the case, but if it is, that's an answer, and while not the 
>>> desired answer, we can move forward with the knowledge that OS X kiosks 
>>> aren't an option.
>>
>>
>> Wait, this is a controlled Kiosk situation? In that case, registering a 
>> global hotkey that overrides Cmd-Shift-3 and Cmd-Shift-4 should probably 
>> work ... ? Though I'm confused, if you're in Kiosk mode, the user couldn't 
>> even copy a screenshot made.
>
> Uli -- thanks for the reply. Few things:
>
> - I've tried registering a global hotkey -- it doesn't override Cmd-Shift-3 
> or -4, it just adds a new function to it. Apparently global hotkeys can 
> "hook" (if that's the right word) at multiple levels. I've actually found a 
> way to deal with those keystroke commands, though a pain and less than 
> elegant (and annoying for the user). It involves some Carbon calls and (on 
> Mavericks) having to open System Preferences - > Security & Privacy -> 
> Accessibility settings. But that doesn't solve the problem of remote desktop, 
> screen recording, Airplay, etc.
>
> - I apologize if I confused things by mentioning kiosks. I used that term 
> because it is a common reference point that might quickly explain the idea. 
> In reality, this isn't a physical kiosk, like one you'd find in a mall, that 
> belongs to no user, and is dedicated to the purpose. This is rather an app 
> running on users' Macs, its just that when the app runs, it has to 
> temporarily take control of their machines, deliver a test such that the user 
> doesn't cheat (by having other apps like a web browser available), and the 
> test content isn't copied, and as soon as the app is exited, things return to 
> normal. While the user is taking the test, they are proctored by a live 
> person via an internal / external video camera, which streams video to a 
> proctoring center full of proctors.
>
> Perhaps I can rephrase the design requirement here in terms (this specific 
> example is is fictional for example) which illustrate better the scenario:
>
> A potential high-profile organization approaches your company and says, "If 
> you can deliver our very expensive certification tests to users' Macs, 
> prevent users from cheating, and prevent them from using their Macs (via 
> screenshots, screen scraping, remote desktop, screen recording, etc.) to copy 
> the test content being delivered, we will pay your organization $250K per 
> year. If you can't secure our test content being delivered, we will not use 
> your product at all."
>
> So, can OS X handle this use-case?
>
> Brad
> ___
>
> 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/jim.zajkowski%40gmail.com
>
> This email sent to jim.zajkow...@gmail.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

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 21, 2014, at 10:08 AM, Uli Kusterer  wrote:

> On 21 Feb 2014, at 17:54, Bradley O'Hearne  wrote:
>> - A kiosk-type environment isn’t some kind of wacky edge use-case. The 
>> question really distills down to whether or not OS X provides APIs that 
>> allow an app to facilitate a secure kiosk-type environment. Maybe the design 
>> philosophy behind OS X is opposed to this scenario / use-case. I hope that 
>> isn’t the case, but if it is, that’s an answer, and while not the desired 
>> answer, we can move forward with the knowledge that OS X kiosks aren’t an 
>> option. 
> 
> 
> Wait, this is a controlled Kiosk situation? In that case, registering a 
> global hotkey that overrides Cmd-Shift-3 and Cmd-Shift-4 should probably work 
> … ? Though I'm confused, if you're in Kiosk mode, the user couldn't even copy 
> a screenshot made.

Uli — thanks for the reply. Few things: 

- I’ve tried registering a global hotkey — it doesn’t override Cmd-Shift-3 or 
-4, it just adds a new function to it. Apparently global hotkeys can “hook” (if 
that’s the right word) at multiple levels. I’ve actually found a way to deal 
with those keystroke commands, though a pain and less than elegant (and 
annoying for the user). It involves some Carbon calls and (on Mavericks) having 
to open System Preferences - > Security & Privacy -> Accessibility settings. 
But that doesn’t solve the problem of remote desktop, screen recording, 
Airplay, etc. 

- I apologize if I confused things by mentioning kiosks. I used that term 
because it is a common reference point that might quickly explain the idea. In 
reality, this isn’t a physical kiosk, like one you’d find in a mall, that 
belongs to no user, and is dedicated to the purpose. This is rather an app 
running on users’ Macs, its just that when the app runs, it has to temporarily 
take control of their machines, deliver a test such that the user doesn’t cheat 
(by having other apps like a web browser available), and the test content isn’t 
copied, and as soon as the app is exited, things return to normal. While the 
user is taking the test, they are proctored by a live person via an internal / 
external video camera, which streams video to a proctoring center full of 
proctors. 

Perhaps I can rephrase the design requirement here in terms (this specific 
example is is fictional for example) which illustrate better the scenario:

A potential high-profile organization approaches your company and says, “If you 
can deliver our very expensive certification tests to users’ Macs, prevent 
users from cheating, and prevent them from using their Macs (via screenshots, 
screen scraping, remote desktop, screen recording, etc.) to copy the test 
content being delivered, we will pay your organization $250K per year. If you 
can’t secure our test content being delivered, we will not use your product at 
all.” 

So, can OS X handle this use-case?

Brad
___

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

Re: Disabling screen capture

[Uli Kusterer]

On 21 Feb 2014, at 17:54, Bradley O'Hearne  wrote:
> - A kiosk-type environment isn’t some kind of wacky edge use-case. The 
> question really distills down to whether or not OS X provides APIs that allow 
> an app to facilitate a secure kiosk-type environment. Maybe the design 
> philosophy behind OS X is opposed to this scenario / use-case. I hope that 
> isn’t the case, but if it is, that’s an answer, and while not the desired 
> answer, we can move forward with the knowledge that OS X kiosks aren’t an 
> option. 


Wait, this is a controlled Kiosk situation? In that case, registering a global 
hotkey that overrides Cmd-Shift-3 and Cmd-Shift-4 should probably work … ? 
Though I'm confused, if you're in Kiosk mode, the user couldn't even copy a 
screenshot made.

-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."




___

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

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 20, 2014, at 4:23 PM, dangerwillrobinsondan...@gmail.com wrote:
>> On 2014/02/21, at 8:05, Stevo Brock  wrote:
>> 
>>> On Feb 20, 2014, at 2:39 PM, Jens Alfke wrote:
>>> 
>>> If I were trying to circumvent this I'd just use my iPhone camera to take a 
>>> photo or video of the screen. (Or open my web browser and search for 
>>> pictures taken by someone else who did.) As there's no way to block that, 
>>> why bother?
...
>>> 
>>> Why not follow the proverb "Locks are there to keep honest people out”,
...
>>> Some things just aren't worth doing.
>> 
>> I don't know if you have this in place or not, but what about embedding some 
>> identifying information in the midst of the important content, such that if 
>> posted images were discovered, they could be traced back?
...
> That sort of thing is defeated easily by accident with image resizing alone. 
….
> Really seriously evaluate the risks and trade offs before making commitments 
> with these kind of requirements. 

Gents…thanks for all of the replies, just a few responses: 

- Yes, there will always be external means to copy content. But that doesn’t 
make the need to protect content ridiculous, and our scope of responsibility is 
the app’s environment on the computer, not external hardware. (One other note — 
these tests are video-proctored, so the user is under constant watch by a 
proctor, so you can’t pull out your iPhone and start snapping pics). 

- This isn’t a requirement I have any control over. I am merely tasked with 
figuring out how to provide the behavior. 

- This is a feature which isn’t a negotiable even for my client in order to 
gain certain potential customers business. Their content has to be secured, or 
the product can’t be used. It is a deal-breaker, so there’s no negotiable there 
either. 

- A kiosk-type environment isn’t some kind of wacky edge use-case. The question 
really distills down to whether or not OS X provides APIs that allow an app to 
facilitate a secure kiosk-type environment. Maybe the design philosophy behind 
OS X is opposed to this scenario / use-case. I hope that isn’t the case, but if 
it is, that’s an answer, and while not the desired answer, we can move forward 
with the knowledge that OS X kiosks aren’t an option. 

- Watermarking isn’t really an option, even tracing doesn’t help, because that 
doesn’t mitigate the damage done. The issue isn’t copyrighting, or even 
catching the person who has copied content after the fact. The issue is 
preventing the copying of proprietary test content and destroying a costly 
investment in the development of certification exams. 

In conclusion — the need for this is absolutely huge in scope. This need 
touches every school, college, and organization with testing of any kind on the 
planet (that’s just our present scope). But beyond that, being able to deliver 
content in secure fashion is a fundamental need in education, financial, 
medical, legal, government, and defense industries. So again, it is just a 
question of whether OS X is an appropriate OS for this — I’d like to think it 
is. 

Brad
___

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

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 21, 2014, at 5:33 AM, Uli Kusterer  wrote:

> On 20 Feb 2014, at 20:58, Bradley O'Hearne  wrote:
>> At WWDC 2013, I approached the Apple engineering teams with a need that a 
>> client of mine had to disable all screen capture while an app was running. 
>> This includes the hotkeys for taking screenshots, capturing displays with 
>> AVFoundation, remote desktop apps, Airplay, etc. As to the specific use case 
>> in play here, the issue is that there is proprietary content delivered via 
>> the app — and the owners of this content need that content secured such that 
>> there is no easy facility *on the machine it is running on* to capture this 
>> content. Please forgive the length of what follows, but a little explanation 
>> is necessary. 
> 
> 
> I would expect NSWindow's -setSharingType: NSWindowSharingNone method to 
> allow doing that. Have you tried that?

Uli — thanks for the reply. I would have expected the same thing, but it 
doesn’t prevent either Command-Shift-3 or Command-Shift-4 screen shots, nor 
screen recording (such as in QuickTime or with a tool like ScreenFlow). Kind of 
a dubious property naming given that it doesn’t really prevent sharing of 
window content. 

Brad
___

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

Re: Disabling screen capture

[Uli Kusterer]

On 20 Feb 2014, at 20:58, Bradley O'Hearne  wrote:
> At WWDC 2013, I approached the Apple engineering teams with a need that a 
> client of mine had to disable all screen capture while an app was running. 
> This includes the hotkeys for taking screenshots, capturing displays with 
> AVFoundation, remote desktop apps, Airplay, etc. As to the specific use case 
> in play here, the issue is that there is proprietary content delivered via 
> the app — and the owners of this content need that content secured such that 
> there is no easy facility *on the machine it is running on* to capture this 
> content. Please forgive the length of what follows, but a little explanation 
> is necessary. 


 I would expect NSWindow's -setSharingType: NSWindowSharingNone method to allow 
doing that. Have you tried that?

-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."




___

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

Re: Disabling screen capture

[dangerwillrobinsondanger]

> On 2014/02/21, at 8:05, Stevo Brock  wrote:
> 
>> On Feb 20, 2014, at 2:39 PM, Jens Alfke wrote:
>> 
>> 
>>> On Feb 20, 2014, at 11:58 AM, Bradley O'Hearne  
>>> wrote:
>>> 
>>> The app is delivering tests remotely ― some of which are not your typical 
>>> classroom college exams, but very privately held, very expensive 
>>> certification tests which clients have spent many thousands of dollars to 
>>> create. This test content needs to be secured, and not easily copied while 
>>> the app is running. Yes, I am aware of various hardware hacks or video 
>>> options that can be accomplished external to the machine ― those are out of 
>>> scope for this question.
>> 
>> If I were trying to circumvent this I'd just use my iPhone camera to take a 
>> photo or video of the screen. (Or open my web browser and search for 
>> pictures taken by someone else who did.) As there's no way to block that, 
>> why bother?
>> 
>> Yes, this isn't a direct answer to your question. But I feel that any 
>> attempt to protect content this way becomes a race to the bottom, with ever 
>> more onerous restrictions in the OS (viz. the Windows kernel stuff Doug 
>> mentioned) that still don't end up deterring people who are determined to 
>> copy.
>> 
>> Why not follow the proverb "Locks are there to keep honest people out", and 
>> put in some basic guards against screen-shots, maybe like capturing the 
>> Cmd-Shift-3 / 4 keystrokes? Going further would IMHO be a time- and 
>> money-sink for you, and still wouldn't prevent copying.
>> 
>> I understand your frustration that people keep telling you "don't do this" 
>> instead of helping you do it, but that's actually one of the things I like 
>> about this list: people will look beyond the immediate question and give 
>> advice on the big picture. Some things just aren't worth doing.
>> 
>> ―Jens
> 
> I don't know if you have this in place or not, but what about embedding some 
> identifying information in the midst of the important content, such that if 
> posted images were discovered, they could be traced back?
> 
> -Stevo Brock
> Sunset Magicwerks, LLC
> www.sunsetmagicwerks.com
> 818-478-9758
> 
>> ___

That sort of thing is defeated easily by accident with image resizing alone. 

Ultimately it sounds like you want to build a kiosk in a controlled 
environment. 
You would need the following to succeed.
Managed user account. 
Kiosk mode application. 
Limited physical access to hardware including the power button and power 
supply. 
Physical screening for camera devices on users. 
(Difficult today. )

That's what would be required to achieve this. 

Coming closer with less would mean installing and doing ridiculous things in 
the system that would likely reduce security or stability and be fragile to 
maintain. 

So as always security is a trade off for user experience quality. 
Really seriously evaluate the risks and trade offs before making commitments 
with these kind of requirements. 
___

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

Re: Disabling screen capture

[Stevo Brock]

On Feb 20, 2014, at 2:39 PM, Jens Alfke wrote:

> 
> On Feb 20, 2014, at 11:58 AM, Bradley O'Hearne  
> wrote:
> 
>> The app is delivering tests remotely — some of which are not your typical 
>> classroom college exams, but very privately held, very expensive 
>> certification tests which clients have spent many thousands of dollars to 
>> create. This test content needs to be secured, and not easily copied while 
>> the app is running. Yes, I am aware of various hardware hacks or video 
>> options that can be accomplished external to the machine — those are out of 
>> scope for this question.
> 
> If I were trying to circumvent this I'd just use my iPhone camera to take a 
> photo or video of the screen. (Or open my web browser and search for pictures 
> taken by someone else who did.) As there's no way to block that, why bother?
> 
> Yes, this isn't a direct answer to your question. But I feel that any attempt 
> to protect content this way becomes a race to the bottom, with ever more 
> onerous restrictions in the OS (viz. the Windows kernel stuff Doug mentioned) 
> that still don't end up deterring people who are determined to copy.
> 
> Why not follow the proverb "Locks are there to keep honest people out", and 
> put in some basic guards against screen-shots, maybe like capturing the 
> Cmd-Shift-3 / 4 keystrokes? Going further would IMHO be a time- and 
> money-sink for you, and still wouldn't prevent copying.
> 
> I understand your frustration that people keep telling you "don't do this" 
> instead of helping you do it, but that's actually one of the things I like 
> about this list: people will look beyond the immediate question and give 
> advice on the big picture. Some things just aren't worth doing.
> 
> —Jens

I don't know if you have this in place or not, but what about embedding some 
identifying information in the midst of the important content, such that if 
posted images were discovered, they could be traced back?

-Stevo Brock
 Sunset Magicwerks, LLC
 www.sunsetmagicwerks.com
 818-478-9758

> ___
> 
> 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%40sunsetmagicwerks.com
> 
> This email sent to devli...@sunsetmagicwerks.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

Re: Disabling screen capture

[Jens Alfke]

On Feb 20, 2014, at 11:58 AM, Bradley O'Hearne  
wrote:

> The app is delivering tests remotely — some of which are not your typical 
> classroom college exams, but very privately held, very expensive 
> certification tests which clients have spent many thousands of dollars to 
> create. This test content needs to be secured, and not easily copied while 
> the app is running. Yes, I am aware of various hardware hacks or video 
> options that can be accomplished external to the machine — those are out of 
> scope for this question.

If I were trying to circumvent this I'd just use my iPhone camera to take a 
photo or video of the screen. (Or open my web browser and search for pictures 
taken by someone else who did.) As there's no way to block that, why bother?

Yes, this isn't a direct answer to your question. But I feel that any attempt 
to protect content this way becomes a race to the bottom, with ever more 
onerous restrictions in the OS (viz. the Windows kernel stuff Doug mentioned) 
that still don't end up deterring people who are determined to copy.

Why not follow the proverb "Locks are there to keep honest people out", and put 
in some basic guards against screen-shots, maybe like capturing the Cmd-Shift-3 
/ 4 keystrokes? Going further would IMHO be a time- and money-sink for you, and 
still wouldn't prevent copying.

I understand your frustration that people keep telling you "don't do this" 
instead of helping you do it, but that's actually one of the things I like 
about this list: people will look beyond the immediate question and give advice 
on the big picture. Some things just aren't worth doing.

—Jens
___

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

Re: Disabling screen capture

[Doug Hill]

My personal feeling is that this will never happen. I seem to recall one of the 
reasons Apple doesn't support Blu-Ray is because of the onerous requirements of 
the content industries to provide DRM at the kernel level. For example, Windows 
has facilities in the kernel to check if there is a bus sniffer, protects the 
video content at the GPU level, etc. DVDs already kind of work this way (try to 
screenshot a DVD, go ahead) due to special support in the GPU/optical drive 
that already exists, so that video data doesn't go to main RAM. It should be 
noted, however, it's much easier to rip a DVD than do a screenshot.

At the very least, I doubt this will get resolved in any time-frame for your 
product/company.

$0.02

Doug Hill

On Feb 20, 2014, at 12:25 PM, Bradley O'Hearne  
wrote:

> 
> On Feb 20, 2014, at 1:12 PM, Kyle Sluder  wrote:
> 
>> On Thu, Feb 20, 2014, at 11:58 AM, Bradley O'Hearne wrote:
>>> 
>>> So my concluding questions are targeted at a general use case of trying
>>> to disable the ability to capture content which is delivered to and
>>> temporarily displayed within an app within OS X. 
>>> 
>>> 1. Does anyone know a possible way this can be accomplished with existing
>>> API?
>> 
>> I highly doubt you will ever be able to disable screen capture of the
>> entire screen. But clearly DVD Player is able to prevent capture of its
>> window, and I think maybe iBooks does too. Though they might not use
>> public API.
>> 
>> Rather than just filing enhancement requests into the black hole of Bug
>> Reporter, you ought to file a DTS incident:
>> 
>> 
>> Unlike Bug Reporter, DTS engineers are actually paid to give you
>> hands-on support with writing code. They might know of certain tricks
>> you can pull, and they might be able to advocate internally for
>> implementing the enhancement requests you have already filed.
> 
> 
> Kyle — thanks for the reply. If we can prevent capturing of just our app, 
> that would work, but the problem is not just a screen capture, but Airplay, 
> and remote desktop too. All of those provide options that effectively allows 
> all the content to be piped to external machines, where it can be recorded 
> there — Window sharing options don’t effect that — I believe those act at the 
> display level. I know both CoreGraphics and AVFoundation 
> (AVCaptureScreenInput) provide ways to record the contents of the display, so 
> somehow that has to be disabled. As for the DVD Player approach, the Apple 
> engineers I spoke with made it pretty clear that this was being facilitated 
> via private API and wasn’t an option. 
> 
> I’ll try the DTS route, but I’ve had multiple instances of filing DTS issues 
> and waiting several months to get initial response. Unfortunately, there’s a 
> level of urgency that won’t allow for a late-or-never wait, so I was hoping 
> for a little luck in hooking a list guru or engineer who either had an answer 
> or could put me through to the right people. I’ll go ahead and file with DTS 
> though, and maybe it will be different this time around. 
> 
> Thanks again,
> 
> Brad
> ___
> 
> 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/cocoadev%40breaqz.com
> 
> This email sent to cocoa...@breaqz.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

Re: Disabling screen capture

[Bradley O'Hearne]

On Feb 20, 2014, at 1:12 PM, Kyle Sluder  wrote:

> On Thu, Feb 20, 2014, at 11:58 AM, Bradley O'Hearne wrote:
>> 
>> So my concluding questions are targeted at a general use case of trying
>> to disable the ability to capture content which is delivered to and
>> temporarily displayed within an app within OS X. 
>> 
>> 1. Does anyone know a possible way this can be accomplished with existing
>> API?
> 
> I highly doubt you will ever be able to disable screen capture of the
> entire screen. But clearly DVD Player is able to prevent capture of its
> window, and I think maybe iBooks does too. Though they might not use
> public API.
> 
> Rather than just filing enhancement requests into the black hole of Bug
> Reporter, you ought to file a DTS incident:
> 
> 
> Unlike Bug Reporter, DTS engineers are actually paid to give you
> hands-on support with writing code. They might know of certain tricks
> you can pull, and they might be able to advocate internally for
> implementing the enhancement requests you have already filed.


Kyle — thanks for the reply. If we can prevent capturing of just our app, that 
would work, but the problem is not just a screen capture, but Airplay, and 
remote desktop too. All of those provide options that effectively allows all 
the content to be piped to external machines, where it can be recorded there — 
Window sharing options don’t effect that — I believe those act at the display 
level. I know both CoreGraphics and AVFoundation (AVCaptureScreenInput) provide 
ways to record the contents of the display, so somehow that has to be disabled. 
As for the DVD Player approach, the Apple engineers I spoke with made it pretty 
clear that this was being facilitated via private API and wasn’t an option. 

I’ll try the DTS route, but I’ve had multiple instances of filing DTS issues 
and waiting several months to get initial response. Unfortunately, there’s a 
level of urgency that won’t allow for a late-or-never wait, so I was hoping for 
a little luck in hooking a list guru or engineer who either had an answer or 
could put me through to the right people. I’ll go ahead and file with DTS 
though, and maybe it will be different this time around. 

Thanks again,

Brad
___

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

Re: Disabling screen capture

[Kyle Sluder]

On Thu, Feb 20, 2014, at 11:58 AM, Bradley O'Hearne wrote:
> 
> So my concluding questions are targeted at a general use case of trying
> to disable the ability to capture content which is delivered to and
> temporarily displayed within an app within OS X. 
> 
> 1. Does anyone know a possible way this can be accomplished with existing
> API?

I highly doubt you will ever be able to disable screen capture of the
entire screen. But clearly DVD Player is able to prevent capture of its
window, and I think maybe iBooks does too. Though they might not use
public API.

Rather than just filing enhancement requests into the black hole of Bug
Reporter, you ought to file a DTS incident:


Unlike Bug Reporter, DTS engineers are actually paid to give you
hands-on support with writing code. They might know of certain tricks
you can pull, and they might be able to advocate internally for
implementing the enhancement requests you have already filed.

Good luck,

--Kyle Sluder
___

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