Re: Turning off screen shot ability
Re: Turning off screen shot ability
- Subject: Re: Turning off screen shot ability
- From: M Pulis <email@hidden>
- Date: Wed, 06 Mar 2013 13:49:13 -0700
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden