Fensterschutz vor Screenshots: Windows, macOS, Linux

Wie Apps Fenster vor Screenshots schützen: Windows, macOS und Linux im Detail

Wenn du versuchst, einen Screenshot von Netflix oder Spotify zu machen, siehst du statt des Videos ein schwarzes Rechteck – das ist kein Bug, sondern absichtlicher Schutz über System-APIs. Entwickler nutzen Flags wie SetWindowDisplayAffinity unter Windows oder sharingType unter macOS, um das Fenster aus den Bildschirmaufnahme-Streams auszuschließen. Aber in macOS 15 Sequoia hat Apple die Kompatibilität gebrochen, und unter Linux hängt alles vom Display-Server ab. Lass uns genauer betrachten, wie der Schutz auf jeder Plattform funktioniert, wo er versagt und welche Workarounds es gibt.

Bildschirmaufnahme-Mechanismen unter Windows: Drei Haupt-APIs

Wenn eine App wie Zoom die Berechtigung zur Bildschirmfreigabe anfordert, abonniert sie einen Framestream vom Betriebssystem. Windows bietet drei Hauptwege, um diesen Stream zu erhalten, jeder mit eigenen Eigenarten:

• GDI BitBlt from desktop DC – die älteste Methode, die seit Windows 2000 funktioniert. Sie verwendet den BitBlt-Aufruf von GetDC(NULL), um Pixel von der DWM (Desktop Window Manager)-Oberfläche in jede HDC zu kopieren. Langsam, keine Hardware-Beschleunigung, aber universell. Wird in Legacy-Apps und Monitoring-Tools eingesetzt.
• Desktop Duplication API (DXGI) – eingeführt in Windows 8. Über IDXGIOutputDuplication::AcquireNextFrame liefert sie eine GPU-Textur mit dem vollständig kompositierten Desktop-Frame. Schnell, hardwarebeschleunigt, erfasst aber nur den gesamten Monitor. Wird in klassischen Versionen von Zoom, TeamViewer, AnyDesk und Teams verwendet.
• Windows.Graphics.Capture (WGC) – der moderne Standard, eingeführt in Windows 10 1803. Unterstützt die Aufnahme entweder des gesamten Monitors oder eines spezifischen Fensters per HWND. Wird in aktuellen Versionen von OBS, Microsoft Teams, Chromium, Zoom und dem integrierten Snipping Tool genutzt.

Alle drei Methoden lesen letztlich Daten aus der DWM – dem einzigen Ort, an dem das finale Bildschirmbild zusammengesetzt wird. Hier greifen die Schutzmechanismen.

SetWindowDisplayAffinity: Modi und ihr Verhalten

Die DWM erlaubt es jedem Fenster, über die Funktion SetWindowDisplayAffinity ein display affinity-Attribut zu setzen. Dieses Attribut bestimmt, ob das Fenster in Aufnahmestreams erscheint. Drei Werte stehen zur Verfügung:

• WDA_NONE (0x00) – Fenster ist in allen Aufnahmen sichtbar (Standard).
• WDA_MONITOR (0x01) – Fenster wird auf dem Monitor angezeigt, aber in Aufnahmen durch ein schwarzes Rechteck ersetzt. Funktioniert seit Windows Vista. Netflix nutzt das zum Inhaltsschutz.
• WDA_EXCLUDEFROMCAPTURE (0x11) – Fenster wird vollständig aus dem Aufnahmestream ausgeschlossen, als ob es nicht existiert. Eingeführt im Windows 10 May 2020 Update (Build 19041). Inhalt darunterliegender Fenster schimmert durch – sauberere Lösung.

C++-Beispiel:

#include <windows.h>
#include <cstdio>

int main() {
    HWND hwnd = GetConsoleWindow();
    if (!SetWindowDisplayAffinity(hwnd, WDA_EXCLUDEFROMCAPTURE)) {
        printf("SetWindowDisplayAffinity failed: %lu\n", GetLastError());
        return 1;
    }
    printf("Okno teper nevidimo for zakhvata. Poprobuy sdelat skrinshot.\n");
    Sleep(60000);
    return 0;
}

Es funktioniert ähnlich in C# über P/Invoke, in Electron über setContentProtection(true) und in Tauri über with_content_protection(true).

Unter der Haube trennt die DWM die Compositing-Pipelines: Ein Fenster mit WDA_EXCLUDEFROMCAPTURE landet nur in der Pipeline für den physischen Monitor, nicht für Aufnime-Clients. Das lässt sich nicht auf Pixelebene umgehen.

Kompatibilität und Einschränkungen unter Windows

Tests unter Windows 11 23H2 zeigten, dass WDA_EXCLUDEFROMCAPTURE korrekt gegen alle gängigen Aufnahmmethoden wirkt:

• GDI BitBlt – Fenster fehlt.
• Desktop Duplication (DXGI) – Fenster fehlt (in Windows 11 24H2 gibt es eine Eigenart, bei der AcquireNextFrame bei Updates versteckter Fenster aufwacht, aber kein Inhalt übertragen wird).
• Windows.Graphics.Capture (WGC) – Fenster fehlt.

Die einzige Ausnahme ist PrintWindow. Diese Methode umgeht die DWM und fordert das Fenster auf, direkt in die angegebene DC zu rendern, und ignoriert das Flag. Die meisten Bildschirmfreigabe-Apps (Zoom, Teams, Discord, OBS) nutzen jedoch keine PrintWindow.

