rebreak-monorepo/ops/mdm/MAC_SUPERVISION_RESEARCH.md

Mac "Supervision" Research — TechLockdown-Analyse & Replizierbarkeit

Research-Datum: 30. Mai 2026
Ziel: Verstehen wie TechLockdown Mac-"Supervision" implementiert und ob/wie wir das für RebreakBinder-Mac replizieren können.

---

Executive Summary

KRITISCH: macOS hat KEIN "Supervised Mode" im iOS-Sinn.

Was iOS "Supervision" ist (Device-Wipe via Apple Configurator oder DEP/ABM, persistent supervised-Flag, volle MDM-Control) existiert auf Mac NICHT. Was es gibt:

1. UAMDM (User-Approved MDM Enrollment) — User installiert MDM-Profil manuell, kein Wipe
2. Automated Device Enrollment (ADE) via ABM — Device-Zuordnung über Apple Business Manager, KANN Wipe erfordern oder Apple-Configurator-Re-Add
3. Configuration Profiles (.mobileconfig) — können viele Restrictions setzen, OHNE MDM oder ABM

TechLockdown-Kernfinding:

• ✅ Nutzen Configuration Profiles (.mobileconfig) — "Config Files" in ihrem Marketing
• ✅ KEIN Device-Wipe erforderlich
• ✅ KEIN ABM/Apple Business Manager erforderlich (nach Public-Info)
• ⚠️ Unklar: betreiben sie eigenes MDM (UAMDM) oder nur statische .mobileconfig-Downloads?
• ✅ Profile-Schutz: "Uninstall Prevented" → RemovalPassword-Feld in .mobileconfig
• ✅ Dashboard-Feature "Profile Locking" (unlock delay, random text entry, accountability notifications) ist ZUSÄTZLICH zum technischen Schutz

Replizierbarkeit für RebreakBinder-Mac: HOCH (80-90%)

• Technisch machbar in 2-4 Wochen für MVP
• Hauptdifferenz zu iOS: keine No-Erase-Supervision (weil es das Konzept auf Mac nicht gibt)
• Pfad: UAMDM + .mobileconfig mit Restrictions + Dashboard-generierte Profiles

---

1. TechLockdown-Findings (verifiziert via techlockdown.com)

1.1 Hauptmechanik: Apple Configuration Profiles

Quelle: https://techlockdown.com/articles/block-porn-mac (fetched 30.05.2026)

TechLockdown nennt Configuration Profiles "Config Files" und beschreibt sie als:

"Config Files, also known as Apple Configuration Profiles, are used to set restrictions on a Mac computer, similar to Screen Time or parental controls."

Was sie damit machen:

Feature	Mechanik	Verifiziert?
Browser-Content-Filter	Configuration Profile mit Custom-Payload für Safari/Chrome Web Content Filter	✅ (erwähnt in Article)
Private-Browsing blockieren	Restrictions-Payload → allowPrivateBrowsing: false (Safari/Chrome)	✅
SafeSearch erzwingen	DNS-Content-Policy (Google: 216.239.38.120, Bing: DNS-Filter)	✅
Browser-Extensions blocken	Restrictions-Payload → Extension-Allowlist/Blocklist	✅ (erwähnt)
Extension-Store blocken	allowExtensionsStore: false (Chrome/Edge)	✅ (erwähnt)
DNS-Filter	Configuration Profile mit DNS-Settings oder DNSProxy-Payload	✅
hosts-File-Modifikation	Erwähnt als Alternative zu DNS	✅ (nicht via Profil, manuell)

1.2 Profile-Schutz-Mechanik

TechLockdown-Feature: "Uninstall Prevented"

Aus ihrem Mac-Article:

"When you download your Config Presets, you have the option to require a password in order to remove your Config Files."

Technische Umsetzung (Standard-Apple-Mechanik):

<key>PayloadRemovalDisallowed</key>
<true/>

ODER (älter, deprecated):

<key>RemovalPassword</key>
<string>hashed_password_here</string>

Wichtig: PayloadRemovalDisallowed verhindert User-Removal NUR wenn Profil via MDM gepusht wurde (nicht bei manueller Installation). Bei manueller Installation ist RemovalPassword der einzige Schutz → User muss Passwort kennen um Profil zu löschen.

1.3 "Profile Locking" — Dashboard-Feature (NICHT Apple-Mechanik)

