Platform Permissions, Automation and Compatibility Notice

Last updated: 16 September 2026 FaceCards needs different technical permissions on different platforms. This notice explains what those permissions enable, their limits and the safety implications of automated input. 1. General principle FaceCards requests permissions to perform a user-selected controller function. Granting a system permission does not give FaceCards permission to use it for unrelated purposes. You can revoke permissions through your operating-system, browser or extension settings, although affected features may stop working. 2. Camera permission Camera permission allows live on-device gesture recognition and calibration. Raw camera frames are not intended to be uploaded to the FaceCards backend. Camera permission should only be active when you start a camera-based FaceCards function. 3. Desktop keyboard and mouse control A supported desktop app may send keyboard and mouse events to the currently focused application. This allows generic control of applications such as flashcard software without reading the deck. The focused window can change. You must check the active application before starting live control because the same keystroke can have a different effect in another program. 4. Desktop updater, autostart and global controls Released desktop builds may use signed update checking, tray/global-shortcut functionality and optional autostart-related capabilities. These functions are intended to keep the controller operable and provide an immediate start/stop route. Exact permissions depend on the operating system and released build. 5. Browser extension permissions Chrome/Edge/Firefox-style extension builds may use extension permissions such as storage, activeTab, scripting, tabs and alarms, with optional website host permissions. A host permission allows the extension to run FaceCards control code on the permitted site. FaceCards is designed to request optional site access when you choose to start or map a site rather than treating permission as authority to collect the site’s contents for unrelated purposes. The extension may inspect the page structure needed to find and activate a mapped control. Its stored mapping is intended to contain a technical locator/label rather than a copy of your flashcard content. 6. Android Accessibility Service For global control of other Android apps, FaceCards may ask you to enable an Android Accessibility Service. Android grants this service powerful capabilities, including the technical ability to retrieve active-window content, report view identifiers, create an accessibility overlay and dispatch gestures. The current FaceCards implementation uses this capability for deterministic user-defined control: tapping mapped points/regions, swiping, scrolling the active window and selected global navigation actions. It is not intended to upload or store the text/content of the active third-party window. Because Accessibility Service is a sensitive Android capability, a Google Play build that is not distributed as an eligible accessibility tool must provide the required separate prominent in-app disclosure and affirmative consent before the user is directed to enable the service. That disclosure must explain the Accessibility Service data/capabilities used for FaceCards’ control function; this public notice or the Android settings screen is not a substitute for the required in-app disclosure. The operating-system settings screen remains the place where you enable or disable the service. 7. Android camera foreground service Android global tracking may use a foreground service with camera access so gesture recognition can continue while you switch to another app. The service is intended to display the ongoing system notification required for that mode and to stop when you stop global tracking. 8. iPhone and iPad limits iOS/iPadOS does not permit FaceCards to inject unrestricted controls into every arbitrary native app. FaceCards therefore uses supported paths such as its own in-app browser and Safari extension/integration surfaces where released. Do not rely on marketing material implying universal iOS app control if the operating system does not permit it. 9. Screen-region mapping FaceCards may let you draw or configure normalised screen regions for different device/orientation layouts. The saved mapping is coordinate/configuration data; the current backend does not need a screenshot of the target app to store the region. Mappings are intentionally separate for phone portrait, phone landscape, tablet portrait, tablet landscape and computer landscape because control positions can change. 10. Direct actions and adapters Some released integrations may expose a limited set of direct actions. An adapter does not imply endorsement or partnership. Third-party APIs and interfaces can change or be withdrawn. 11. Compatibility is conditional Compatibility depends on device hardware, camera, browser, OS version, app version, window layout, third-party UI and permissions. A previously working mapping can stop working after a third-party update. Use the free trial where available to test your intended setup before purchase. 12. Safety rule Never enable live automated input in a high-consequence context where an accidental action could cause serious harm. Stop FaceCards before entering passwords, confirming payments, changing security settings, controlling machinery or performing other sensitive actions unless you have independently ensured the mapping cannot act there. 13. Third-party terms You remain responsible for complying with the target app/site’s terms and institutional rules. FaceCards does not authorise conduct that a third party or the law prohibits. 14. Permissions and privacy Details of personal data associated with permissions, devices, mappings and calibration are in the Privacy Policy and Cookie, Browser and Device Storage Notice. 15. Contact Platform-permission questions: facecardssupport@gmail.com