Re: Turning off screen shot ability
On Mar 7, 2013, at 12:23 AM, Jens Alfke wrote: > On Mar 6, 2013, at 5:56 PM, Charles Srstka 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_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: Turning off screen shot ability
On 07/03/2013, at 4:21 PM, Brad O'Hearne 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 ___ 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: how to implement iphoto like animation while doing drag and drop on custom listview
On Mar 6, 2013, at 10:46 PM, Muthulingam Ammaiappan wrote: > (when user drag the item if the mouse co-ords enters the in between region > then the corresponding elements will animate... and animation will end and > it comeback its original position once the mouse left the coords) > > please help me how i can implement the above mentioned animation while > doing drag and drop...any pointers are highly appreciated That’s a pretty broad question. What specifically do you want to know? In general the answer is going to be “use Core Animation”. If you have questions about particular things with CA, ask them; but if you want someone to design the whole algorithm for you, well, I’m sure you can hire a consultant to do it. There’s a limit to what you can expect to get for free. —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: Turning off screen shot ability
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 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_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/heardrwt%40gmail.com > > This email sent to heard...@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: Turning off screen shot ability
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 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 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 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 ___ 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: Turning off screen shot ability
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_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: Turning off screen shot ability
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 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 wrote: > >> >> On Mar 6, 2013, at 9:02 AM, Jens Alfke wrote: >> >>> >>> On Mar 6, 2013, at 8:37 AM, Brad O'Hearne 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. > ___ 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
how to implement iphoto like animation while doing drag and drop on custom listview
Hi Friends, i had developed the custom list view which is having NSView as a cell with variable sizes to represent the video clips in the timeline. and i had implemented the drag and drop for reordering functionality... that is working as per the expectation... but i wanted to add the animation while doing the drag and drop like in "iPhoto"... (when user drag the item if the mouse co-ords enters the in between region then the corresponding elements will animate... and animation will end and it comeback its original position once the mouse left the coords) please help me how i can implement the above mentioned animation while doing drag and drop...any pointers are highly appreciated in stackoverflow link: http://stackoverflow.com/questions/15264751/how-to-implement-iphoto-like-animation-while-doing-drag-and-drop-on-custom-listv Thanks & Regards, Muthu ___ 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: Turning off screen shot ability
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 het volgende geschreven: > On Mar 5, 2013, at 9:57 PM, Brad O'Hearne 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 > > > ___ > > 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/diederik%40tenhorses.com > > This email sent to diede...@tenhorses.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: Turning off screen shot ability
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 wrote: > > On Mar 6, 2013, at 9:02 AM, Jens Alfke wrote: > >> >> On Mar 6, 2013, at 8:37 AM, Brad O'Hearne 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. ___ 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: Turning off screen shot ability
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 wrote: > On Mar 6, 2013, at 19:56:04, Charles Srstka 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 > > ___ > > 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: Turning off screen shot ability
On Mar 6, 2013, at 19:56:04, Charles Srstka 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 ___ 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: Turning off screen shot ability
On Mar 5, 2013, at 9:57 PM, Brad O'Hearne 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 ___ 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: Turning off screen shot ability
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" To: "danchik" Cc: "Brad O'Hearne" ; "List Developer Cocoa" Sent: Wednesday, March 06, 2013 4:35 PM Subject: Re: Turning off screen shot ability On 07/03/2013, at 11:21 AM, 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! 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 ___ 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: Turning off screen shot ability
On 07/03/2013, at 11:21 AM, 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! 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 ___ 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: Turning off screen shot ability
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! :) - Original Message - From: "Graham Cox" To: "Brad O'Hearne" Cc: "List Developer Cocoa" 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 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 ___ 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/danchik%40rebelbase.com This email sent to danc...@rebelbase.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: Turning off screen shot ability
On 07/03/2013, at 3:37 AM, Brad O'Hearne 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 ___ 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: NSDrawer not always sending -drawerDidOpen: to delegate
For archive searchers, this non-reproducible problem that we worked on 3 weeks ago wasn't fixed. It happened to me again yesterday. Also, another, probably related problem occurred, which is that a bunch of checkboxes in the drawer, created and bound programatically, seemed to lose their bindings (via an object controller) to the data model. Invoking my "kickDrawer:" method still brings the delegation back to life. So, in addition to nilling and then resetting the delegate in this method, I also now recreate the checkboxes. And I invoke this -kickDrawer: whenever the app is reactivated, in addition to -awakeFromNib and 1.0 second after -awakeFromNib. ___ 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: Turning off screen shot ability
On Mar 6, 2013, at 9:02 AM, Jens Alfke wrote: > > On Mar 6, 2013, at 8:37 AM, Brad O'Hearne 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. ___ 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: Turning off screen shot ability
On Mar 6, 2013, at 1:49 PM, M Pulis 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 ___ 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: Turning off screen shot ability
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 willa 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 (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: Turning off screen shot ability
> 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 willa 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 (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: Turning off screen shot ability
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, dangerwillrobinsondan...@gmail.com 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 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, ___ 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/toothpic%40fastq.com This email sent to tooth...@fastq.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: Core Data migration: how to delete some managed objects?
On Tue, 5 Mar 2013 18:56:32 -0800, Jerry Krinock said: >> I take it you are using your technique successfully in practice? > >Maybe not. I'd pasted in some of my code but modified it for your >case. Although I have done a lot of stuff in that method, I'm not sure >if I have ever used that specific technique of *not* invoking super, to >"delete" an object. OK, well, it seems to be working well at least! >If you invoked associateSourceInstanc >e:withDestinationInstance:forEntityMapping: per the documentation, you'd >pass nil for destinationInstance. And then it will either (1) >degenerate internally to a no-op, (2) raise an exception, or (3) crash. >You can figure it out from there :) As I said in my previous post, it goes boom. :( I'll just not invoke super, it seems the right stuff is happening... Thanks! -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: Turning off screen shot ability
On Mar 6, 2013, at 8:37 AM, Brad O'Hearne 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. ___ 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: Turning off screen shot ability
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 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. > ___ > > 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. Cont
Re: IOKit device help
On Mar 6, 2013, at 9:00 AM, Ben Gollmer wrote:
> On Mar 3, 2013, at 8:58 PM, Jason T. Slack-Moehrle
> wrote:
>
>> I am using: IOServiceGetMatchingServices
>>
>> kr = IOServiceGetMatchingServices(kIOMasterPortDefault,
>>
>> IOServiceNameMatching("AppleUSBEHCI"), &io_objects);
>>
>> I am looking for how I find out information about the internal HD as the
>> above will prob USB device.
>>
>> I cannot seem to find a list or anything that would tell me this.
>>
>> Essentially I am looking for a way to get a unique ID from the system. On
>> Windows the other developer uses the hard disk id.
>
> On OS X, it is typical to use the system serial number, MAC address of the
> primary network interface, or the hardware UUID to uniquely identify a
> system. Of course, each of those can change for different reasons.
>
> Technote 1103 includes sample code & some discussion of the various caveats:
>
> http://developer.apple.com/library/mac/#technotes/tn1103/_index.html
And if you decide you still want to get a disk ID, the proper API would
probably be DiskArbitration.
https://developer.apple.com/library/mac/#documentation/Darwin/Reference/DiscArbitrationFramework/_index.html
Cheers,
Ken
___
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: IOKit device help
On Mar 3, 2013, at 8:58 PM, Jason T. Slack-Moehrle
wrote:
> I am using: IOServiceGetMatchingServices
>
> kr = IOServiceGetMatchingServices(kIOMasterPortDefault,
>
> IOServiceNameMatching("AppleUSBEHCI"), &io_objects);
>
> I am looking for how I find out information about the internal HD as the
> above will prob USB device.
>
> I cannot seem to find a list or anything that would tell me this.
>
> Essentially I am looking for a way to get a unique ID from the system. On
> Windows the other developer uses the hard disk id.
On OS X, it is typical to use the system serial number, MAC address of the
primary network interface, or the hardware UUID to uniquely identify a system.
Of course, each of those can change for different reasons.
Technote 1103 includes sample code & some discussion of the various caveats:
http://developer.apple.com/library/mac/#technotes/tn1103/_index.html
--
Ben
___
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: Turning off screen shot ability
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 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, > > > ___ 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
