Turning off screen shot ability

  • Hello,

    I am working on a security-related Mac app and I need to know the way to turn off the ability to screen shot or capture the contents of the app's window. It would appear that setting the sharing type on the main window (which covers the entire screen) to none doesn't completely do it. It appears that Shift-Cmd-3 still performs a screen shot. I've already tried capturing keystrokes and it appears these system-level hot-key combinations aren't able to be cleanly intercepted. More than that, I would think this is overkill -- I would think there would be a simple way to turn off the ability for outside sources to grab contents of an app.

    How can I turn this off?

    Thanks,

    Brad
  • On Mar 5, 2013, at 8:57 PM, Brad O'Hearne wrote:

    > I am working on a security-related Mac app and I need to know the way to turn off the ability to screen shot or capture the contents of the app's window.

    No, what you need to do is recognize the fundamental stupidity of the requirement and drop it.

    --
    Scott Ribe
    <scott_ribe...>
    http://www.elevated-dev.com/
    (303) 722-0567 voice
  • Am 06.03.2013 um 06:13 schrieb Scott Ribe:

    > On Mar 5, 2013, at 8:57 PM, Brad O'Hearne wrote:
    >
    >> I am working on a security-related Mac app and I need to know the way to turn off the ability to screen shot or capture the contents of the app's window.
    >
    > No, what you need to do is recognize the fundamental stupidity of the requirement and drop it.

    Would you be so kind as to elaborate on your statement, i.e. the "fundamental stupidity"?

    > --
    > Scott Ribe
    > <scott_ribe...>
    > http://www.elevated-dev.com/
    > (303) 722-0567 voice
    >
  • > Would you be so kind as to elaborate on your statement, i.e. the "fundamental stupidity"?

    I didn't make the original statement but perhaps I can shed some light. Even if, hypothetically, you were able to disable the cmd-shift-3 keyboard shortcut there many, many other ways for a person to capture screen contents. There are 3rd party apps for screen capture, they could mirror the screen and put a sniffer on the video cable, they could eavesdrop on the EM radiation given off by the monitor and recreate the image inductively (yes, this has been done), to say nothing of the most obvious issue: cameras, which are bound to be almost every pocket you come across. There're also screen readers and other assistive devices that expose the same information. Attempting solve any of these "problems", let alone all of them, is a losing battle and would only serve to frustrate legitimate users.
  • Have tried changing it in system preferences?
    Beyond that look into managed user accounts and creating user account templates in OS X server.
    You might not need a programmatic solution. Sounds like an account solution.
    But, it's always easy to take a photo and you will still need to do something about apps like QuickTime X and Grab.
    They're bundled.
    You'll also need to look at all other apps and browser plugins.
    The worst part is potentially for accessibility functionality. That may also run you into a wall if legal compliance in various countries.
    Oh there is also Automator and AppleScript and screenshots can be done via terminal.

    Quite a rabbit hole you're in.

    On 2013/03/06, at 12:57, Brad O'Hearne <brado...> wrote:

    > Hello,
    >
    > I am working on a security-related Mac app and I need to know the way to turn off the ability to screen shot or capture the contents of the app's window. It would appear that setting the sharing type on the main window (which covers the entire screen) to none doesn't completely do it. It appears that Shift-Cmd-3 still performs a screen shot. I've already tried capturing keystrokes and it appears these system-level hot-key combinations aren't able to be cleanly intercepted. More than that, I would think this is overkill -- I would think there would be a simple way to turn off the ability for outside sources to grab contents of an app.
    >
    > How can I turn this off?
    >
    > Thanks,
    >
    >
    >
  • I appreciate the desire of a few here to communicate your perceived futility of turning off screen shots or window capture. I do not want to digress into a philosophical discussion here, I just want to stick to talk of the capabilities of machinery -- but given that the responses here pretty much scan with the discussions I found at various forums online, I want to just briefly address the futility issue.

    Because a security measure can be breached, either in common practice or in theory, does not mean that it is either futile, or that it is wise to just throw it away. I could give a very long list of examples of this, but for brevity, just a few:

    - Passwords can be breached, but yet we still actively use and recommend using them.
    - SSL can be breached, yet it is the protocol foundation for most secure communication on the Internet.
    - An ATM pin can be breached, yet all of us are no doubt happy that our banks didn't just issue us code-less cash cards which pull directly from our bank accounts.
    - Car and house locks can be quite easily breached, but yet we still continue to put them in cars and house doors.

    Finally, every security system on the planet can be breached by social engineering. Given that there may be no such thing as a 100% secure system, does that mean it is wise to throw off security measures? No. Eliminating 99% (or 90%, or 80%) of potential breaches is useful. Even slowing down a breach is useful on a number of levels.

    I would like to avoid everyone's personal editorial on the value of turning off screen capture is or not, as it is a foregone conclusion that we need this in place. My client is in the security business, and while the details of their product are not going to be discussed here, suffice to say, their use case is a completely legitimate pursuit of turning off screen capture -- and that is with full consideration of alternate means of capture, not ignoring them.

    So that said, to retrench back to the original question, I am interested in the capabilities of the machine (OS X) and if so, how. I need to programmatically within an app (not by external system administration) turn off all screen capture capability, by hotkeys, or by grabbing the contents of the window. For those who have mentioned screen capture apps as a way to breach this, you might be interested to know that with one common screen capture app (I tested with ScreenFlow) that setting the NSWindow's sharingType to NSWindowSharingNone prevents it from capturing the active window. The primary hole appears to be OS X screen capture hotkeys, and in that regard, I'm really interested why setting the sharingType to none, which is supposed to prevent other processes from capturing the contents of the window (and does in some cases) allows OS X to still capture the screen.

    To distill it -- does OS X have the programmatic ability to turn off screen capture, and if so, how? It is just a question of whether the machine can do it or not. While I appreciate the other sentiments, I can assure you this use is completely legit. Either OS X has the ability or it doesn't -- that, and how it is turned off (if it can be) is all I need to determine. One other responder said that he's encountered other apps which *can* do this, so if someone in the know could pass on the 4-1-1, I would be very appreciative.

    Thanks in advance,

    Brad

    On Mar 6, 2013, at 12:51 AM, Izzy Fraimow <frozendevil+<cocoa-dev...> wrote:

    >> Would you be so kind as to elaborate on your statement, i.e. the "fundamental stupidity"?
    >
    > I didn't make the original statement but perhaps I can shed some light. Even if, hypothetically, you were able to disable the cmd-shift-3 keyboard shortcut there many, many other ways for a person to capture screen contents. There are 3rd party apps for screen capture, they could mirror the screen and put a sniffer on the video cable, they could eavesdrop on the EM radiation given off by the monitor and recreate the image inductively (yes, this has been done), to say nothing of the most obvious issue: cameras, which are bound to be almost every pocket you come across. There're also screen readers and other assistive devices that expose the same information. Attempting solve any of these "problems", let alone all of them, is a losing battle and would only serve to frustrate legitimate users.
  • On Mar 6, 2013, at 8:37 AM, Brad O'Hearne <brado...> wrote:

    > I am interested in the capabilities of the machine (OS X) and if so, how. I need to programmatically within an app (not by external system administration) turn off all screen capture capability, by hotkeys, or by grabbing the contents of the window.

    Apple’s DVD player app does this, for DRM purposes*. I don’t know how it manages it, whether it’s some public system API or an internal-only thing … but it might be a useful clue to track down.

    —Jens

    * And whatever people think about the legitimacy of that reason, it was imposed on Apple by the movie studios as a precondition for being able to use the DVD decryption codec.
  • Why would there be a simple way?

    A simple way off would require a simple way on to avoid breaking a
    plethora of apps.

    Screenshots and screen movies are how many apps are easily and quickly
    documented by honest consultants and IT help desks; a vital tool. As a
    developer, I know everyone else has full access to my UI and I
    theirs... no biggie.

    In all seriousness though, you may want to approach Apple DTS directly
    and present your business case to them.

    Consider the small possibility that MacOS may not be a platform
    suitable for your app, given its general consumer-centric market.

    Also, you may need to solve problems because of sandboxing.

    Talk to Apple DTS.

    Good Luck!

    Gary

    On Mar 6, 2013, at 5:29 AM, <dangerwillrobinsondanger...> wrote:

    > Have tried changing it in system preferences?
    > Beyond that look into managed user accounts and creating user
    > account templates in OS X server.
    > You might not need a programmatic solution. Sounds like an account
    > solution.
    > But, it's always easy to take a photo and you will still need to do
    > something about apps like QuickTime X and Grab.
    > They're bundled.
    > You'll also need to look at all other apps and browser plugins.
    > The worst part is potentially for accessibility functionality. That
    > may also run you into a wall if legal compliance in various countries.
    > Oh there is also Automator and AppleScript and screenshots can be
    > done via terminal.
    >
    > Quite a rabbit hole you're in.
    >
    > On 2013/03/06, at 12:57, Brad O'Hearne <brado...>
    > wrote:
    >
    >> Hello,
    >>
    >> I am working on a security-related Mac app and I need to know the
    >> way to turn off the ability to screen shot or capture the contents
    >> of the app's window. It would appear that setting the sharing type
    >> on the main window (which covers the entire screen) to none doesn't
    >> completely do it. It appears that Shift-Cmd-3 still performs a
    >> screen shot. I've already tried capturing keystrokes and it appears
    >> these system-level hot-key combinations aren't able to be cleanly
    >> intercepted. More than that, I would think this is overkill -- I
    >> would think there would be a simple way to turn off the ability for
    >> outside sources to grab contents of an app.
    >>
    >> How can I turn this off?
    >>
    >> Thanks,
    >>
    >>
    >>

  • > Why would there be a simple way?

    I can think of a few reasons:

    1. Using NSApplicationPresentationOptions, you can enforce the following programmatically: auto-hide the system dock, hide the system dock entirely, auto-hide the system menu bar, hide the system menu-bar entirely, completely disable the system Apple menu, disable process switching between apps, disable the ability to force-quit an app, disable app session termination, disable the ability to hide an application, disable menu bar transparency, present your app full screen, and auto-hide the toolbar. These are all clearly aimed at giving an app control of its presentation and environment. A very obvious reason an app would need to control its presentation is in order to control the content presented within.

    2. NSWindow allows you to specify the level of access other processes have to the window's content. Aside from the fact that is seems a bit bizarre that there's the ability to grant no access (NSWindowSharingNone, which doc states should prevent the window's contents to be read by another process), and a screen shot still works, the mere presence of this configurable parameter acknowledges the potential need of an app to secure its displayed content. Therefore, it doesn't seem such a stretch to imagine that if a window's contents were secured, that screen shots would follow right along as something desired to be turned off.

    > Screenshots and screen movies are how many apps are easily and quickly documented by honest consultants and IT help desks; a vital tool. As a developer, I know everyone else has full access to my UI and I theirs... no biggie.

    I get the sentiment, and I think it follows with most of discussions I've found elsewhere online about this that the general misperception about the need to turn off this ability stems from some draconian developer wanting unreasonable rigidity and control in an app like a game or something casual. I'm sure there are those folks out there who have such motivations. This is not one of them, and if interested in thinking this through, I would encourage a slight shift in perspective.

    Again, I am not at liberty to speak in detail about the specific use-case, but I can speak to the nature of the need. Ultimately, this is not an issue of needing to secure the app itself. The app is really just scaffolding if you will....a pipeline. The app is just a delivery mechanism -- but the content it is delivering needs to be secured. A few others have accurately mentioned an example which demonstrates this -- DRM -- for securing music, movies, books, etc. This is a great example, there's no particular need for iTunes to be secured (for the app itself), but the content it is delivering, that's another matter -- DRM has certain requirements, as do the copyright holding entities have contractual requirements for securing such.

    The specific use-case I am dealing with isn't a music or movie sharing app, and the specifics aren't really important anyway. But I'm sure everyone can draw a distinction between someone trying to prevent screen shots of their favorite first-person-shooter game, and trying to secure private research, government or military information, or confidential documents. My use-case is in the latter category -- and the target of screen-shot prevention isn't necessarily even the user or a user's nefarious intent -- it might be other agents on the machine, or it might be preventing an accidental or arbitrary screen shot which gets left on a machine or is accidentally sent to a printer.

    So in a nutshell, shift the perspective -- this isn't an enemy-of-the-user thing. It is a help and safeguard for both the content provider, and the content consumer (user). I hope that helps to paint the picture a little clearer.

    > In all seriousness though, you may want to approach Apple DTS directly and present your business case to them.

    That is good advice. Thanks for the tip.

    Brad
  • Fine,

    Good rehearsal, but we are not the folks you need support from.

    If it was easy, Google would have it listed or someone here would have
    quickly replied.

    You have a special need, that's fine and what DTS is all about. Go for
    it.

    Gary

    On Mar 6, 2013, at 1:43 PM, Brad O'Hearne wrote:

    >
    >> Why would there be a simple way?
    >
    > I can think of a few reasons:
    >
    > 1. Using NSApplicationPresentationOptions, you can enforce the
    > following programmatically: auto-hide the system dock, hide the
    > system dock entirely, auto-hide the system menu bar, hide the system
    > menu-bar entirely, completely disable the system Apple menu, disable
    > process switching between apps, disable the ability to force-quit an
    > app, disable app session termination, disable the ability to hide an
    > application, disable menu bar transparency, present your app full
    > screen, and auto-hide the toolbar. These are all clearly aimed at
    > giving an app control of its presentation and environment. A very
    > obvious reason an app would need to control its presentation is in
    > order to control the content presented within.
    >
    > 2. NSWindow allows you to specify the level of access other
    > processes have to the window's content. Aside from the fact that is
    > seems a bit bizarre that there's the ability to grant no access
    > (NSWindowSharingNone, which doc states should prevent the window's
    > contents to be read by another process), and a screen shot still
    > works, the mere presence of this configurable parameter acknowledges
    > the potential need of an app to secure its displayed content.
    > Therefore, it doesn't seem such a stretch to imagine that if a
    > window's contents were secured, that screen shots would follow right
    > along as something desired to be turned off.
    >
    >> Screenshots and screen movies are how many apps are easily and
    >> quickly documented by honest consultants and IT help desks; a vital
    >> tool. As a developer, I know everyone else has full access to my UI
    >> and I theirs... no biggie.
    >
    > I get the sentiment, and I think it follows with most of discussions
    > I've found elsewhere online about this that the general
    > misperception about the need to turn off this ability stems from
    > some draconian developer wanting unreasonable rigidity and control
    > in an app like a game or something casual. I'm sure there are those
    > folks out there who have such motivations. This is not one of them,
    > and if interested in thinking this through, I would encourage a
    > slight shift in perspective.
    >
    > Again, I am not at liberty to speak in detail about the specific use-
    > case, but I can speak to the nature of the need. Ultimately, this is
    > not an issue of needing to secure the app itself. The app is really
    > just scaffolding if you will....a pipeline. The app is just a
    > delivery mechanism -- but the content it is delivering needs to be
    > secured. A few others have accurately mentioned an example which
    > demonstrates this -- DRM -- for securing music, movies, books, etc.
    > This is a great example, there's no particular need for iTunes to be
    > secured (for the app itself), but the content it is delivering,
    > that's another matter -- DRM has certain requirements, as do the
    > copyright holding entities have contractual requirements for
    > securing such.
    >
    > The specific use-case I am dealing with isn't a music or movie
    > sharing app, and the specifics aren't really important anyway. But
    > I'm sure everyone can draw a distinction between someone trying to
    > prevent screen shots of their favorite first-person-shooter game,
    > and trying to secure private research, government or military
    > information, or confidential documents. My use-case is in the latter
    > category -- and the target of screen-shot prevention isn't
    > necessarily even the user or a user's nefarious intent -- it might
    > be other agents on the machine, or it might be preventing an
    > accidental or arbitrary screen shot which gets left on a machine or
    > is accidentally sent to a printer.
    >
    > So in a nutshell, shift the perspective -- this isn't an enemy-of-
    > the-user thing. It is a help and safeguard for both the content
    > provider, and the content consumer (user). I hope that helps to
    > paint the picture a little clearer.
    >
    >> In all seriousness though, you may want to approach Apple DTS
    >> directly and present your business case to them.
    >
    > That is good advice. Thanks for the tip.
    >
    > Brad
    >
  • On Mar 6, 2013, at 1:49 PM, M Pulis <toothpic...> wrote:

    > Fine,
    >
    > Good rehearsal, but we are not the folks you need support from.

    I was unaware you spoke for the entire list. I had thought it wasn't too far of a stretch to think that someone somewhere (outside of Apple themselves) might be subscribed to this list that might have a similar need and/or have solved it already. If I truly am the only developer writing security-related apps, then I suppose I ought to be able to stay employed a while longer... ;-)

    > If it was easy, Google would have it listed or someone here would have quickly replied.

    What Google returned in searching was a a number of similar conversations elsewhere in which a few vocal people didn't even attempt to answer the question, but instead tried to rake the question-asker over the coals merely for not "recognize[ing] the fundamental stupidity of the requirement and drop it." Finding zero answers elsewhere, I posted here.

    I appreciate the opinions of those vocal few who essentially are saying that OS X has security holes which shouldn't be closed, and anyone needing such are not only inconsiderate to their users, but should go elsewhere and use other more secure operating systems. Now I personally don't believe any of that -- I believe that OS X is a great platform for security-related apps, and that there is a solution out there for this problem. (And there appears to be -- thank you for the couple of people who shall remain anonymous who contacted me offline while I was writing this response).

    > You have a special need, that's fine and what DTS is all about. Go for it.

    Again, good advice. I'll will pursue this direction.

    Cheers,

    Brad
  • On Mar 6, 2013, at 9:02 AM, Jens Alfke wrote:

    >
    > On Mar 6, 2013, at 8:37 AM, Brad O'Hearne <brado...> wrote:
    >
    >> I am interested in the capabilities of the machine (OS X) and if so, how. I need to programmatically within an app (not by external system administration) turn off all screen capture capability, by hotkeys, or by grabbing the contents of the window.
    >
    > Apple’s DVD player app does this, for DRM purposes*. I don’t know how it manages it, whether it’s some public system API or an internal-only thing … but it might be a useful clue to track down.

    I'd start with the "Son Of Grab" sample app; it shows how to get the contents of other app's windows, so that's where I'd look to figure out how to prevent that.
  • On 07/03/2013, at 3:37 AM, Brad O'Hearne <brado...> wrote:

    > To distill it -- does OS X have the programmatic ability to turn off screen capture, and if so, how?

    I don't know if it's definitely the case, but isn't the screen capture implemented using a KEXT? If so, and if you can identify which one, you could simply remove it.

    --Graham
  • Sorry, I hate when people lecture instead of answering the question
    (especially not knowing the answer), but in this case I just couldn't help
    myself... DON"T!  this, if to be disabled, should be exposed and left for a
    user to decide... its so incredibly disapointing when the app, for what ever
    reason, decides for me what I could and should do while its running.... its
    MY device! <end rant>

    :)

    ----- Original Message -----
    From: "Graham Cox" <graham.cox...>
    To: "Brad O'Hearne" <brado...>
    Cc: "List Developer Cocoa" <cocoa-dev...>
    Sent: Wednesday, March 06, 2013 3:29 PM
    Subject: Re: Turning off screen shot ability

    >
    > On 07/03/2013, at 3:37 AM, Brad O'Hearne <brado...>
    > wrote:
    >
    >> To distill it -- does OS X have the programmatic ability to turn off
    >> screen capture, and if so, how?
    >
    >
    > I don't know if it's definitely the case, but isn't the screen capture
    > implemented using a KEXT? If so, and if you can identify which one, you
    > could simply remove it.
    >
    > --Graham
    >
  • On 07/03/2013, at 11:21 AM, danchik <danchik...> wrote:

    > Sorry, I hate when people lecture instead of answering the question (especially not knowing the answer), but in this case I just couldn't help myself... DON"T!  this, if to be disabled, should be exposed and left for a user to decide... its so incredibly disapointing when the app, for what ever reason, decides for me what I could and should do while its running.... its MY device! <end rant>

    Sorry to have offended you.

    I wasn't offering an opinion on whether it was a good idea or not - if you read the rest of the thread you'll see there has already been much discussion about that. In this case, it's not your machine, it's a different user's machine, that is presumably going to be operated in a kiosk-like mode or in some particularly locked-down scenario. So I don' think you need to worry that this will end up on your desktop.

    In any case, having browsed through much of the system library I couldn't casually identify anything that looked relevant, so I think my suggestion was pretty moot anyway.

    --Graham
  • I wasn't responding to your answer :), infact I think giving an answer to a
    question is always appropriate!

    I was referring to my self as the annoying lecturer, since my opinon was
    never solicited :) but I just couldn't resist :)  And you are correct, I
    only saw the fraction (as the original poster said "dilluted") version of
    the question, which triggered my tourrettes :)

    ----- Original Message -----
    From: "Graham Cox" <graham.cox...>
    To: "danchik" <danchik...>
    Cc: "Brad O'Hearne" <brado...>; "List Developer Cocoa"
    <cocoa-dev...>
    Sent: Wednesday, March 06, 2013 4:35 PM
    Subject: Re: Turning off screen shot ability

    On 07/03/2013, at 11:21 AM, danchik <danchik...> wrote:

    > Sorry, I hate when people lecture instead of answering the question
    > (especially not knowing the answer), but in this case I just couldn't help
    > myself... DON"T!  this, if to be disabled, should be exposed and left for
    > a user to decide... its so incredibly disapointing when the app, for what
    > ever reason, decides for me what I could and should do while its
    > running.... its MY device! <end rant>

    Sorry to have offended you.

    I wasn't offering an opinion on whether it was a good idea or not - if you
    read the rest of the thread you'll see there has already been much
    discussion about that. In this case, it's not your machine, it's a different
    user's machine, that is presumably going to be operated in a kiosk-like mode
    or in some particularly locked-down scenario. So I don' think you need to
    worry that this will end up on your desktop.

    In any case, having browsed through much of the system library I couldn't
    casually identify anything that looked relevant, so I think my suggestion
    was pretty moot anyway.

    --Graham
  • On Mar 5, 2013, at 9:57 PM, Brad O'Hearne <brado...> wrote:

    > Hello,
    >
    > I am working on a security-related Mac app and I need to know the way to turn off the ability to screen shot or capture the contents of the app's window. It would appear that setting the sharing type on the main window (which covers the entire screen) to none doesn't completely do it. It appears that Shift-Cmd-3 still performs a screen shot. I've already tried capturing keystrokes and it appears these system-level hot-key combinations aren't able to be cleanly intercepted. More than that, I would think this is overkill -- I would think there would be a simple way to turn off the ability for outside sources to grab contents of an app.
    >
    > How can I turn this off?

    Turning off the user's ability to do a screen capture in general is probably the wrong approach — and even if you managed to sink your tendrils deep enough to do this, there'd probably be plenty of ways to work around it. Instead, I'd try to figure out what Apple's DVD player does; it allows you to take screenshots all day long, but the copyrighted content gets replaced by a solid color.

    I'm not sure exactly how it pulls this off, but taking a random stab in the dark, one thing that might be worth looking into would be finding a way to *detect* when a screenshot is taking place, and swapping your content out for a solid color or some other generic thing when you notice you're getting screenshotted. No idea how possible/feasible that is, but it's an idea.

    Charles
  • On Mar 6, 2013, at 19:56:04, Charles Srstka <cocoadev...> wrote:

    > Turning off the user's ability to do a screen capture in general is probably the wrong approach — and even if you managed to sink your tendrils deep enough to do this, there'd probably be plenty of ways to work around it. Instead, I'd try to figure out what Apple's DVD player does; it allows you to take screenshots all day long, but the copyrighted content gets replaced by a solid color.

    And as a user, I would still expect my screenshot key to function if this mystery app is running in the background, so it had better not remove/trap the key just because it's running. And if you remove/trap it only when it's the foreground app, than what's preventing it from being screenshotted when it's in the background? Look for other ways around being secure - preventing screenshots whole-hog is not a good idea at all.

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • I'll take a stab at this one last time -- I appreciate the opinions here and under normal circumstances I would agree with the sentiments of user liberty and user control of their machine. However, this is a very specialized, security-oriented use-case. This app *never* runs in the background, it can't be put to the background, you cannot switch to another app while it is running, you cannot access any other system or app facilities whatsoever while this app runs. The content delivered by this app is intended to be completely secured, not able to be captured by a background app, not able to be captured with screen shots either.

    It is the user's choice whether they want to run the app or not, and at any time during the use of this app, the user may opt to exit the app. However, while the app runs, it is the only game in town. There are very legitimate use cases for this -- someone earlier replied mentioning kiosk mode. That's a pretty close analogy, but consider this to be kiosk mode plus confidential data which the user is not supposed to replicate or copy, either intentionally or accidentally. Put simply, the user is given full control over whether to run the app, or exit the app, but they do not get to call the shots or make the rules on how to use the content in the app. It is displayed while the app runs, and it is gone once the app is exited.

    Again -- I appreciate the sentiments about disabling screen shots not being a desirable approach for whatever reasons. If this were a game, or word-processing app, or music composition app, or something else, that might be a good argument. But this is something far different from those -- security is imperative. Furthermore, one more wrinkle I have not mentioned, this is a requirement of the content-owners. Someone earlier mentioned DRM, iTunes, and the requirements of media publishers to secure such data. Different data, but same principle -- it is an absolute, non-negotiable requirement that data be secured in this way. I have zero ability to change that requirement. The requirement does not originate from me, nor is it mine to change -- it is only mine to solve. But even if I was given authority to make the call, I'd agree with the pursuit of this end -- this particular use case is a legitimate use-case for disabling screen-shots.

    I'll refrain from any more attempts at explaining the scenario...I've said what I could, but if that still isn't enough, it shouldn't be too hard to imagine scenarios where this would be desirable.

    Brad

    On Mar 6, 2013, at 9:39 PM, Steve Mills <smills...> wrote:

    > On Mar 6, 2013, at 19:56:04, Charles Srstka <cocoadev...> wrote:
    >
    >> Turning off the user's ability to do a screen capture in general is probably the wrong approach — and even if you managed to sink your tendrils deep enough to do this, there'd probably be plenty of ways to work around it. Instead, I'd try to figure out what Apple's DVD player does; it allows you to take screenshots all day long, but the copyrighted content gets replaced by a solid color.
    >
    > And as a user, I would still expect my screenshot key to function if this mystery app is running in the background, so it had better not remove/trap the key just because it's running. And if you remove/trap it only when it's the foreground app, than what's preventing it from being screenshotted when it's in the background? Look for other ways around being secure - preventing screenshots whole-hog is not a good idea at all.
    >
    > --
    > Steve Mills
    > office: 952-818-3871
    > home: 952-401-6255
    > cell: 612-803-6157
  • Lee Ann,

    Thanks for the reply. I took a look at the "Son of Grab" app -- if I've understood it correctly, it appears to be related to the setSharingType property of the window in question, which I already have set to none -- which means no other process should be able to capture it. It appears that isn't the case with Command-Shift-3 however, which seems to still create screen shots unimpeded.

    Brad

    On Mar 6, 2013, at 2:14 PM, Lee Ann Rucker <lrucker...> wrote:

    >
    > On Mar 6, 2013, at 9:02 AM, Jens Alfke wrote:
    >
    >>
    >> On Mar 6, 2013, at 8:37 AM, Brad O'Hearne <brado...> wrote:
    >>
    >>> I am interested in the capabilities of the machine (OS X) and if so, how. I need to programmatically within an app (not by external system administration) turn off all screen capture capability, by hotkeys, or by grabbing the contents of the window.
    >>
    >> Apple’s DVD player app does this, for DRM purposes*. I don’t know how it manages it, whether it’s some public system API or an internal-only thing … but it might be a useful clue to track down.
    >
    > I'd start with the "Son Of Grab" sample app; it shows how to get the contents of other app's windows, so that's where I'd look to figure out how to prevent that.
  • I agree with Charles. I only work with iOS and have apps that actually take screenshots in runtime triggered by IBActions. I have no experience with detecting it, but would be suprised if detecting that a screenshot was taken would be impossible to do.
    The good thing about Charles' suggestion is it clearly shows users there is nothing wrong with their device, it is intended behaviour.
    While you are at it, you may consider adding an explanation to that solid color png. Part of that image could display text that tells the user why screenshots are discouraged.
    That would take away some of the objections raised against this feature.

    Verstuurd vanaf mijn iPhone

    Op 7 Mar 2013 om 02:56 heeft Charles Srstka <cocoadev...> het volgende geschreven:

    > On Mar 5, 2013, at 9:57 PM, Brad O'Hearne <brado...> wrote:
    >
    >> Hello,
    >>
    >> I am working on a security-related Mac app and I need to know the way to turn off the ability to screen shot or capture the contents of the app's window. It would appear that setting the sharing type on the main window (which covers the entire screen) to none doesn't completely do it. It appears that Shift-Cmd-3 still performs a screen shot. I've already tried capturing keystrokes and it appears these system-level hot-key combinations aren't able to be cleanly intercepted. More than that, I would think this is overkill -- I would think there would be a simple way to turn off the ability for outside sources to grab contents of an app.
    >>
    >> How can I turn this off?
    >
    > Turning off the user's ability to do a screen capture in general is probably the wrong approach — and even if you managed to sink your tendrils deep enough to do this, there'd probably be plenty of ways to work around it. Instead, I'd try to figure out what Apple's DVD player does; it allows you to take screenshots all day long, but the copyrighted content gets replaced by a solid color.
    >
    > I'm not sure exactly how it pulls this off, but taking a random stab in the dark, one thing that might be worth looking into would be finding a way to *detect* when a screenshot is taking place, and swapping your content out for a solid color or some other generic thing when you notice you're getting screenshotted. No idea how possible/feasible that is, but it's an idea.
    >
    > Charles
  • Sounds like impossible requirements short of running root processes and heavily modifying software, but still being severely insecure at many levels.

    Sounds like you're saying you need to run an app, and also have kb and mouse input, potentially universal access as well.
    Sounds like you're also saying you will expect this to run on a system where users may have admin accounts (normal for most ).

    You're going to need a lot of caveats to your requirements.
    You'll need an installer, because you're going to need to do things as root.
    KB shortcuts for screen capture are in System Prefs and can be enabled/disabled there and kb shortcuts are customizable.
    You can find the tool in /usr/sbin/screencapture and you would need to disable it or relocate it temporarily. This could be as simple as modifying the user shell path or moving the tool temporarily.
    (requiring admin authorization either when you app launches or when you run an installer to install privileged tools.)

    That will take care of screenshots, but it has nothing to do with Cocoa specifically.
    Your app will most certainly not make in into MAS.

    You will still need to account for admin users modifying things.
    They can enable root easily.
    HW access means running in single user mode easily.
    You will need to detect and handle external displays. Those are easily recorded.
    If it is a Mac without a built-in display, it is all to easy to capture a video signal from the port.

    Never mind mounting the disk from another system that may ignore file permissions easily.

    Still doesn't account for unknown software and processes on a system that may be running already with escalated privileges before yours launches.
    Apple Remote Deskop or other remote management & screensharing tools?
    You probably don't want to go into trying to white list processes.
    Still does not account for cameras taking pictures which can then be OCR'd easily too.

    Your app will likely be easily cracked or otherwise circumvented as long as users can have hardware access & admin access.
    That leaves a severe amount of complex obfuscation and custom view drawing.

    You need a root kit, but your worst enemy will be another root kit.

    On Mar 7, 2013, at 2:33 PM, Brad O'Hearne <brado...> wrote:

    > Lee Ann,
    >
    > Thanks for the reply. I took a look at the "Son of Grab" app -- if I've understood it correctly, it appears to be related to the setSharingType property of the window in question, which I already have set to none -- which means no other process should be able to capture it. It appears that isn't the case with Command-Shift-3 however, which seems to still create screen shots unimpeded.
    >
    > Brad
    >
    > On Mar 6, 2013, at 2:14 PM, Lee Ann Rucker <lrucker...> wrote:
    >
    >>
    >> On Mar 6, 2013, at 9:02 AM, Jens Alfke wrote:
    >>
    >>>
    >>> On Mar 6, 2013, at 8:37 AM, Brad O'Hearne <brado...> wrote:
    >>>
    >>>> I am interested in the capabilities of the machine (OS X) and if so, how. I need to programmatically within an app (not by external system administration) turn off all screen capture capability, by hotkeys, or by grabbing the contents of the window.
    >>>
    >>> Apple’s DVD player app does this, for DRM purposes*. I don’t know how it manages it, whether it’s some public system API or an internal-only thing … but it might be a useful clue to track down.
    >>
    >> I'd start with the "Son Of Grab" sample app; it shows how to get the contents of other app's windows, so that's where I'd look to figure out how to prevent that.
    >
  • On Mar 6, 2013, at 10:21 PM, Brad O'Hearne wrote:

    > ...but they do not get to call the shots or make the rules on how to use the content in the app...

    And there is the crux of my argument about fundamental stupidity. Once the data is in the user's head, there is no technical means to control what the user does with it.

    > Someone earlier mentioned DRM, iTunes, and the requirements of media publishers to secure such data. Different data, but same principle...

    Yes, and DRM is the classic and perfect example of the futility of trying to simultaneously allow and disallow a user to access data. DRM is largely, and quite famously, a miserable failure and vast waste of effort. (How many hacks exist to capture DVD playback on OS X? Answer, in case you don' know: a lot, and they're apparently damn near trivial to write.)

    > ...it is an absolute, non-negotiable requirement that data be secured in this way. I have zero ability to change that requirement. The requirement does not originate from me, nor is it mine to change -- it is only mine to solve.

    Well, that sucks... Are you 100% certain you have no ability to affect the requirement? And what if the answer is "no, their is no way to do that on OS X"? Or, more likely, what if the answer is "not through a supported API, only by hacking the windowing system"? Is this misfeature really worth the all the potential problems with conflicts and updates that come with injecting code to modify kernel operations?

    > But even if I was given authority to make the call, I'd agree with the pursuit of this end -- this particular use case is a legitimate use-case for disabling screen-shots.

    Then you need to think about it more, rather than defending the indefensibly stupid requirement handed down from marketing.

    > I'll refrain from any more attempts at explaining the scenario...I've said what I could, but if that still isn't enough, it shouldn't be too hard to imagine scenarios where this would be desirable.

    Unless you take time to think about it more deeply, in which case it becomes obvious that the requirement is self-contradictory, and although someone might indeed desire it, there is absolutely not, indeed cannot be, a scenario where it is truly important.

    NB: thanks to friends/colleagues who work with truly confidential data, I have a rough idea how the DOD & NSA deal with top secret data. I'm pretty sure they would snicker at this "absolute, non-negotiable requirement" ;-)

    --
    Scott Ribe
    <scott_ribe...>
    http://www.elevated-dev.com/
    (303) 722-0567 voice
  • I’m replying to a few different people’s messages here, to avoid cluttering up the thread too much.

    On Mar 6, 2013, at 12:49 PM, M Pulis <toothpic...> wrote:

    > Good rehearsal, but we are not the folks you need support from.
    > If it was easy, Google would have it listed or someone here would have quickly replied.

    That is a really unhelpful response. You don’t speak for the list, and people have certainly asked other tricky questions on these lists that have taken some work to answer. Just because you don’t _like_ the question is no reason to shoot it down. However, I do agree that answering this may require internal knowledge that DTS can get.

    On Mar 6, 2013, at 5:56 PM, Charles Srstka <cocoadev...> wrote:

    > Instead, I'd try to figure out what Apple's DVD player does; it allows you to take screenshots all day long, but the copyrighted content gets replaced by a solid color.

    If that’s true (I’ve never tried it) then my suspicion is that this is a side effect of the way the DVD decoding is done — the codec is hardware-based and may be passing the decoded pixels through a separate pipeline where they get composited into the video output late in the game, i.e. the DRM’d pixels never appear in the GPU’s main frame buffer. If so (and I’m really just making an educated guess) then that technique wouldn’t be applicable to other apps.

    Back in the old days (like, 10.0 and 10.1) it was problematic to screenshot OpenGL content because the pixels got composited differently than regular Quartz graphics, but that got resolved long ago.

    On Mar 6, 2013, at 10:51 PM, John Joyce <dangerwillrobinsondanger...> wrote:

    > You will need to detect and handle external displays. Those are easily recorded.
    > If it is a Mac without a built-in display, it is all to easy to capture a video signal from the port.

    Well, HDMI has DRM capabilities in it — the video source can determine whether the video receiver is an approved device (i.e. one that won't record or capture the pixels) and refuse to send anything otherwise. Once again, this was a requirement made by the movie studios. I don’t know whether the other current video interfaces work the same way (DVI didn’t, but current Macs don’t have connectors for it any more.)

    —Jens
  • Brad,

    I dug into DVD Players symbols and it would appear to be using private API of the Core Graphics Services variety.
    http://cocoadev.com/wiki/CoreGraphicsPrivate

    Specifically CGSSetWindowCaptureExcludeShape()

    Hope this helps.
    -Richard

    On 06/03/2013, at 11:06:59 PM, Scott Ribe <scott_ribe...> wrote:

    > On Mar 6, 2013, at 10:21 PM, Brad O'Hearne wrote:
    >
    >> ...but they do not get to call the shots or make the rules on how to use the content in the app...
    >
    > And there is the crux of my argument about fundamental stupidity. Once the data is in the user's head, there is no technical means to control what the user does with it.
    >
    >> Someone earlier mentioned DRM, iTunes, and the requirements of media publishers to secure such data. Different data, but same principle...
    >
    > Yes, and DRM is the classic and perfect example of the futility of trying to simultaneously allow and disallow a user to access data. DRM is largely, and quite famously, a miserable failure and vast waste of effort. (How many hacks exist to capture DVD playback on OS X? Answer, in case you don' know: a lot, and they're apparently damn near trivial to write.)
    >
    >> ...it is an absolute, non-negotiable requirement that data be secured in this way. I have zero ability to change that requirement. The requirement does not originate from me, nor is it mine to change -- it is only mine to solve.
    >
    > Well, that sucks... Are you 100% certain you have no ability to affect the requirement? And what if the answer is "no, their is no way to do that on OS X"? Or, more likely, what if the answer is "not through a supported API, only by hacking the windowing system"? Is this misfeature really worth the all the potential problems with conflicts and updates that come with injecting code to modify kernel operations?
    >
    >> But even if I was given authority to make the call, I'd agree with the pursuit of this end -- this particular use case is a legitimate use-case for disabling screen-shots.
    >
    > Then you need to think about it more, rather than defending the indefensibly stupid requirement handed down from marketing.
    >
    >> I'll refrain from any more attempts at explaining the scenario...I've said what I could, but if that still isn't enough, it shouldn't be too hard to imagine scenarios where this would be desirable.
    >
    > Unless you take time to think about it more deeply, in which case it becomes obvious that the requirement is self-contradictory, and although someone might indeed desire it, there is absolutely not, indeed cannot be, a scenario where it is truly important.
    >
    > NB: thanks to friends/colleagues who work with truly confidential data, I have a rough idea how the DOD & NSA deal with top secret data. I'm pretty sure they would snicker at this "absolute, non-negotiable requirement" ;-)
    >
    > --
    > Scott Ribe
    > <scott_ribe...>
    > http://www.elevated-dev.com/
    > (303) 722-0567 voice
  • On 07/03/2013, at 4:21 PM, Brad O'Hearne <brado...> wrote:

    > But this is something far different from those -- security is imperative.

    Perhaps your app is not suited to having a graphical output or interface at all in that case? While I'm not a fan of "security through obscurity", you could arrange your programs output to be routed to a paper tape puncher maybe, or a hall of monkeys with typewriters being prodded with sharp sticks.

    Facetiousness aside, I'm trying to make a serious point - once your app writes its output to the screen, it's out there. The photons have left the monitor, carrying the output data of the app with them to whatever detector they are destined for, be it eyeballs or a camera. You can't get them back, all you can do is prevent them being emitted in the first place. All a screen shot is is a time-delayed version of the same. So the problem appears to be time, doesn't it? So how about you only show the output to the user for, say, 0.2 seconds? That will be very hard to capture. Hard to see too, but security always comes at the cost of usability. Just make sure you train users to pay attention FULLY to the screen.

    Another option, given that the screen shot feature writes files with particular file names to the desktop, you could monitor the desktop folder, detect the files and delete them.

    Or, perhaps you could collate all of these replies to your thread and present them to the arse who wrote the spec.

    --Graham
  • On Mar 7, 2013, at 12:23 AM, Jens Alfke wrote:

    > On Mar 6, 2013, at 5:56 PM, Charles Srstka <cocoadev...> wrote:
    >
    >> Instead, I'd try to figure out what Apple's DVD player does; it allows you to take screenshots all day long, but the copyrighted content gets replaced by a solid color.
    >
    >
    > If that’s true (I’ve never tried it) then my suspicion is that this is a side effect of the way the DVD decoding is done — the codec is hardware-based and may be passing the decoded pixels through a separate pipeline where they get composited into the video output late in the game, i.e. the DRM’d pixels never appear in the GPU’s main frame buffer. If so (and I’m really just making an educated guess) then that technique wouldn’t be applicable to other apps.

    Nope, FYI, it is not a side effect--it is deliberate and it is required by the licensing terms for DVD playback. It is also apparently easy to circumvent.

    --
    Scott Ribe
    <scott_ribe...>
    http://www.elevated-dev.com/
    (303) 722-0567 voice
  • On Wed, Mar 6, 2013 at 9:43 PM, Brad O'Hearne <brado...> wrote:
    > 2. NSWindow allows you to specify the level of access other processes have to the window's content. Aside from the fact that is seems a bit bizarre that there's the ability to grant no access (NSWindowSharingNone, which doc states should prevent the window's contents to be read by another process), and a screen shot still works, the mere presence of this configurable parameter acknowledges the potential need of an app to secure its displayed content. Therefore, it doesn't seem such a stretch to imagine that if a window's contents were secured, that screen shots would follow right along as something desired to be turned off.

    Does this restriction work for the screencapture command line tool?
  • Seeing as this uses non public APIs, i would STRONGLY recommend not using it in any shipping applications.
    However, for interests sake alone this is how DVD Player appears to do it.

    https://github.com/heardrwt/RHAdditions/blob/master/RHAdditions/NSWindow%2B
    RHPreventCaptureAdditions.m


    -Richard

    On 06/03/2013, at 11:41:16 PM, Scott Ribe <scott_ribe...> wrote:

    >
    > On Mar 7, 2013, at 12:23 AM, Jens Alfke wrote:
    >
    >> On Mar 6, 2013, at 5:56 PM, Charles Srstka <cocoadev...> wrote:
    >>
    >>> Instead, I'd try to figure out what Apple's DVD player does; it allows you to take screenshots all day long, but the copyrighted content gets replaced by a solid color.
    >>
    >>
    >> If that’s true (I’ve never tried it) then my suspicion is that this is a side effect of the way the DVD decoding is done — the codec is hardware-based and may be passing the decoded pixels through a separate pipeline where they get composited into the video output late in the game, i.e. the DRM’d pixels never appear in the GPU’s main frame buffer. If so (and I’m really just making an educated guess) then that technique wouldn’t be applicable to other apps.
    >
    > Nope, FYI, it is not a side effect--it is deliberate and it is required by the licensing terms for DVD playback. It is also apparently easy to circumvent.
    >
    > --
    > Scott Ribe
    > <scott_ribe...>
    > http://www.elevated-dev.com/
    > (303) 722-0567 voice
  • On 3/7/13 10:47 AM, Richard Heard wrote:
    > Seeing as this uses non public APIs, i would STRONGLY recommend not using it in any shipping applications.
    > However, for interests sake alone this is how DVD Player appears to do it.
    >
    > https://github.com/heardrwt/RHAdditions/blob/master/RHAdditions/NSWindow%2B
    RHPreventCaptureAdditions.m


    I can't imagine myself using it but it really is cool! Thanks for sharing!

    Regards
    Markus
    --
    __________________________________________
    Markus Spoettl
  • Pretty sure private API is not allowed on the list.,,
    On 2013/03/07, at 19:18, Markus Spoettl <ms_lists...> wrote:

    > On 3/7/13 10:47 AM, Richard Heard wrote:
    >> Seeing as this uses non public APIs, i would STRONGLY recommend not using it in any shipping applications.
    >> However, for interests sake alone this is how DVD Player appears to do it.
    >>
    >> https://github.com/heardrwt/RHAdditions/blob/master/RHAdditions/NSWindow%2B
    RHPreventCaptureAdditions.m

    >
    > I can't imagine myself using it but it really is cool! Thanks for sharing!
    >
    > Regards
    > Markus
    > --
    > __________________________________________
    > Markus Spoettl
    > _______________________________________________
    >
    >
    >
  • Thank you everyone for your responses and discussion. I'll take a look at all of the resources listed by responders, and pursue it further with DTS. In conclusion, I'll add what my opinion is of the knobs and switches on the machine here.

    Here's what I find interesting -- if I set the NSWindow sharingType to NSWindowSharingNone, then screen capture with another capture app (like ScreenFlow -- the only one I've directly tested) does not work. It still indeed does capture, but it captures my desktop as if my app was not running or visible. Everything else on my desktop is captured, but my app is nowhere to be found. In addition, if I attempt a Command-Shift-4-SpaceBar (to capture the window), then this does not work -- in fact, OS X presents a dialog saying that this operation cannot be done (see the link below -- note this is nothing that my app presents).

    https://www.dropbox.com/s/0i02n3bkuhg0160/Screen%20Shot%202013-03-07%20at%2
    08.11.16%20AM.png


    However, if I Command-Shift-4 and then mouse-drag, I can capture whatever is in the bounding box (including the entire contents of the window which was prevented in the other case), or if I Command-Shift-3 I can capture the entire screen (including the window in question).

    Based on the inconsistency of the Command-Shift-... screen shot behavior, my conclusion is that this is a bug. Completely forgetting any philosophical or design opinions, this behavior doesn't make logical sense to me. To prevent someone from taking a screen shot of the specific window, to the point of the system intervene further with a dialog presented to the user, while allowing the entire contents of that same window to be captured by taking a screen shot of the full screen or a custom bounding box by mouse-drag -- I can't reconcile the logic behind that.

    So my conclusion is that this is a bug, probably with the enforcement of the NSWindow sharingType. Thanks again or the responses and discussion, both on this list, and offline.

    Brad

    On Mar 7, 2013, at 3:18 AM, Markus Spoettl <ms_lists...> wrote:

    > On 3/7/13 10:47 AM, Richard Heard wrote:
    >> Seeing as this uses non public APIs, i would STRONGLY recommend not using it in any shipping applications.
    >> However, for interests sake alone this is how DVD Player appears to do it.
    >>
    >> https://github.com/heardrwt/RHAdditions/blob/master/RHAdditions/NSWindow%2B
    RHPreventCaptureAdditions.m

    >
    > I can't imagine myself using it but it really is cool! Thanks for sharing!
    >
    > Regards
    > Markus
    > --
    > __________________________________________
    > Markus Spoettl
  • LOL, that's too funny!

    I think average eye can make a conscionable impression in 0.15sec.... some
    one should spec that out in an RFC... hehehe, a graph perhaps of security to
    usability in terms of the rate of impression :)

    ----- Original Message -----
    From: "Graham Cox" <graham.cox...>
    To: "Brad O'Hearne" <brado...>
    Cc: "Cocoa dev" <cocoa-dev...>
    Sent: Wednesday, March 06, 2013 11:29 PM
    Subject: Re: Turning off screen shot ability

    >
    > On 07/03/2013, at 4:21 PM, Brad O'Hearne <brado...>
    > wrote:
    >
    >> But this is something far different from those -- security is imperative.
    >
    >
    > Perhaps your app is not suited to having a graphical output or interface
    > at all in that case? While I'm not a fan of "security through obscurity",
    > you could arrange your programs output to be routed to a paper tape
    > puncher maybe, or a hall of monkeys with typewriters being prodded with
    > sharp sticks.
    >
    > Facetiousness aside, I'm trying to make a serious point - once your app
    > writes its output to the screen, it's out there. The photons have left the
    > monitor, carrying the output data of the app with them to whatever
    > detector they are destined for, be it eyeballs or a camera. You can't get
    > them back, all you can do is prevent them being emitted in the first
    > place. All a screen shot is is a time-delayed version of the same. So the
    > problem appears to be time, doesn't it? So how about you only show the
    > output to the user for, say, 0.2 seconds? That will be very hard to
    > capture. Hard to see too, but security always comes at the cost of
    > usability. Just make sure you train users to pay attention FULLY to the
    > screen.
    >
    > Another option, given that the screen shot feature writes files with
    > particular file names to the desktop, you could monitor the desktop
    > folder, detect the files and delete them.
    >
    > Or, perhaps you could collate all of these replies to your thread and
    > present them to the arse who wrote the spec.
    >
    > --Graham
    >
previous month march 2013 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Go to today