How can I prevent the user from using Snip and Sketch to take screen shots?
A customer wanted to know how they could disable the Snip and Sketch feature of Windows 10. They tried deploying policy to block the execution of C:\Program
Files\WindowsApps\Microsoft.ScreenSketch_10.1907.2471.0_x64__8wekyb3d8bbwe\ScreenSketch.exe, but that didn’t help.
Okay, first of all, ScreenSketch.exe is not Snip and Sketch. Screen Sketch is a feature of the Windows Ink Workspace that lets you draw directly on the screen. It’s not the Snip and Sketch tool. Snip and Sketch (as of this writing) is part of the ShellExperienceHost.exe process, and if you block that process, you lose all sorts of things like the taskbar Calendar, the wireless network chooser, and a number of other shell features.
(Note that the above information is not contractual. The implementation details of various shell features may, and indeed have, changed over time.)
We asked why the customer felt the need to disable the Snip and Sketch feature.
The customer liaison explained that they had a program that displayed proprietary information and didn’t want their employees making screen copies of the data.
Disabling the Snip and Sketch feature is not going to solve your problems. There’s also the Snipping Tool, the PrtSc key, and all number of third party screen capture utilities. And even if you manage to get them all, the employee could just take out a digital camera and snap a photo.
That said, the customer could modify their proprietary program to call the SetÂWindowÂDisplayÂAffinity function to indicate that the window contents should not be included in screen captures, as I noted some time ago. The desktop compositor will prevent those pixels from being included in BitÂBlt and other screen capture functions.
UWP applications can set the ApplicationÂView.IsÂScreenÂCaptureÂEnabled property to false to exclude a view from screen capture functions.
Light
Dark
14 comments
That was an informative post, but are you sure about ScreenSketch.exe?
I just used PowerShell and C# to inquire Microsoft.ScreenSketch. Its friendly name is @{Microsoft.ScreenSketch_10.1907.2471.0_x64__8wekyb3d8bbwe?ms-resource://Microsoft.ScreenSketch/Resources/AppStoreName}, which resolves to Snip & Sketch. Its manifest explicitly defines ScreenSketch.exe as the “Exectuable”.
Also, the “Product Name” field of ScreenSketch.exe reads “Microsoft Snip & Sketch”.
Last but not least, I used Process Explorer to inspect the Snip & Sketch window. Its owning process was ScreenSketch.exe, launched by SvcHost.exe.
Likely was at one point? In v1909, asking Ink Workspace to take a full screen screenshot indeed sends it to Snip and Sketch. Ink Workspace used to be a lot more integrated, but was likely changed into just calling its respective apps to avoid feature duplication. At the time of this story, it was likely the old Ink Workspace that was in place.
I can confirm this, I used Process Manager to grab the owner of the Snip and Sketch window and it was ScreenSketch.exe.
Raymond writes these posts way in advance IIRC, likely a previous version of Windows 10 had the windows owned by ShellExperienceHost but now they seem to be owned by individual processes.
The earliest version of Snip & Sketch that I could find was 10.1809.181023004 from Windows 10 v1809. (You know… the Fall Destroyers Update.) Its package number is 2018.1023.2326.0. Before that, there was no Snip & Sketch. Instead, you had to use Screen Sketch, a feature of Windows Ink Workspace.
The executable file for Screen Sketch was ScreenSketch.exe. Microsoft didn’t change the executable file name even after the app spun off into Snip & Sketch.
AFAIK, Snip & Sketch has never been, in part or whole, within the ShellExperienceHost.exe.
>Its friendly name is @{Microsoft.ScreenSketch_10.1907.2471.0_x64__8wekyb3d8bbwe?ms-resource://Microsoft.ScreenSketch/Resources/AppStoreName}
If that’s it’s friendly name I’d hate to see what it’s bad-hair-day name is…
Haha! Yes. Microsoft’s definitions are often quirky like this.
If this trips you, I suggest you don’t look at Microsoft’s definition of “boot partition” and “system partition”. Or at least, try not to think about which one contains the boot loader.
this comment has been deleted.
This sounds like another walls and ladders issue, but if this is just to prevent accidental disclosure of information it should be fine. Otherwise, if you can’t trust your employees not to divulge confidential data I think that you’ve already lost and should think about why you’re having the problem in the first place.
tsk, tsk, it’s not like you (Microsoft) never tried to do the same thing: https://support.microsoft.com/en-us/help/2006298/print-screen-functionality-fails-with-no-error-message
🙂
I recall there also being a support article explaining how no software nor hardware will prevent the user from taking a photo with their phone or just writing it down on a piece of paper, but I can’t find it now. It was helpful with a few customers.
Where’s that old article about throwing stones in glass houses? Raymond is not Microsoft, and Outlook is not his product. He knows that when he writes about things that are done incorrectly, there’s likely a Microsoft product that also does the thing incorrectly.
Btw, I would have thought about “how to enable a window with HDCP protection”
Some of the introductory information isn’t entirely accurate, but it indeed matches with users’ perception of the experience and the proposed problem solution would work in some scenarios (where you control the code of apps that present the data you don’t want captured).
ScreenSketch.exe is indeed the process and main executable of the Snip & Sketch (proper) app. To most users Snip & Sketch is both this app and the actual “modern snipping experience” as I like to call it, but as you suggest – ShellExperienceHost.exe hosts the actual snipping UI that runs separately from the ScreenSketch.exe process and its main logic lives in ScreenClipping.dll.
If you’re an admin and want to prevent using specifically modern snipping (which again – many users see as the main part of Snip & Sketch) from capturing any app – you can use AppLocker to block ScreenClipping.dll.
Now, you may still want to try to block PrtScn, the classic Snipping Tool, snipping from OneNote, PowerPoint, Word, Excel, screen capture from Teams, Skype, the browser etc. (if even possible) and installing other apps that could capture your screen and see the complete block isn’t possible, but you can still do some work to make it more difficult to take and potentially share screenshots. Raymond’s solution is the only one that should address all of these and will only fail a physical camera or smartphone test.
One additional problem is – I think Raymond’s solution might also prevent seeing the blocked windows from remoting over Remote Desktop and similar solutions which might be good or bad depending on your security environment.
Setting window affinity doesn’t exclude it from remote desktop, and I don’t think it prevents the window from being taken screenshots of in a remote desktop session. At least that was the case for some early version of Windows 10. I remember accidentally discovering that I could screenshot DRM-protected content in Videos (now known as Movies & TV) in a remote session.
There’s probably still a way to capture. Possibly video capture/streaming software that works at a low enough level would still be able to capture it.
I hope you let the customer know that about the amazing modern convenience called the pen (or pencil) that a malicious actor could use to WRITE DOWN information displayed on the screen. What they’re trying to do is ultimately futile. There’s always going to be an “analog hole” at the very least.
https://en.wikipedia.org/wiki/Analog_hole
Edit: Also this reminds me of airport body scanners. There was some controversy about images they captured being potentially pornographic with how they could see through clothes to some degree. There were assurances made the computers that displayed the images to TSA agents could not be used to permanently save images. Guess what happened?