Sign inDeveloper & IT Documentation
Technical architecture, security posture, compliance, and rollout guidance — written for whoever at your company needs to evaluate or deploy MIRA, not for end users.
Overview
MIRA is a B2B focus/distraction-blocking product built around physical NFC tags. An employee taps a tag (or a MIRA Button hub) to start a focus session, which blocks distracting apps and sites on their own devices for the duration of the session — syncing in real time across their devices. Company admins manage their roster and see privacy-preserving usage analytics from a web dashboard — org-wide aggregates, plus a per-member view built only from sessions employees mark Work. Sessions marked Personal are never visible to any admin, individually or in aggregate, regardless of which device they happened on.
Native apps
iOS and macOS apps are shipping. Windows and Android apps are feature-complete for blocking but still in beta — see platform support.
Admin dashboard
This web app — roster management, aggregate analytics, billing, and this documentation.
Getting started
- 1. Buy your MIRA cards — this sets up your company account and admin access.
- 2. Invite your team from the dashboard (individually or by pasting a list).
- 3. Need more cards later? Add them anytime from Settings → Billing.
- 4. Each employee opens the MIRA app and signs in with the email you invited.
- 5. Tap a tag (or the MIRA Button) to start a focus session.
Platform support
Current state of the native apps, by platform. This page is updated as each platform ships.
"Beta" means app- and website-blocking are fully built and have been verified on real hardware, but distribution isn't enterprise-ready yet: no signed Windows installer, no Android Play Store / Managed Google Play listing, and the browser extension isn't published to the Chrome Web Store yet either — none have been validated against a managed/MDM fleet. Rolling out on a mixed OS fleet today? Employees on iOS/macOS get the smoothest experience now; Windows/Android/ browser-extension users can pilot the beta builds directly — see the caveats in how blocking works.
How blocking works
MIRA uses each platform's own native content-control framework rather than a general traffic-decrypting proxy — it never inspects, logs, or reroutes the content of your connections. iOS, macOS, and Windows do this with no VPN component at all. Android's website blocking is built on Android's own VpnService API, so Android will show its standard system VPN icon while a focus session is active — see the Android note below for exactly what that does and doesn't mean.
- iOSApple's Screen Time / Family Controls framework (
ManagedSettingsStore,DeviceActivityMonitor) — the same system framework Apple's own Screen Time feature is built on. - macOSTwo separate mechanisms. Website blocking uses a Network Extension Transparent Proxy (
NETransparentProxyProvider) that intercepts the connection at the OS level to read the destination hostname and blocks or relays it — it does not decrypt, log, or forward traffic anywhere. App blocking is a separate, non-Network-Extension mechanism: it watches app launches/activations viaNSWorkspaceand force-quits matches — a detect-and-kill approach, since Apple's Family Controls-style "can't even launch it" shielding is iOS-only and has no native macOS equivalent. - WindowsTwo separate mechanisms. App blocking (
ProcessBlocker) polls running processes every 1.5s and terminates matches against the blocklist — a detect-and-kill approach, not a preventive one. Website blocking (WebsiteBlocker) is built on WinDivert, a kernel-mode packet filter: it reads only the unencrypted TLS ClientHello's SNI hostname field on port 443 traffic and either forwards the connection or sends a TCP reset — it never decrypts or inspects the connection content itself. - AndroidTwo separate mechanisms. App blocking uses
UsageStatsManagerto detect the foreground app and shows a full-screen overlay when it's blocked — no Accessibility Service or Device Admin permissions involved. Website blocking runs a realVpnServicethat routes traffic through a local, on-device SOCKS5 proxy, which reads the TLS ClientHello SNI the same way Windows does and relays or drops the connection accordingly — traffic is never sent to a remote server, decrypted, or logged. - Browser extensionA Manifest V3 Chrome/Edge extension ("MIRA Focus") using
chrome.declarativeNetRequestdynamic rules — page loads to a blocked domain redirect to a branded block page; background requests (XHR, media) are simply refused. Website blocking only — a browser extension is sandboxed and architecturally cannot see or control other applications, so it's a complementary layer alongside the OS-level app blocking, not a replacement for it.
Known open items (Windows):
- Website blocking is incompatible with HVCI / Memory Integrity when enabled — the app detects this and reports a clear error rather than failing silently, but the underlying conflict isn't resolved.
- The installer isn't Authenticode-signed yet, so Windows SmartScreen may warn on first run as an unrecognized publisher.
- App blocking is poll-based (up to a 1.5s window) and can be bypassed by renaming the blocked executable — a known, accepted limitation rather than a bug.
Known open items (Android):
- Android allows only one active system VPN at a time. If another app already holds the device's "Always-on VPN" slot (a corporate VPN, for example), website blocking can't also run — the app detects this and tells the user clearly; app blocking keeps working regardless.
- Aggressive OEM battery management (notably Samsung's "Sleeping apps") can interfere with background reliability on some devices.
- Not yet tested against a managed/MDM Android environment.
System requirements
Which phones can tap an NFC card
Having an NFC chip isn't the same as being able to tap-and-trigger a session — that needs background tag reading, a narrower bar. Employees on anything below these don't need a card at all; the app works the same either way, they'd just start/stop sessions manually.
iPhone
iPhone XS or later, iOS 13+. Every iPhone released since 2018 qualifies — this is a background-reading capability gap, not an NFC-chip gap (the 7 and later have the chip, but can't trigger a tap without the app already open).
Android
No clean single cutoff — NFC has been standard above budget tier since ~2017. Reliable reference points: Galaxy A22 or later, Galaxy S8 or later, Pixel 3 or later, OnePlus 6T or later, Moto Edge/Moto G Power 2020 or later.
Data & privacy
This is enforced by what the dashboard's server code is able to read — not a setting that can be turned off. The full breakdown lives in our Privacy Policy; the short version:
Admins can see
- Aggregate focus hours across the whole team
- Adoption and active-usage rates
- Department breakdowns — shown once at least one member has been assigned a department
- A per-member view (focus hours, session count, consistency) — built only from Work sessions
- Whether a member has been active recently (last Work-session date only)
Admins never see
- Raw session-by-session history or timeline for any named person
- What anyone did during a session, or which specific apps/sites they opened or were blocked from
- Anything about a session marked Personal — individually or in aggregate
Only sessions marked Work ever contribute to any admin-visible number, individually or in aggregate. That choice is made per session, in the app, before it starts — not tied to which device you're using. Sessions marked Personal never contribute anywhere, regardless of device.
Retention & deletion: account and roster data is retained for as long as your organization is active. To request export or deletion of your organization's data — including on employee offboarding or account closure — email hello@tapmira.com.
Security
- Authentication runs on Firebase Auth. Admin sessions use short-lived, httpOnly session cookies — credentials are never stored in the browser.
- Every organization's data is isolated by server-side security rules — one company's admin cannot read another company's data, enforced at the database layer, not just in the UI.
- All traffic (dashboard and native apps) is encrypted in transit via TLS, and encrypted at rest by the underlying cloud infrastructure.
- No third-party advertising trackers or analytics SDKs are embedded in the product.
- Found a security issue? Email hello@tapmira.com with details — we treat security reports as priority and will respond directly.
Compliance & sub-processors
MIRA is an early-stage product and is upfront about where things stand: we are not yet SOC 2 or ISO 27001 certified, and have not yet undergone a third-party penetration test. Both are on the roadmap as the company grows. A data processing agreement (DPA) is available on request.
Primary data storage (Firestore) currently runs on Google Cloud's US multi-region infrastructure. Company/roster data is not currently stored in an EU-only region — if that's a hard requirement for your organization, email us before signing up so we can advise.
Calendar & Slack integration
Company Focus Blocks — recurring focus time an admin schedules from the dashboard that blocks off time directly on employees' calendars — needs each employee to individually connect their own Google or Microsoft calendar from the MIRA app. That's a separate, per-person grant; nothing an admin does connects anyone else's calendar. What an admin's own action can do is remove friction from that per-person step, which differs by provider:
Microsoft
Without any setup, an employee connecting an org-managed Microsoft/Outlook calendar will often hit "this app needs admin approval" and get stuck. Your Microsoft/Entra admin can clear this for everyone at once: open the dashboard's Focus Blocks page and click "Approve for your company." That sends the admin to a Microsoft page for a one-time, org-wide approval — it connects no one's calendar itself, it just means employees stop seeing that wall afterward.
No admin action needed or available — every employee can connect their own Google Calendar directly. Google has completed its standard app verification for this scope, so there's no "Google hasn't verified this app" warning to click through — the consent screen goes straight to MIRA's own branded permission request.
Slack works differently from either calendar provider — no admin action needed or possible. Each employee can connect their own Slack account from the MIRA app to automatically set their Slack status (e.g. "Focusing") while a session is active — a personal, one-click connection, the same as installing any public Slack app.
IT deployment
On managed fleets, macOS System Extensions typically need to be explicitly allow-listed by MDM before they can activate. Use the identifiers below:
M87GY63Y6Rcom.miradial.mira.MiraNetworkFilterWindows: ships as a self-hosted Inno Setup installer (not MSIX/Store-packaged), so it isn't something a store-based MDM policy can push directly. Install requires local admin (one UAC prompt) and sets up a Windows service plus the WinDivert kernel driver. The installer supports Inno Setup's standard /VERYSILENT unattended flag for scripted rollouts, though that path hasn't been explicitly hardened or tested yet. Identifiers to allow-list:
{A6F1B9D2-3C4E-4F5A-9B1C-2D3E4F5A6B7C}MiraWindows.exe, MiraWindows.Service.exe%ProgramFiles%\MIRA\MiraWindowsService, WinDivertAndroid: the package identifier is com.miradial.miraapp. A release-signing key is now configured for Play Store uploads, but there is no Play Store or Managed Google Play listing yet — it isn't deployable via standard Android MDM today. Treat this as pending, not available.
Browser extension: not yet published to the Chrome Web Store — currently "Load unpacked" (developer mode) only, so it can't be force-installed via Chrome/Edge enterprise policy yet either. Requested permissions are storage, alarms, declarativeNetRequest, tabs, notifications, identity (for the optional personal-calendar-read feature), and sidePanel (for the extension's UI), plus host access limited to Firebase/Google API endpoints and MIRA's own dashboard domain (app.tapmira.com) — no broad <all_urls> access is requested by default (a *://*/* optional host permission is requested at runtime only for domains the user explicitly adds to their own blocklist). One thing worth flagging to IT specifically: the site blocklist is configured locally per browser install today, not centrally pushed by admins — enterprise policy support (chrome.storage.managed) is a known gap, not yet built.
Network requirements: MIRA does not require any special firewall allow-listing for its own blocking behavior. The apps do need outbound HTTPS access to Firebase/Google Cloud endpoints (for sign-in and syncing focus sessions) — Windows additionally checks GitHub's release-asset host for app updates. If your network already allows general HTTPS traffic to Google-operated domains, no extra configuration is needed.
Identity & provisioning: MIRA currently uses its own email/password accounts (Firebase Auth). SSO/SAML and SCIM-based provisioning are not yet supported — admins invite and manage members directly from the dashboard.
Supported locales in the product UI: English and Estonian today, with Finnish, Swedish, Latvian, and Lithuanian translated and ready to re-enable. Card shipping is currently EU-only.
FAQ & troubleshooting
Does MIRA work alongside our corporate VPN or EDR software?
In most cases yes, but this hasn't been formally validated against every VPN/EDR product — see the callout in "How blocking works." Pilot with a small group first if your fleet runs one.
What happens if an employee's device is offline?
Blocking is enforced entirely on-device, so it keeps working without a network connection. Focus session state syncs to the dashboard as soon as connectivity returns.
Can an employee just uninstall the app or disable blocking?
Yes — MIRA is not an MDM-enforced lock. It's a focus tool employees opt into, not a surveillance or restriction system admins force onto personal devices.
What data do we lose if we cancel or an employee leaves?
You can export your roster and aggregate analytics at any time from the dashboard. Email hello@tapmira.com to request full account/data deletion.
Does MIRA see or store the content of blocked sites or messages?
No. MIRA blocks at the app/domain level using each OS's native controls — it never inspects, decrypts, or logs traffic content, on any platform.
We're on a mixed fleet (some Windows, some Mac, some Android). Can we roll out now?
Yes — invite everyone today. iOS/macOS get the most mature experience; Windows and Android are in beta with working blocking but rougher edges (see the callouts in "How blocking works") — worth piloting with a small group first on those platforms.
Why does my phone show a VPN icon when MIRA is blocking sites?
On Android, website blocking is built using Android's own VpnService API, so the OS shows its standard VPN status icon whenever it's active — that's how Android labels every app using that framework, regardless of what it does. Nothing is routed to a remote server; the connection is inspected locally on the device to check the destination, then relayed straight out. Windows, iOS, and macOS don't use a VPN component at all.
Support & contact
MIRA is a small, hands-on team — every support request is read and answered by someone who works on the product, not a ticketing queue. There is no public status page yet; if something looks wrong, email us and we'll tell you directly what's going on.