Wichtige Einschränkung: WDA_EXCLUDEFROMCAPTURE wird erst ab Windows 10 20H1 (May 2020 Update) unterstützt. Auf älteren Versionen, einschließlich LTSC, gibt die Funktion ERROR_INVALID_PARAMETER zurück. In diesen Fällen auf WDA_MONITOR zurückgreifen, das in Aufnahmen ein schwarzes Rechteck zeigt.

Es gibt zudem ein undokumentiertes Attribut WCA_EXCLUDED_FROM_DDA über SetWindowCompositionAttribute, das das Fenster nur aus der Desktop Duplication API ausschließt. In der Praxis ist es unnötig, da WDA_EXCLUDEFROMCAPTURE das umfassender abdeckt.

macOS bis 14: sharingType als zuverlässiger Mechanismus

Unter macOS bis Version 14 wurde die NSWindow-Eigenschaft sharingType genutzt:

window.sharingType = .none

Verfügbare Werte:

• .readWrite – Fenster ist lesbar und modifizierbar durch andere Prozesse (selten genutzt).
• .readOnly – Fenster ist aufnehmbar (Standard).
• .none – Fenster ist aus Aufnahmen ausgeschlossen.

Dieses Flag wirkte über WindowServer, das die Compositing über Core Graphics handhabt. Bis einschließlich macOS 14 Sonoma blockierte sharingType = .none effektiv Aufnahmen über Legacy-APIs (CGWindowListCreateImage) und das neue ScreenCaptureKit (eingeführt in macOS 12.3).

Electron und Tauri nutzten diesen Mechanismus intern für ihre setContentProtection(true)-Methoden.

macOS 15 Sequoia: Rückschritt bei ScreenCaptureKit

Mit macOS 15 Sequoia hat Apple die Architektur von WindowServer geändert: Nun werden alle sichtbaren Fenster in einen einzigen Framebuffer compositiert, und ScreenCaptureKit erfasst diesen direkt. Dadurch beeinflusst sharingType = .none SCStream nicht mehr.

Ein offizieller Apple-Vertreter bestätigte in den Developer Forums: „At this time there are no public APIs for preventing screen capture“.

Wichtige Nuance: Legacy-APIs (CGWindowListCreateImage) respektieren sharingType = .none weiterhin. Das führt zu geteiltem Verhalten bei Apps:

• Zoom (aktuell), Teams, QuickTime, System-Screenshots (Cmd+Shift+3/4/5), neuere OBS-Versionen – nutzen ScreenCaptureKit → Fenster ist sichtbar.
• Google Chrome (getDisplayMedia), Google Meet in Chrome, ältere OBS-Versionen – nutzen CoreGraphics → Fenster ist unsichtbar.

Das ist ein grundlegender Rückschritt für Produkte, die Bildschirmaufnahmeschutz brauchen. Ohne private APIs gibt es keine Lösung – und deren Nutzung garantiert Ablehnung beim App-Store-Review und Bruch bei OS-Updates. Alternativen: Unterstützung auf macOS 14 und früher beschränken oder verhaltensbasierte Methoden: Fenster bei Bildschirmfreigabe-Start automatisch minimieren, SCStream-Aktivität über System-Signale erkennen.

Linux: X11 vs. Wayland – Zwei verschiedene Welten

Unter Linux unterscheidet sich die Lage je nach Display-Server erheblich.

X11 – unterstützt architekturell keinen Fensterschutz vor Aufnahmen. Jeder Client mit Display-Zugriff kann XGetImage oder XCompositeNameWindowPixmap aufrufen, um Pixel von jedem Fenster zu greifen. Compositing-Erweiterungen (Picom, KWin, Mutter) bieten möglicherweise teilweisen Schutz, aber es gibt keine WM-übergreifende Lösung.

Wayland – basiert auf Isolationsprinzipien: Clients können die Surfaces anderer nicht lesen. Bildschirmaufnahme ist nur über xdg-desktop-portal + PipeWire möglich und nur mit expliziter Benutzerzustimmung. Fensterschutz wird auf Protokollebene gehandhabt – wenn ein Fenster keinen Zugriff gewährt, erscheint es nicht in Aufnahmen. Das macht Wayland deutlich sicherer als X11, erfordert aber korrekte Protokoll-Implementierung durch Apps.

Wichtige Erkenntnisse

• SetWindowDisplayAffinity mit WDA_EXCLUDEFROMCAPTURE – de-facto-Standard unter Windows, um ein Fenster vollständig aus Aufnahmen auszuschließen. Funktioniert ab Windows 10 May 2020 Update.
• Unter macOS 15 Sequoia wirkt sharingType = .none nicht mehr gegen ScreenCaptureKit – das ist eine Apple-Architekturänderung ohne öffentliches Workaround.
• Unter Linux macht X11 Fensterschutz protokollbedingt unmöglich; Wayland regelt es auf Protokollebene.
• PrintWindow unter Windows umgeht den Schutz, wird aber in populären Bildschirmfreigabe-Apps nicht genutzt.
• Electron und Tauri nutzen diese APIs intern – ihr Verhalten hängt von Plattform und OS-Version ab.

— Editorial Team