Skip to content

[API Suggestion][Security] Add ExcludeFromScreenCapture API to Forms/Controls #13258

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
KlausLoeffelmann opened this issue Apr 7, 2025 · 10 comments · May be fixed by #13467
Open

[API Suggestion][Security] Add ExcludeFromScreenCapture API to Forms/Controls #13258

KlausLoeffelmann opened this issue Apr 7, 2025 · 10 comments · May be fixed by #13467
Assignees
Labels
api-approved (4) API was approved in API review, it can be implemented blocking Used by the API Review Board 📚 documentation Open issue here - https://github.com/dotnet/dotnet-api-docs/issues security Issues of runtime code vulnerabilities or unintentional exposing customer data side effect
Milestone

Comments

@KlausLoeffelmann
Copy link
Member

KlausLoeffelmann commented Apr 7, 2025

TL;DR

With the rise of continuous screen capture tools for AI analysis, sensitive LOB applications are at increased risk of data leakage. This proposal adds a simple API to WinForms that allows developers to prevent their forms and controls from being captured in screenshots, addressing a critical security concern for applications that handle sensitive data.

Rationale

Modern productivity tools increasingly use continuous screen capturing to feed content to LLMs for summarization, analysis, and automation. While this offers productivity benefits, it creates significant security risks for certain Line of Business (LOB) applications that handle sensitive data, or at least certain areas of those apps.

Here are a few thoughts, which types of applications might require protection against unauthorized screen captures:

  1. Healthcare Applications: Applications displaying patient records, medical histories, test results, or other protected health information (PHI) covered under HIPAA regulations

  2. Financial Applications: Banking software, investment platforms, or accounting systems showing account balances, transaction histories, credit card numbers, or tax information

  3. Government Systems: Applications handling citizen data, social security numbers, tax records, or classified information

  4. Legal Software: Case management systems containing privileged attorney-client communications, court filings, or sensitive legal strategies

  5. Insurance Platforms: Systems displaying policy details, claims information, or personal policyholder data

  6. HR Software: Applications showing employee records, salary information, performance reviews, or personal details

  7. Educational Systems: Applications containing student records, grades, or other information protected under FERPA

Proposed API

Windows 10/11 provides the SetWindowDisplayAffinity API with the options WDA_NONE, WDA_Monitor and WDA_EXCLUDEFROMCAPTURE that can block most software-based screen capture methods. This proposal wraps this functionality in a simple, easy-to-use WinForms API that raises awareness about this security concern and gives developers a straightforward way to protect sensitive information.

New Property for Form Class

namespace System.Windows.Forms;

public class Form
{
   /// <summary>
   /// Gets or sets a value indicating whether this form should be excluded from screen captures.
   /// When set to true, the form will appear blacked out in screenshots and screen recordings.
   /// This only works on Windows 10 version 1803 and higher.
   /// </summary>
   public ScreenCaptureMode ScreenCaptureMode { get; set; }
}

Alternatively: New Property for Control Class

I mention this, that we had this considered, but meanwhile with reservations. If we decided, to do it on control level, that would automatically include every control up the inheritance hierarchy.
But. This is subject to more testing, and there is a risk to make it work reliably and would then lull the developer into a false sense of security.

namespace System.Windows.Forms;

public class Control
{
   /// <summary>
   /// Gets or sets a value indicating whether this form should be excluded from screen captures.
   /// When set to true, the form will appear blacked out in screenshots and screen recordings.
   /// This only works on Windows 10 version 1803 and higher.
   /// </summary>
   public ScreenCaptureMode ScreenCaptureMode { get; set; }
}

Additional Supporting APIs

namespace System.Windows.Forms;

/// <summary>
/// Enumeration defining the behavior when a form or control is captured in a screenshot.
/// </summary>
public enum ScreenCaptureMode
{
    /// <summary>
    ///  The form or control can be captured normally in screenshots. Default.
    /// </summary>
    Allow = 0,
    
    /// <summary>
    ///  The form or control appears blacked out in screenshots.
    /// </summary>
    HideContent = 1,
    
    /// <summary>
    ///  The form or control appears blurred in screenshots.
    /// Requires Windows 10 version 2004 or higher.
    /// </summary>
    HideWindow = 2
}

New Form Configuration in Visual Studio Designer

Add a "Security" category in the Properties panel of the WinForms designer with the ExcludeFromScreenCapture property for easy discovery and configuration.

Implementation Notes

  • Assumingly pretty straight forward, low risk, low hanging fruit overall with substantial benefit/impact for customers. Need to explore the feasibility of a per-control level.
  • IMPORTANT: There is a feature which not many people know of, where a whole Form can be used as a control, in which case the Form acts as a UserControl. If we decide, control level for that feature is not feasible, I would even suggest to throw an exception, if a Form is added to the parent's ControlCollection with its ScreenCaptureMode set to anything else than Allow.

Limitations/Discussion points

  • This full Win32 API is available on Windows 10 version 2004 and higher
  • It of course doesn't prevent hardware-based screen captures (e.g., taking a photo of the screen), which need to be clearly stated in the API docs, along, that this can help securing data but not totally prevent it.
  • The protection applies at the window level and may not be granular enough for all scenarios. We should be adding a few respective warnings in the docs.

