| Platform | OS / Device | Enrollment | TOR Reference | Limitation Basis | BAEC | |
|---|---|---|---|---|---|---|
| Apple | Apple iOS / iPadOS Smartphone / Tablet |
BYOD (Unsupervised) | TOR 2.15, TOR 2.17 | Apple iOS sandbox restrictions prevent full background silent app uninstall or full factory wipe without user consent on unsupervised BYOD devices. | Selective Enterprise Profile Revocation: Instantly purges all school/managed data while respecting privacy. | |
|
📄 Evidence & Context Operational Explanation: All iOS apps execute within isolated, non-privileged sandboxes. On unsupervised BYOD devices (User Enrollment), the MDM framework is limited to Selective Enterprise Wipes (removing corporate data and managed apps). It cannot perform full factory resets (EraseDevice) or silently delete personal apps without explicit user interaction. Source References Apple Support — Security of runtime process in iOS Context: Establishes that all third-party iOS software operates in a non-privileged sandbox, proving that apps cannot escalate rights to wipe system files or delete other apps. Apple Support — User Enrollment and device management Context: Defines the explicit privacy boundaries of BYOD User Enrollment, proving that enterprise management cannot touch personal apps or personal device storage. Apple Support — Erase Apple devices Context: Confirms in Apple's deployment specification that the EraseDevice (full factory wipe) command is ignored on User Enrolled personal devices. |
||||||
| Google ChromeOS Chromebook |
Managed Guest Sessions | TOR 2.11, TOR 2.18 | ChromeOS extension framework boundaries and restrictions on non-managed guest sessions prevent deep kernel-level agent execution or strict hardware port blocking without official enterprise enrollment. | Chrome Education Upgrade Enforcement: Enforced Chrome Enterprise Enrollment. | ||
|
📄 Evidence & Context Operational Explanation: Chrome extensions operate inside user-mode web-renderer sandboxes and lack native C/C++ kernel access or ring-0 privilege execution. Hardware-enforced Verified Boot prevents persistent root filesystem modifications. Hardware restrictions (such as blocking USB storage ports) require official Enterprise Device Enrollment to take effect. Source References Chromium Docs — Extension Architecture & Sandboxing Context: Details the process-level isolation of extensions, proving they run as unprivileged browser renderers without host kernel or device-driver execution rights. Chromium Docs — Developer Mode & OS Integrity Architecture Context: Demonstrates that ChromeOS root filesystems are read-only and cryptographically verified, preventing third-party security agents from installing kernel hooks. Chrome Enterprise Policy Documentation — ExternalStorageDisabled Context: Validates that hardware controls (like USB port blocking via ExternalStorageDisabled) are device policies enforced solely on enrolled enterprise assets. |
||||||
| Microsoft | Windows 10/11 Home PC / Laptop |
BYOD / Legacy Enrollment | TOR 2.1, TOR 2.13 | Legacy Windows Home operating systems natively lack kernel-level MDM API access compared to Pro/Enterprise editions. Advanced Intune device-level policies are not supported natively. | Agent-Based Deployment: Utilizing supported user-space controls and manual provisioning. | |
|
📄 Evidence & Context Operational Explanation: Windows Home lacks native Microsoft Entra ID join capabilities and ignores enterprise Configuration Service Providers (CSPs). Core management engines (BitLocker management, Group Policy/ADMX ingestion, AppLocker/WDAC) require Windows Pro, Enterprise, or Education editions. Source References Microsoft Learn — MDM enrollment of Windows devices Context: Confirms that Windows Home explicitly blocks Entra ID (Azure AD) domain join and full enterprise MDM enrollment flows. Microsoft Learn — Supported operating systems and browsers in Intune Context: Outlines OS edition prerequisites for Intune management, highlighting that Windows Home is restricted from advanced configuration profiles. Microsoft Learn — Configuration service provider (CSP) reference Context: Documents the underlying CSP architecture, showing that enterprise policy CSPs list Pro/Enterprise as hard minimum operating system requirements. |
||||||
| Google Android Smartphone / Tablet |
Legacy / BYOD | TOR 2.15 | Silent installation of applications requires Android Enterprise privileges. Standard legacy device administrator APIs are deprecated and cannot silently install or update apps in the background. | Zero-Touch & Managed Play: Enforcing Android Enterprise Zero-Touch enrollment. | ||
|
📄 Evidence & Context Operational Explanation: Silent, non-interactive app installations require Android Enterprise DPC provisioning in Device Owner or Profile Owner mode via the PackageInstaller API. Legacy Device Administrator mode (DeviceAdminReceiver) was formally deprecated in Android 10 and cannot silently install or update apps without interactive user prompts. Source References Android Developers — Android 6.0 Enterprise Features (PackageInstaller) Context: Pinpoints the introduction of silent background installation capabilities, showing it was built exclusively for Android Enterprise Device Owner mode. Android Developers — What's new for enterprise in Android 10 Context: Proves Google's formal deprecation of legacy Device Admin policies in favor of modern Android Enterprise deployment models. Android Developers — Device Administration Guide Context: Details the limited permissions of legacy Device Admin, demonstrating that package installation APIs were never included in that framework. |
||||||
| Apple | Apple iOS / macOS Tablet / Mac |
Any | TOR 2.19 | Apple does not provide a public MDM payload to completely disable 'Developer Mode' natively for security reasons, as it is strictly controlled by the physical user with the device passcode. | Strict Configuration Profiles: Enforcing profiles to block the execution of sideloaded apps. | |
|
📄 Evidence & Context Operational Explanation: iOS Developer Mode requires physical interaction, a local device reboot, and physical passcode authentication on screen. Apple deliberately excludes a public MDM restriction key for Developer Mode, treating it as a strict physical hardware trust boundary that cannot be remotely overridden. Source References Apple Developer Documentation — Enabling Developer Mode on a Device Context: Documents the required physical workflow (rebooting and entering the device passcode) to activate Developer Mode, showing it mandates local user consent. Apple Developer Documentation — MDM Restrictions Configuration Profile Keys Context: Provides the complete official list of configurable restriction keys, verifying the complete absence of any payload key to toggle Developer Mode. Apple Support — Device management restrictions for supervised Apple devices Context: Confirms that even under full device supervision, Apple does not grant MDM servers administrative control over Developer Mode. |
||||||
| Microsoft | Windows 10/11 PC / Laptop |
Shared Device Mode | TOR 2.3, TOR 2.18 | Windows Hello biometrics are bound to individual local user profiles and the TPM. They do not seamlessly scale for dynamic multi-user shared devices (hundreds of students) without significant profile bloat. | FIDO2 & Secure Passwords: Standard Azure AD/Entra ID secure password policies. | |
|
📄 Evidence & Context Operational Explanation: Windows Hello biometric templates are cryptographically bound to specific local user profiles and the local TPM. On shared multi-user devices (e.g., student laptops), enrolling biometrics creates local profile bloat that causes disk starvation, leading enterprise policies like Shared PC Mode to explicitly disable Windows Hello. Source References Microsoft Learn — Windows Hello for Business FAQ Context: Explains that biometric data is tied locally to a specific profile hash and TPM key on that exact hardware, preventing roaming biometrics. Microsoft Learn — Manage multi-user and guest Windows devices with Shared PC Context: Details how local profile accumulation degrades performance on multi-user machines and mandates profile deletion routines. Microsoft Learn — SharedPC & CloudDesktop CSP Technical Reference Context: Shows that Microsoft's recommended MDM policy templates for shared devices explicitly disable Windows Hello biometrics by default to avoid profile bloat. |
||||||
| Generic | All Platforms All Devices |
Any | TOR 2.16 | MDM protocols generally do not have visibility into encrypted HTTPS traffic of third-party apps to natively block 'in-app purchases' dynamically on a per-transaction basis outside of the official App Store ecosystems. | App Store Restrictions & Content Filtering: Disabling in-app purchases via OS-level App Store restrictions. | |
|
📄 Evidence & Context Operational Explanation: MDM operates at the control plane (pushing configuration profiles and policy commands) rather than as a network-level proxy. Third-party applications using TLS or certificate pinning obscure payment traffic from MDM agents, making per-transaction dynamic blocking impossible outside native app store APIs. Source References Apple Support — Filter Content for Apple Devices Context: Distinguishes the MDM control channel from network payload filters, showing MDM commands do not perform inline packet inspection. Android Developers — Network Security Configuration & Certificate Pinning Context: Proves mobile apps do not trust user- or MDM-installed root certificates by default, preventing interception of HTTPS payment traffic. Apple Developer Documentation — MDM Restrictions Configuration Profile Keys Context: Demonstrates that restriction payloads can only disable native StoreKit APIs, not arbitrary third-party web checkouts inside apps. |
||||||
| Apple | Apple iOS / iPadOS Smartphone / Tablet |
Any | TOR 2.12 | Apple's native Screen Time and Family Controls APIs are restricted to consumer Apple IDs using iCloud Family Sharing. The official Apple Enterprise MDM protocol does not support setting granular daily time limits per app. | Custom Endpoint Agent & Network Filtering: Using network-level filtering to block the app's internet access. | |
|
📄 Evidence & Context Operational Explanation: Apple's FamilyControls framework explicitly mandates consumer iCloud Family Sharing and parental permission entitlements. Managed Apple Accounts used in enterprise cannot join consumer family groups, and Apple's MDM specification lacks any profile payload key to push daily minute quotas per app. Source References Apple Developer Documentation — Screen Time Frameworks Overview Context: Establishes that the Screen Time API entitlement (com.apple.developer.family-controls) requires consumer Family Sharing authorization. Apple Support — Device Management Restrictions for iPhone and iPad Context: Shows that MDM restrictions can block access to Screen Time configuration UI, but cannot programmatically define daily time quotas. Apple Support — Review Device Management Restrictions for Apple Devices Context: Clarifies that Apple treats enterprise configuration profiles and consumer parental controls as completely distinct architectural systems. |
||||||
| Microsoft | Windows 10/11 PC / Laptop |
Azure AD Enterprise | TOR 2.12 | Granular app usage limits are powered by Microsoft Family Safety, which requires personal Microsoft Accounts (MSA) and consumer family groups. It is not natively supported through Azure AD enterprise MDM. | Custom Agent Process Termination: Deploying the endpoint agent to forcefully kill the application process once the quota is exceeded. | |
|
📄 Evidence & Context Operational Explanation: Microsoft Family Safety is architected around personal consumer identities (MSAs) inside a consumer Family Group. Enterprise management via Intune/Entra ID supports data security policies and notification pauses (Quiet Time), but lacks any MDM payload to enforce daily app duration quotas. Source References Microsoft Support — Roles, permissions, and data sharing in Family Safety Context: Documents that Family Safety feature availability relies strictly on consumer Microsoft Accounts organized in a family group. Microsoft Learn — App protection policies overview in Intune Context: Outlines the scope of Intune MAM policies, showing enterprise capabilities focus on data leakage prevention rather than time quotas. Microsoft Learn — Configure Quiet Time Policies in Microsoft Intune Context: Proves Intune's time controls are limited to blocking notification alerts during non-work hours, rather than capping daily usage minutes. |
||||||
| Google ChromeOS / Android Chromebook / Tablet |
Enterprise | TOR 2.12 | Google's Digital Wellbeing and Family Link features are designed for consumer Gmail accounts. Enterprise policies do not natively support setting an 'X minutes per day' quota on individual apps. | IMTLazarus Extension / Agent: Utilizing the extension/agent to block the screen once the quota is hit. | ||
|
📄 Evidence & Context Operational Explanation: Google Family Link daily usage limits and app timers require personal Google Accounts. While Android Enterprise APIs allow admins to block, allow, or force-install apps, there is no enterprise API payload to enforce dynamic daily time quotas on individual applications. Source References Google For Families Help — Set App Time Limits on Your Child's Device Context: Confirms app daily timers are consumer features tied specifically to personal Google accounts managed via Family Link. Google for Developers — Android Management API Reference Context: Provides the complete field list for Android Enterprise policies, demonstrating the lack of any daily usage quota schema. Android Enterprise Help — Pause or Turn On Your Work Profile Context: Shows enterprise time controls are binary schedule toggles (turning off the work profile) rather than granular per-app minute counters. |
||||||
| Google Android Smartphone / Tablet |
Enterprise Enrollment | TOR 2.16 | The Managed Google Play Store does not expose a global MDM policy payload to block all in-app purchases natively. Restrictions are handled via consumer Google Play authentication settings. | Restricting Account Addition: Preventing the addition of personal Google Accounts to the device. | ||
|
📄 Evidence & Context Operational Explanation: Android Enterprise API schemas (enterprises.policies) provide no global flag to disable in-app purchasing across all installed apps. In-app purchase prevention relies on user-level Google Play password/biometric authentication settings or individual developer-implemented Managed Configurations (managedProperties). Source References Google for Developers — Android Management API Policy Reference Context: Confirms the absence of any global policy key within the official Android Management API to block in-app billing across apps. Google Play Help — Require a Password or Authentication for Purchases Context: Verifies that purchase prevention is an account-level setting enforced inside the Google Play client rather than an MDM command. Android Developers — Set up Managed Configurations Context: Shows that app-specific toggles require app developers to manually build app restriction schemas, rather than being an OS-level MDM setting. |
||||||
| Microsoft | Windows 10/11 PC / Laptop |
Azure AD Enterprise | TOR 2.16 | Windows MDM does not expose a granular policy to specifically block 'in-app purchases' dynamically across all applications. Standalone Win32 and UWP applications handle their own payment gateways outside of MDM control. | Store Disabling & WDAC: Disabling the public Microsoft Store and enforcing Windows Defender Application Control (WDAC) allow-listing. | |
|
📄 Evidence & Context Operational Explanation: Windows Configuration Service Providers (CSPs) can disable the Microsoft Store entirely, but cannot intercept or block in-app transactions inside running applications. Win32 apps are permitted to run custom web-based or third-party payment engines (e.g., Stripe) that operate completely outside MDM visibility. Source References Microsoft Learn — Policy CSP - ADMX_WindowsStore Context: Documents store-related CSP keys, showing policies can disable the Store app but cannot granularly block payment calls within running apps. Microsoft Learn — Get Started with the Microsoft Store FAQ Context: Confirms Microsoft Store rules permit desktop Win32 applications to integrate independent payment engines outside Microsoft commerce. Microsoft Learn — StoreContext API Reference Context: Illustrates that store purchasing APIs execute directly between the app process and Microsoft servers, bypassing MDM policy engines. |
||||||
| Apple | Apple macOS Mac |
Any | TOR 2.16 | Unlike iOS, Apple does not support the 'allowInAppPurchases' MDM restriction payload for macOS. Furthermore, macOS applications installed outside the Mac App Store manage their own independent payment gateways completely outside of MDM control. | Gatekeeper & App Allowlisting: Enforcing strict application allow-listing to prevent the installation of unauthorized apps with in-app purchases. | |
|
📄 Evidence & Context Operational Explanation: The allowInAppPurchases payload key in Apple's MDM profile schema applies exclusively to iOS, iPadOS, and visionOS—it is completely omitted from macOS support. Apps distributed directly via Developer ID notarization use custom payment SDKs outside StoreKit, rendering them unmanageable via MDM. Source References Apple Developer Documentation — MDM Restrictions Configuration Profile Keys (allowInAppPurchases) Context: Highlights Apple's explicit OS compatibility matrix, which lists iOS/iPadOS but excludes macOS for the allowInAppPurchases payload key. Apple Support — Device Management Restrictions for Mac Computers Context: Verifies that official macOS deployment payload specifications contain no key for restricting in-app commerce. Apple Developer Documentation — Distributing Mac Apps Outside the App Store Context: Explains Developer ID notarization rules, confirming non-Store macOS software is free to execute custom payment gateways. |
||||||
| Apple | Apple iPadOS / macOS Tablet / Mac |
Any | TOR 2.18 | Apple 'Shared iPad' strictly requires Managed Apple IDs provisioned through Apple School Manager (ASM). Standard unmanaged Apple IDs or generic local accounts do not support dynamic cloud-based multi-user session switching. | 1:1 Deployment or Identity Providers: Utilizing 1:1 deployment models or relying on Entra ID. | |
|
📄 Evidence & Context Operational Explanation: Multi-user session switching and cloud profile synchronization on iPadOS require Managed Apple Accounts. Consumer Apple IDs cannot sign into a Shared iPad, and local Temporary Sessions (Guest mode) do not support persistent cloud syncing. Source References Apple Support — Shared iPad Overview Context: Establishes the hard prerequisite of organization-owned Managed Apple Accounts for multi-user cloud profile switching on iPadOS. Apple Support — Deploy Shared iPad Context: Outlines deployment architecture via ASM/ABM, proving that standard consumer accounts are blocked at the login screen. Apple Support — Use Shared iPad with Managed Apple Accounts Context: Explains that Temporary Sessions delete all local data upon logout, confirming that persistent multi-user sync requires a Managed Apple Account. |
||||||
| Google Android Smartphone / Tablet |
Enterprise Enrollment | TOR 2.18 | Standard Android Enterprise is architecturally designed for a single primary user per device. Native dynamic multi-user switching is restricted to dedicated kiosk scenarios and often disabled by OEMs. | 1:1 Model or Kiosk Mode: Enforcing a 1:1 Device ownership model or utilizing Kiosk mode. | ||
|
📄 Evidence & Context Operational Explanation: Core Android Enterprise deployment models (Work Profile, Fully Managed) rely on a single primary user. Programmatic multi-user creation (createAndManageUser()) is strictly limited to Dedicated Device (kiosk) modes, and OEMs frequently remove or disable the underlying AOSP multi-user UI framework. Source References Android Enterprise Help — Management Solutions Overview Context: Demonstrates that Android Enterprise relies on Work Profiles within a single primary user account rather than OS-level multi-user switching. Android Developers — Manage Multiple Users on Dedicated Devices Context: Shows that programmatic multi-user API calls (switchUser()) are restricted exclusively to Dedicated Device (kiosk/COSU) management modes. Android Open Source Project (AOSP) — Support Multiple Users Context: Highlights that AOSP multi-user UI components are optional overlays that hardware OEMs regularly modify or disable in custom Android builds. |
||||||
| Apple | Apple iOS / iPadOS Smartphone / Tablet |
Any | TOR 2.22 | Apple iOS strictly sandboxes apps and aggressively suspends background execution. Third-party MDM agents are prohibited from globally monitoring keystrokes or screen text inside other local offline apps (like Apple Notes). | Network-Level Safeguarding & Guided Access: Enforcing web-filtering proxies and Single-App Mode during critical offline scenarios. | |
|
📄 Evidence & Context Operational Explanation: iOS sandboxing enforces complete inter-process isolation. iOS lacks global accessibility or screen-scraping APIs for third-party background apps. Furthermore, background execution is strictly suspended shortly after leaving the foreground, preventing continuous keystroke or input logging. Source References Apple Support — Security of runtime process in iOS Context: Validates inter-process isolation, proving an MDM client app cannot access memory or inputs belonging to another app. Apple Developer Documentation — Background Tasks & Execution Limits Context: Documents iOS background suspension rules, showing background apps are paused and prohibited from executing continuous logging threads. Apple Support — Device Management Restrictions for iPhone and iPad Context: Confirms Apple provides no MDM profile entitlement to grant keylogging or screen recording permissions to an agent app. |
||||||
| Google ChromeOS Chromebook |
Enterprise | TOR 2.22 | ChromeOS relies on browser extensions for endpoint monitoring. Extensions are strictly sandboxed to the Chrome browser environment and cannot monitor keystrokes or offline activity inside standalone Android (ARC) or Linux (Crostini) apps. | Container Restriction: Restricting the installation of Android/Linux apps via Google Admin, forcing users to utilize web applications where the Chrome extension has full visibility. | ||
|
📄 Evidence & Context Operational Explanation: Chrome extensions operate exclusively inside browser renderer processes. Standalone Android (ARCVM) and Linux (Crostini) applications execute inside separate virtual machines managed by crosvm. Browser extensions have no visibility or input-hooks inside these independent VM environments. Source References Chromium Docs — Extension System Architecture Context: Proves extensions are confined to web-browser DOM events and cannot hook OS input events outside active browser tabs. Chromium Projects — Running Custom Containers & VMs Under ChromeOS Context: Defines the hypervisor security boundary separating Chrome browser processes from Android and Linux virtual machines. Chrome Enterprise Help — Admin Console Extension & Device Policy Restrictions Context: Shows enterprise extension telemetry APIs collect web events but lack interfaces to monitor VM input drivers. |
||||||
| Google Android Smartphone / Tablet |
Work Profile / BYOD | TOR 2.17 | Android Enterprise Work Profiles prevent the MDM from factory resetting the entire physical device or accessing device-wide GPS location tracking for a global 'Lost Mode', as the MDM only manages the isolated work container. | Work Profile Wipe: Executing a selective wipe to delete only the encrypted work container and managed apps, without affecting the personal side. | ||
|
📄 Evidence & Context Operational Explanation: On BYOD devices, the Profile Owner DPC is confined strictly to the work container. Issuing a wipe command deletes only corporate data (wipeData removes the profile), and admins cannot access global device GPS coordinates or force a device-wide Lost Mode lock. Source References Android Developers — Work Profiles Overview Context: Establishes that IT admins have zero visibility or administrative control over personal profile storage and location permissions. Android Developers — Disallow Factory Reset & Enterprise Wipe Context: Confirms that calling wipe APIs on a personal Work Profile device destroys only corporate keys and container data. |
||||||
| Microsoft | Windows 10/11 PC / Laptop |
Any | TOR 2.17 | Windows natively does not support an MDM equivalent to Apple's 'Lost Mode' (which persistently locks the screen with a custom message and continuously pings GPS) purely through standard OMA-URI commands. | Agent-Based Lock & Conditional Access: Utilizing the IMTLazarus endpoint agent to force a remote screen lock, and leveraging Entra ID to instantly revoke the user's session tokens. | |
|
📄 Evidence & Context Operational Explanation: Apple's EnableLostMode MDM command forces an OS-level lockout, displays custom contact text, and forces background location tracking. The Windows RemoteLock CSP (./Vendor/MSFT/RemoteLock/Lock) executes a standard LockWorkstation() call without persistent kiosk-overlay lockouts or background location streaming capabilities. Source References Apple Developer Documentation — MDM Command (EnableLostMode) Context: Documents Apple's dedicated protocol command that locks the UI, displays contact info, and forces GPS location reporting. Microsoft Learn — RemoteLock CSP Context: Shows that the Windows MDM lock payload merely triggers the standard OS lock screen rather than a specialized lost-mode UI. Microsoft Learn — Device Action: Locate Device in Intune Context: Clarifies that Windows location queries depend on standard location services being enabled and active network connectivity. |
||||||
| Apple | Apple macOS Mac |
Any | TOR 2.17 | 'Lost Mode' is an iOS/iPadOS specific MDM feature. While macOS supports 'Remote Lock' (firmware PIN lock), it does not natively support the continuous GPS-pinging 'Lost Mode' payload. | Remote Lock & FileVault: Executing a standard Remote Lock combined with FileVault encryption to ensure data on the missing Mac is completely inaccessible. | |
|
📄 Evidence & Context Operational Explanation: Managed Lost Mode (EnableLostMode) is exclusive to supervised iOS/iPadOS/Mac Catalyst runtimes. On macOS, enterprise MDM utilizes DeviceLock, which sets a 6-digit firmware/system lock requiring a local PIN to unlock. Because system execution halts at the firmware level, continuous background location pings cannot take place. Source References Apple Support — Lock and locate Apple devices Context: Defines the operating system scope of Managed Lost Mode, explicitly limiting continuous GPS tracking to supervised iOS/iPadOS. Apple Support — Managed Lost Mode and remote wipe Context: Explains that locking a Mac via MDM issues a 6-digit PIN lock that stops the OS until the hardware PIN is validated locally. Apple Developer Documentation — EnableLostMode MDM Command Reference Context: Verifies in the developer specification that the EnableLostMode command payload is unsupported on macOS. |
||||||
| Google ChromeOS Chromebook |
Managed Guest Sessions | TOR 2.22 | In ChromeOS Managed Guest Sessions (and Ephemeral User modes), the OS natively destroys all local user data and extension storage immediately upon logout or reboot. Any offline telemetry queued locally during a disconnected session is permanently wiped by the OS before it can synchronize if the session ends prior to network reconnection. | Persistent 1:1 Enrollment: Utilizing persistent user profiles (1:1 deployment) where local storage is preserved across reboots, or accepting localized data loss as a strict security feature of ephemeral shared sessions. | ||
|
📄 Evidence & Context Operational Explanation: Managed Guest Sessions and ephemeral profiles rely on transient, unpersisted mount points managed by the cryptohomed daemon. When a session ends via logout or reboot, the local user directory is immediately unmounted and wiped, irrevocably destroying any offline telemetry queued in local storage before it can sync over the network. Source References Chrome Enterprise & Education Help — Managed Guest Session Overview Context: Confirms that ending a managed guest session triggers an automatic, total deletion of all local storage and extension data. Chrome Enterprise Policy Reference — DeviceEphemeralUsersEnabled Context: Outlines the policy mechanics forcing ChromeOS to wipe the local user partition completely upon session sign-out. Chromium Docs — Cryptohome & Ephemeral User Architecture Context: Explains the low-level cryptohome unmount process, proving unsynced local data cannot survive session teardown. |
||||||
| Apple | Apple iOS / iPadOS Smartphone / Tablet |
Any | TOR 2.22 | Apple iOS aggressively suspends background apps and does not automatically wake them upon network reconnection. If a user force-closes the app, or the OS suspends it, offline logs cannot instantly synchronize in the background until the user manually launches the app or a remote push notification wakes it. | APNs Wake & Foreground Enforcement: Utilizing Apple Push Notification service (APNs) to remotely wake the app, or using MDM Single-App Mode to enforce foreground execution during critical exam scenarios. | |
|
📄 Evidence & Context Operational Explanation: Swiping up to force-close an app sets a system-level flag that prohibits iOS from waking or launching the app for background execution or background tasks (BGTaskScheduler). Reconnecting to a Wi-Fi or cellular network does not trigger a background app wake; synchronization must wait for a manual user foreground launch or an incoming APNs push message. Source References Apple Developer Documentation — Configuring background execution modes Context: Details the iOS application state machine, demonstrating that suspended apps cannot execute background network sync loops. Apple Developer Forums — Official Apple DTS Guidance on Force Quit & Background Tasks Context: Provides official Apple Developer Technical Support confirmation that force-quitting sets an OS flag blocking all background task launches. Apple Developer Documentation — Using background tasks (BGTaskScheduler) Context: Establishes that network reconnection events do not act as automatic background execution triggers for suspended iOS applications. |
||||||