Quelle: https://techlockdown.com/features/profile-locking

TechLockdown's Dashboard bietet zusätzliche Schutz-Layer:

• Unlock Delay: Profile erst nach z.B. 5 Minuten unlockbar (künstliche Verzögerung)
• Random Text Entry: User muss exakten String abtippen (z.B. aB3cD5eF7gH9{J1k<3m#5oP7qR9sT1uV3wX5&Z7)
• Accountability Notifications: Email an Trusted Person bei Unlock/Lock

KRITISCH: Dies ist KEIN Apple-OS-Feature. Das ist ihre Web-App-Logik. Der User muss sich auf techlockdown.com einloggen um das Password für Profile-Removal zu sehen → während des Logins erzwingen sie delay+random-text+notification.

Hypothese (NICHT verifiziert, aber logisch):

1. User installiert .mobileconfig mit RemovalPassword: "random_secure_hash"
2. User kennt Passwort NICHT (TechLockdown generiert es, zeigt es nicht sofort)
3. Wenn User Profil entfernen will → macOS fragt nach Password
4. User muss auf TechLockdown-Dashboard gehen → "Unlock Profile" klicken
5. Dashboard zeigt Password erst nach delay+random-text+notification

Das bedeutet: Technisch ist es nur RemovalPassword. Der "Locking"-Layer ist Web-App-UX.

1.4 "Managed Mode" für Browser-Extensions

TechLockdown erwähnt:

"Tech Lockdown members will also have the option to enforce browser restrictions with managed mode on their Mac devices: You can hide the option to uninstall any extension you choose."

Was "Managed Mode" bedeutet (Apple-Definition):

• Browser-Extensions können als "managed" markiert werden wenn sie via MDM/Configuration-Profile installiert werden
• Managed Extensions: User kann sie nicht deinstallieren (Option ist ausgegraut/versteckt)
• Extension-Allowlist/Blocklist via Configuration Profile

Payload-Beispiel (Chrome):

<key>ExtensionSettings</key>
<dict>
    <key>EXTENSION_ID</key>
    <dict>
        <key>installation_mode</key>
        <string>force_installed</string>  <!-- managed, nicht entfernbar -->
        <key>update_url</key>
        <string>https://clients2.google.com/service/update2/crx</string>
    </dict>
</dict>

WICHTIG: Managed Extension Installation funktioniert NUR mit:

• MDM-gepushten Profiles ODER
• Configuration Profiles die vom User approved sind (UAMDM) ODER
• Profiles signiert mit Device Management Cert

1.5 Was TechLockdown NICHT erwähnt

❌ Device-Wipe / Erase
❌ Apple Configurator
❌ Apple Business Manager (ABM)
❌ Supervision (iOS-Konzept)
❌ System Extensions (NEFilterProvider etc.)
❌ Device Enrollment Program (DEP)
❌ "Automated Device Enrollment"

Interpretation: TechLockdown verwendet den simpelsten Pfad — Configuration Profiles + optional UAMDM (wenn sie eigenes MDM haben).

---

2. Apple-Mechanik Deep-Dive: macOS MDM vs. iOS MDM

2.1 "Supervision" auf Mac existiert NICHT

Konzept	iOS	macOS
Supervised Mode	✅ Existiert (via Configurator oder DEP)	❌ Existiert nicht
Supervised-Flag	✅ Persistent nach Wipe/Setup-Assistant	❌ Kein Äquivalent
Requires Device-Wipe	✅ Ja (außer via DEP/ABM)	N/A
Full MDM Control	✅ Supervised = volle Restrictions	⚠️ Abhängig von UAMDM vs. ADE
User-Removal von Profilen	Supervised: Nur MDM kann entfernen	UAMDM: User KANN entfernen (außer RemovalPassword)

2.2 macOS Enrollment-Pfade

Option 1: UAMDM (User-Approved MDM Enrollment)

Flow:

1. User bekommt .mobileconfig-Download-Link (via Safari)
2. User öffnet .mobileconfig → macOS zeigt "Profil heruntergeladen" Notification
3. User geht zu System Settings → Privacy & Security → Profiles
4. User klickt "Install" → macOS zeigt MDM-Consent-Dialog ("This will allow XYZ to manage this Mac")
5. User muss Admin-Passwort eingeben → MDM-Enrollment abgeschlossen

Eigenschaften:

• ✅ KEIN Device-Wipe
• ✅ KEIN Apple Business Manager nötig
• ✅ User behält Control (kann MDM-Profil jederzeit entfernen — außer RemovalPassword gesetzt)
• ⚠️ Einige MDM-Payloads funktionieren NUR mit UAMDM (z.B. Kernel-Extension-Approval, SystemExtension-Silent-Install)
• ⚠️ User sieht dass MDM installiert ist (in System Settings)

Schutz gegen Removal:

<key>RemovalPassword</key>
<string>HASHED_PASSWORD</string>

→ User muss Passwort kennen um Profil zu löschen

Option 2: Automated Device Enrollment (ADE) via ABM

Flow:

1. Device wird in Apple Business Manager (ABM) registriert
   • Via Apple Authorized Reseller (bei Kauf)
   • Via Apple Configurator iPhone-App (nachträglich, nur während Setup-Assistant)
2. Device aktiviert → Setup-Assistant zeigt "Remote Management" Screen
3. Device enrollt automatisch in vorkonfiguriertes MDM
4. MDM pusht Profiles → User kann NICHT ablehnen

Eigenschaften:

• ✅ Automatisch, kein User-Klick-Fiesta
• ✅ Profile sind "supervised-like" (User kann sie nicht entfernen)
• ❌ Kann Device-Wipe erfordern (abhängig ob Device schon eingerichtet war)
• ❌ Braucht ABM-Account (kostenlos, aber Apple-Business-Verifizierung nötig)
• ❌ Device muss bei Apple als "managed" registriert sein

KRITISCH für RebreakBinder: ADE ist overkill für Consumer-Use-Case. ABM ist für Unternehmen/Schulen gedacht. Consumer-Devices nachträglich zu ABM hinzuzufügen ist kompliziert (nur via Configurator-iPhone-App während Setup-Assistant → Device-Wipe).

Option 3: Statische Configuration Profiles (kein MDM)

Flow:

1. User lädt .mobileconfig herunter
2. User öffnet → System Settings → Profiles → Install
3. Profil ist installiert

Eigenschaften:

• ✅ Einfachst möglich
• ✅ KEIN MDM-Server nötig
• ❌ KEINE "managed" Features (z.B. Extensions können nicht force-installed werden)
• ❌ User kann Profil jederzeit entfernen (außer RemovalPassword)
• ❌ MDM-Push-Updates nicht möglich (User muss neue Profiles manuell installieren)

Nutzbar für: DNS-Filter, Browser-Restrictions, SafeSearch, aber NICHT für Managed-Extension-Install

2.3 Welche Restrictions brauchen Supervision/ABM?

Apple's offizielle Doku ist unklar — meine Research zeigt:

Restriction/Payload	UAMDM (ohne ABM)	ADE (via ABM)	Static Profile
DNS-Settings	✅	✅	✅
com.apple.applicationaccess (Restrictions)	✅	✅	✅
Browser-Restrictions (Private-Browsing etc.)	✅	✅	✅
SystemExtensions-Silent-Approval	✅ (UAMDM required)	✅	❌
Managed Browser Extensions	✅ (mit UAMDM-MDM)	✅	❌
com.apple.webcontent-filter (iOS-only?)	❌ (iOS-only laut Doku)	❌	❌
NEFilterProvider System Extension	⚠️ Kompliziert (siehe 2.4)	✅	❌

2.4 System Extensions auf Mac (NEFilterProvider)

Wenn wir eine NEFilterProvider System Extension für Mac bauen wollen (analog zu iOS NEFilter):

Requirements:

1. macOS App mit System Extension Target
2. Developer-ID-Signierung (NICHT App-Store-Signierung)
3. Notarization via Apple
4. System Extension Entitlement: com.apple.developer.system-extension.install
5. Network Extension Entitlement: com.apple.developer.networking.networkextension

Installation-Pfade:

Pfad	User-Approval nötig?	Silent Install möglich?
Direkt aus App	✅ Ja (User muss in System Settings → Security klicken)	❌
Via MDM (UAMDM) + SystemExtensions-Payload	⚠️ Reduziert (User muss MDM approven, dann silent)	✅ (nach MDM-Enrollment)
Via ABM/ADE	✅ Silent (kein User-Click)	✅

SystemExtensions Payload-Beispiel:

<key>PayloadType</key>
<string>com.apple.system-extension-policy</string>
<key>AllowUserOverrides</key>
<false/>
<key>AllowedSystemExtensions</key>
<dict>
    <key>YOUR_TEAM_ID</key>
    <array>
        <string>org.rebreak.nefilter.extension</string>
    </array>
</dict>

WICHTIG: Diese Payload funktioniert NUR wenn via MDM gepusht (UAMDM oder ADE). Static Profile-Install funktioniert NICHT.

---

3. Replizierbarkeits-Matrix: TechLockdown vs. RebreakBinder-Mac

Feature	TechLockdown (angenommen)	RebreakBinder-Mac (Pfad 1: UAMDM)	RebreakBinder-Mac (Pfad 2: Static Profiles)	Effort
DNS-Filter	✅ Configuration Profile	✅ .mobileconfig mit DNS-Proxy/Settings	✅ .mobileconfig	2-3 Tage
Browser-Restrictions (Private-Browsing, Extension-Store)	✅ Restrictions-Payload	✅ Restrictions-Payload	✅ Restrictions-Payload	3-5 Tage
SafeSearch erzwingen	✅ DNS + hosts	✅ DNS + Restrictions	✅ DNS + Restrictions	1-2 Tage
Managed Browser-Extensions	✅ (mit UAMDM-MDM)	✅ (braucht UAMDM-MDM)	❌ (geht nicht ohne MDM)	1 Woche (MDM-Server-Setup)
Profile-Schutz (RemovalPassword)	✅ RemovalPassword-Feld	✅ RemovalPassword-Feld	✅ RemovalPassword-Feld	1 Tag
"Profile Locking" (delay, random text, accountability)	✅ Dashboard-Logic	✅ Dashboard-Logic (replizierbar)	✅ Dashboard-Logic	3-5 Tage (Backend)
NEFilterProvider System-Extension	❌ (nicht erwähnt, vermutlich nicht)	⚠️ Möglich mit UAMDM	❌ (geht nicht ohne MDM)	2-3 Wochen (Extension bauen + Signing)
App nicht löschbar	❌ (nicht möglich auf Mac ohne ADE)	❌ (auch mit UAMDM nicht)	❌	N/A
Kein Device-Wipe	✅	✅	✅	N/A
ABM-Account nötig	❌ (nach Public-Info)	❌ (UAMDM = kein ABM)	❌	N/A

Legende:

• ✅ Funktioniert / replizierbar
• ⚠️ Funktioniert mit Einschränkungen
• ❌ Funktioniert nicht / nicht replizierbar

---

4. Empfehlung für RebreakBinder-Mac

4.1 MVP-Pfad (2-4 Wochen, 80% TechLockdown-Feature-Parity)

Techstack:

1. UAMDM-MDM-Server (NanoMDM — wir haben das schon für iOS)
   • Selbst-gehostet auf mdm-mac.rebreak.org (oder Subdomain von mdm.rebreak.org)
   • Verwendet für: Profile-Push + Updates
2. Configuration Profiles (.mobileconfig) mit:
   • DNS-Proxy-Payload (AdGuard DNS mit ClientID)
   • Restrictions-Payload (Browser-Restrictions, SafeSearch, Extension-Control)
   • RemovalPassword (generiert auf Backend, nicht sofort sichtbar)
3. RebreakBinder-Mac App (SwiftUI macOS):
   • Wizard für MDM-Enrollment (UAMDM-Flow)
   • Lokale Checks (iCloud-Locked?, FileVault?, Admin-User?)
   • Profile-Download + Install-Anleitung
4. Backend-Extension (Nitro):
   • /api/binder/mac/enroll → generiert UAMDM-Enrollment-Profil
   • /api/binder/mac/profiles → generiert Restriction-Profiles mit RemovalPassword
   • "Profile Locking" Logic (unlock-delay, random-text, accountability-email)

Flow:

1. User öffnet RebreakBinder-Mac → Wizard startet
2. Pre-Flight: Check ob iCloud-Locked, Admin-User, etc.
3. MDM-Enrollment:
   • App zeigt .mobileconfig-Download für NanoMDM-Enrollment
   • User installiert → macOS zeigt UAMDM-Consent
   • User approved → Device enrollt in NanoMDM
4. Restriction-Profiles:
   • NanoMDM pusht DNS-Filter + Browser-Restrictions + SafeSearch
   • Profile hat RemovalPassword gesetzt (User kennt es NICHT)
5. Lock-Mechanik:
   • User will Profil entfernen → macOS fragt nach Password
   • User geht auf rebreak.org/settings → "Unlock Mac Profile"
   • Backend zeigt Password erst nach delay + random-text + Email an Parent

Vorteile:

• ✅ KEIN Device-Wipe
• ✅ KEIN ABM nötig
• ✅ Repliziert 80% von TechLockdown
• ✅ Verwendet bestehende NanoMDM-Infrastruktur

Nachteile:

• ⚠️ User kann MDM-Profil theoretisch entfernen (wenn er Admin-Passwort hat) → dann sind alle Restrictions weg
• ⚠️ Weniger "locked-down" als iOS-Supervision (weil Mac kein Supervision-Konzept hat)

4.2 Advanced-Pfad (4-8 Wochen, 95% Feature-Parity + System-Extension)

Zusätzlich zu MVP:

1. NEFilterProvider System-Extension (analog zu iOS):
   • Mac-App mit System-Extension-Target
   • Network-Extension-Filter (blockt auf Netzwerk-Layer)
   • Via UAMDM-MDM silent-installed (SystemExtensions-Payload)
2. Managed Browser-Extension (Chrome/Safari):
   • Extension als "managed" via MDM installiert
   • User kann Extension nicht deinstallieren
   • Backup-Layer falls DNS-Filter gebypassed wird

Vorteile:

• ✅ Multi-Layer-Blocking (DNS + System-Extension + Browser-Extension)
• ✅ Schwerer zu bypassen als nur DNS-Filter

Nachteile:

• ⚠️ System-Extension braucht Developer-ID + Notarization (2-3 Tage Setup)
• ⚠️ User muss UAMDM approven (sichtbar in System Settings)
• ⚠️ 2-3 Wochen zusätzlicher Entwicklungsaufwand

4.3 Was wir NICHT replizieren können (Mac-Limitierungen)

❌ App nicht löschbar — nur via ADE/ABM möglich, nicht für Consumer-Devices
❌ "Supervised" Status — existiert auf Mac nicht
❌ Erzwungenes MDM (wie iOS DEP) — User kann UAMDM-Profil entfernen wenn Admin
❌ Settings-Toggle disablen (wie iOS NEFilter-Settings) — Mac-System-Settings sind offen

ABER: Mit RemovalPassword + "Profile Locking" (delay+random-text+email) erreichen wir ähnlichen Schutz → User muss bewusst umgehen, kann nicht "aus Versehen" deaktivieren.

---

5. Apple Business Manager (ABM) — Do We Need It?

5.1 Was ist ABM?

• Kostenloser Apple-Service für Unternehmen/Schulen
• Ermöglicht Device-Management ohne User-Touch (Automated Device Enrollment)
• Devices werden bei Kauf vom Reseller automatisch zu ABM hinzugefügt

5.2 ABM-Setup-Prozess

1. Apple Business Manager Account erstellen:
   • https://business.apple.com
   • Braucht: Business-Name, DUNS-Nummer (oder Business-Verifizierung)
   • Approval-Zeit: 1-3 Tage
2. Devices registrieren:
   • Via Apple Authorized Reseller (bei Neukauf)
   • Via Apple Configurator iPhone-App (nachträglich, nur während Setup-Assistant → Device-Wipe)
   • Via CSV-Upload (Device-Serial-Numbers)
3. MDM-Server verlinken:
   • ABM → Settings → MDM-Server hinzufügen
   • Download ABM-Public-Key + Upload MDM-Server-Cert
4. Enrollment-Profile erstellen:
   • Definiert welches MDM, welche Restrictions, welcher Setup-Assistant-Skip
5. Device aktiviert → Auto-Enrollment

5.3 Brauchen wir das?

TechLockdown: Vermutlich NEIN (keine Erwähnung in Public-Docs)
RebreakBinder-Mac MVP: NEIN — UAMDM reicht
RebreakBinder-Mac Advanced: NEIN — ABM macht nur Sinn für "owned devices" (Unternehmen kauft Macs für Employees)

Für unseren Use-Case (Consumer-Family, eigenes Device):

• ABM = Overkill
• UAMDM = Sweet Spot (User behält Ownership, wir bekommen MDM-Control)

AUSNAHME: Wenn wir jemals ein "ReBreak-Family-Mac-Rental-Programm" machen (wir kaufen Macs, leasen sie an Families) → dann ABM sinnvoll.

---

6. Offene Fragen / Risiken / User-Decisions-Needed

6.1 Offene Fragen

1. Kann TechLockdown's "managed mode" für Extensions wirklich ohne MDM?

   • Hypothese: NEIN — "managed" braucht MDM. Entweder TechLockdown hat UAMDM oder sie meinen was anderes mit "managed mode"
   • To-Do: Test mit ihrer Trial → Mac-Setup durchgehen, schauen ob MDM-Enrollment nötig ist

2. Wie handlen sie Updates?

   • Wenn UAMDM: MDM-Push für neue Profiles
   • Wenn Static: User muss neue .mobileconfig manuell installieren
   • To-Do: TechLockdown-Trial testen

3. Was passiert wenn User Admin-Passwort vergisst?

   • User kann MDM-Profil NICHT entfernen (braucht Admin-PW für System Settings → Profiles → Remove)
   • Aber User kann Mac komplett wipen via Recovery-Mode
   • Mitigation: In unserer Doku klar machen dass Wipe immer möglich ist

6.2 Risiken

Risiko	Impact	Likelihood	Mitigation
User entfernt MDM-Profil via Recovery-Mode-Wipe	HIGH (alles weg)	MEDIUM (motivated user)	Accountability-Layer (Email an Parent bei Profil-Removal-Versuch)
User findet RemovalPassword via Keychain/Logs	MEDIUM (Profil entfernbar)	LOW (braucht Tech-Skills)	Password-Hash statt Plaintext, nie loggen
macOS-Update bricht MDM-Enrollment	MEDIUM (Re-Enrollment nötig)	LOW (Apple testet MDM gut)	Health-Check im Backend, Push-Notification an Parent bei Device-Offline
Apple ändert UAMDM-Mechanik in macOS 16	HIGH (Flow bricht)	LOW (UAMDM ist stable API)	Stay updated mit Apple-Developer-Betas

6.3 User-Decisions-Needed

Vor Implementation Start:

1. Gehen wir mit UAMDM-MDM oder Static Profiles?

   • UAMDM = mehr Features (managed extensions, silent system extension), aber sichtbar in Settings
   • Static = simpler, aber weniger Schutz
   • Empfehlung: UAMDM (wir haben NanoMDM schon, Effort ist gering)

2. System-Extension ja/nein im MVP?

   • Ja = 2-3 Wochen länger, aber besserer Bypass-Schutz
   • Nein = schneller MVP, DNS-only-Blocking
   • Empfehlung: NEIN im MVP, Phase 2

3. Wie kommunizieren wir dass Mac weniger "locked-down" ist als iOS?

   • Mac = User behält mehr Control (ist macOS-Philosophy)
   • iOS = Supervision = volle Lockdown
   • Empfehlung: Transparent sein: "Mac-Blocking ist effektiv aber nicht unbreakable wie iOS"

4. ABM-Account beantragen (future-proofing)?

   • Kostet nichts außer Setup-Zeit
   • Könnte nützlich sein für Enterprise-Use-Cases später
   • Empfehlung: JA, aber low-priority (nicht für MVP nötig)

---

7. Implementation-Roadmap (wenn GO-Entscheidung)

Phase 1: MVP (2-4 Wochen)

Week 1: NanoMDM-Mac-Setup + Backend

• NanoMDM-Subdomain für Mac (mdm-mac.rebreak.org oder Shared mit iOS)
• Backend-Endpoints:
  • POST /api/binder/mac/enroll → generiert UAMDM-Enrollment-Profil
  • POST /api/binder/mac/profiles/restrictions → generiert Restriction-Profile
  • POST /api/binder/mac/unlock → Profile-Locking-Logic (delay+random-text)
• Profile-Templates (.mobileconfig):
  • DNS-Proxy (AdGuard mit ClientID)
  • Restrictions (Browser, SafeSearch, Extension-Control)
  • RemovalPassword-Handling

Week 2-3: RebreakBinder-Mac App (SwiftUI)

• Wizard-UI (analog zu iOS-Version)
• Pre-Flight-Checks:
  • iCloud-Account-Status
  • FileVault-Status
  • Admin-User-Check
• MDM-Enrollment-Flow:
  • .mobileconfig-Download via Safari
  • System-Settings-Anleitung (Screenshots)
  • Verification (Device erscheint in NanoMDM)
• Success-Screen + Setup-Completion

Week 4: Testing + Docs

• Test auf verschiedenen macOS-Versionen (Ventura, Sonoma, Sequoia)
• User-Doku: "Mac-Setup-Guide"
• Runbook: "Mac-MDM-Recovery" (was tun wenn Profil weg ist)
• Beta-Test mit Chahine + Olfa-Macs

Phase 2: Advanced (4-8 Wochen, optional)

NEFilterProvider System-Extension:

• Xcode-Projekt: Mac-App + System-Extension-Target
• Network-Extension-Code (analog zu iOS NEFilter)
• Developer-ID-Signierung + Notarization
• SystemExtensions-Payload für silent install via MDM
• Testing + macOS-Security-Approval-Flow

Managed Browser-Extension:

• Chrome-Extension (Web-Content-Blocker)
• Safari-Extension (Content-Blocker)
• MDM-Payload für force-install + managed-mode
• Testing

---

8. Quellen & Verifikations-Status

Quelle	URL	Verifiziert?	Datum
TechLockdown Mac Article	https://techlockdown.com/articles/block-porn-mac	✅ Fetched & parsed	30.05.2026
TechLockdown Profile-Locking	https://techlockdown.com/features/profile-locking	✅ Fetched	30.05.2026
Apple Configuration Profile Reference	developer.apple.com/business/documentation/	⚠️ Fetched PDF, parsing incomplete	30.05.2026
Apple MDM Protocol Reference	developer.apple.com/business/documentation/	⚠️ Fetched, parsing incomplete	30.05.2026
Apple UAMDM Docs	developer.apple.com/documentation/devicemanagement	❌ JS-required, couldn't fetch	30.05.2026

Verifikations-Grad:

• ✅ TechLockdown-Mechanik: 80% verifiziert (Public-Info, keine Trial getestet)
• ⚠️ Apple-Mechanik: 60% verifiziert (Doku-Access limited, basiert auf Known-Knowledge + PDF-Snippets)
• ❌ TechLockdown-MDM-Server: 0% verifiziert (nicht public, Hypothese)

Nächste Schritte für 100% Verifikation:

1. TechLockdown-Trial-Account → Mac-Setup durchgehen → schauen ob MDM-Enrollment oder nur .mobileconfig
2. tcpdump auf Mac während TechLockdown-Setup → sehen ob MDM-Server-Traffic
3. Installiertes Profil inspizieren: sudo profiles show -all → sehen ob RemovalPassword, MDM-Server-URL, etc.

---

9. Fazit

TechLockdown's Mac-"Supervision" ist KEIN Supervision (weil das auf Mac nicht existiert). Es ist UAMDM (wahrscheinlich) + Configuration Profiles + RemovalPassword + clevere Dashboard-UX.

Wir können 80-90% davon replizieren in 2-4 Wochen mit:

• NanoMDM (haben wir schon)
• .mobileconfig-Profile (DNS, Restrictions, Browser)
• RemovalPassword + "Profile Locking" Backend-Logic
• RebreakBinder-Mac SwiftUI-App als Wizard

Was wir NICHT replizieren können:

• "Supervision" (existiert auf Mac nicht)
• App-nicht-löschbar (nur via ADE/ABM, nicht Consumer-freundlich)

Empfehlung: GO für MVP-Pfad (UAMDM + Profiles), SKIP System-Extension im MVP (Phase 2), SKIP ABM (nicht nötig).

Ehrlichkeits-Disclaimer für User: "Mac-Blocking ist effektiv und multi-layered (DNS + Browser + Accountability), aber nicht unbreakable wie iOS-Supervision. Ein Mac-User mit Admin-Zugriff kann theoretisch alles umgehen (wie bei jedem Mac-Parental-Control-Tool). Unser Schutz basiert auf Accountability + technischen Hürden, nicht auf absolutem Lock-Down."

---

Nächster Schritt: User-Entscheidung über Pfad → dann detailed Implementation-Planning für RebreakBinder-Mac.