Benefits

  • Simple API that's easy for developers to adopt
  • Raises awareness about an important security consideration
  • Provides immediate protection against many common screen capture methods
  • Aligns with the "secure by default" principle by making security features easily accessible
@KlausLoeffelmann KlausLoeffelmann added security Issues of runtime code vulnerabilities or unintentional exposing customer data side effect untriaged The team needs to look at this issue in the next triage and removed needs-area-label labels Apr 7, 2025
@merriemcgaw merriemcgaw added api-suggestion (1) Early API idea and discussion, it is NOT ready for implementation and removed untriaged The team needs to look at this issue in the next triage labels Apr 8, 2025
@merriemcgaw merriemcgaw added this to the 10.0 Preview4 milestone Apr 8, 2025
@merriemcgaw merriemcgaw added blocking Used by the API Review Board api-ready-for-review (2) API is ready for formal API review; applied by the issue owner labels Apr 8, 2025
@KalleOlaviNiemitalo
Copy link

What's the Windows 11 version 22H2 API for ScreenCaptureMode.Blur?

@bartonjs
Copy link
Member

@KlausLoeffelmann Please update the proposal to include namespaces and classes for each code segment, so we don't eat up meeting time by adding them live.

Bitte, machen Sie diese Thema die Namespacennamen und die Classennamen zu haben, deshalb wir waehrend dem Treffen Mullzeit nicht machen werden.

@KlausLoeffelmann
Copy link
Member Author

What's the Windows 11 version 22H2 API for ScreenCaptureMode.Blur?

We had this as part of the initial discussions, but we are no longer considering this.

@KlausLoeffelmann
Copy link
Member Author

@bartonjs

...waehrend dem Treffen Mullzeit nicht machen

Assuming "Müllzeit", I will definitely steal this word creation and use it from now on, when I speak German! 😄

@GrabYourPitchforks
Copy link
Member

It of course doesn't prevent hardware-based screen captures (e.g., taking a photo of the screen), which need to be clearly stated in the API docs, along, that this can help securing data but not totally prevent it.

IMO the documentation should clearly call out that this API simply makes a request of the OS. It's up to other agents -- either the OS itself or other applications running on the machine -- to enforce this request.

Specifically, this flag will not prevent other applications running under your user session from capturing screen shots of your application. Yes, those other applications would have to jump through hoops to do so since the normal OS-provided screencap APIs will honor this flag, but it's critical to document that .NET does not itself provide any type of enforcement mechanism for this request.

@bartonjs
Copy link
Member

bartonjs commented Apr 15, 2025

Video

  • Putting the property on Control seems to make sense, even though HideWindow is only valid on top level forms.
    • If research says this is a bad idea, moving it to Form is also fine.
namespace System.Windows.Forms;

public partial class Control
{
   public ScreenCaptureMode ScreenCaptureMode { get; set; }
}

public enum ScreenCaptureMode
{
    Allow = 0,
    HideContent = 1,
    HideWindow = 2,
}

@bartonjs bartonjs added api-approved (4) API was approved in API review, it can be implemented and removed api-suggestion (1) Early API idea and discussion, it is NOT ready for implementation api-ready-for-review (2) API is ready for formal API review; applied by the issue owner labels Apr 15, 2025
@KlausLoeffelmann
Copy link
Member Author

IMO the documentation should clearly call out that this API simply makes a request of the OS. It's up to other agents -- either the OS itself or other applications running on the machine -- to enforce this request.

@GrabYourPitchforks: Excellent point. I am even considering including a small warning-like remark directly in the XML Summary.

@kekekeks
Copy link

FYI: This API doesn't affect AnyDesk.

@Tanya-Solyanik Tanya-Solyanik added the 📚 documentation Open issue here - https://github.com/dotnet/dotnet-api-docs/issues label Apr 16, 2025
@Tanya-Solyanik
Copy link
Contributor

even though HideWindow is only valid on top level forms

@bartonjs @KlausLoeffelmann We can reflect this restriction in the field name - HideTopLevelWindow

@Tanya-Solyanik
Copy link
Contributor

Tanya-Solyanik commented Apr 16, 2025

Add a "Security" category in the Properties panel of the WinForms designer

@KlausLoeffelmann - you didn't reflect that in the API declaration in your proposal - category, explicit default value, property description.
Designer does not have mechanism to restrict properties to a specific OS, we can mention that in the prop description though.
This should be an ambient property and child control can not set it to a different value - designer should shadow readonly on this property if the parent control sets it. If it had been set incorrectly, the child control value will be ignored at the runtime

Aligns with the "secure by default" principle by making security features easily accessible

What is the default value of this property? Anything other than allow would be breaking....

Designer features take screen captures (drag and drop, wait while reloading) we should make sure to shadow this property in the ControlDesigner.

I would even suggest to throw an exception, if a Form is added to the parent's ControlCollection with its ScreenCaptureMode set to anything else than Allow.

What was the conclusion on this? I wouldn't throw, it seems reasonable to make parent control "invisible" to capture because you don't want any children captured either.

How do we handle running on a lower level OS? Fail silently?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-approved (4) API was approved in API review, it can be implemented blocking Used by the API Review Board 📚 documentation Open issue here - https://github.com/dotnet/dotnet-api-docs/issues security Issues of runtime code vulnerabilities or unintentional exposing customer data side effect
Projects
None yet
7 participants