Privacy-First Mac Auto-Lock: Why On-Device Detection Matters

When your Mac locks because you stepped away from your desk, the question is not just "did it detect me?", but "where did that detection happen?". The architecture behind auto-lock detection shapes what you are trusting with your privacy. This guide explains three common patterns and what on-device really means.

Three Architectures for Auto-Lock Detection

Mac auto-lock apps solve a common problem in different ways. Each approach makes different privacy and security trade-offs, and understanding them helps you choose the tool that aligns with your comfort level.

On-Device Vision

In this pattern, your Mac's built-in camera processes frames locally using computer vision. The app asks: "Is a face in front of the camera right now?" The answer stays on your device. No frames are sent anywhere. No account is needed. Nothing happens outside your Mac.

This is the simplest privacy model. Your camera feed and any processing results remain entirely local. The app observes the camera stream, makes a decision, and discards the frame. If the process ever fails or the service closes down, the app still works because it has no dependency on a remote server.

Bluetooth Proximity

Some apps use your Apple Watch (or other Bluetooth device) as a proximity signal. The app periodically checks the signal strength (RSSI, or "received signal strength indicator") between your Mac and watch. If the signal weakens, you have probably walked away. If it strengthens again, you are back.

This approach has a natural limitation: it requires a paired Bluetooth device and it cannot distinguish between you stepping away and your watch moving into another room. It also works best when your watch is with you. However, Bluetooth signal checking is entirely local (the Bluetooth radio is in your device) and does not send data elsewhere unless the app itself sends it.

Cloud-Based Detection

In this model, frames or metadata are sent to a cloud service. The server processes the vision task or stores a record of your presence. A typical setup works like this: your camera feed is encrypted and uploaded to a company's servers, where a machine learning model identifies faces or recognises you. The result is sent back to your Mac, which then locks.

This pattern centralises processing power (servers can run more complex models than your Mac) and can enable features like "recognised my face" rather than just "is a face present". It also requires an account, terms of service, privacy policies, and trust in the company handling the data. Your camera frames are in flight and at rest on someone else's infrastructure.

What "On-Device" Really Means for Peeku

Peeku uses on-device vision detection. Here is what that means in practice and what does not leave your Mac.

What Stays Local

• Camera frames. Every frame captured from your camera is processed by your Mac's Vision framework, which is a local Apple library. The frame is never written to disk and is never sent to any server.
• Face presence decision. Peeku asks: "Is a face in this frame?" The answer (yes or no) is computed locally and stays on your Mac.
• All lock decisions. When you arm auto-lock, the decision to lock your screen is made by a process running on your Mac, checking local signals.
• No account requirement. Peeku does not need you to create a Peeku account, sign in, or prove your identity to any service. You download it and run it.
• No network traffic for detection. The core job (determining whether you are at your desk) does not send any data over the network.

What Is Stored Locally (And Honestly)

Peeku does store something on your Mac: mathematical feature vectors from your face. These are not photos. They are numerical representations (arrays of numbers) that encode the visual characteristics of a face. They are stored in a plain-text file (not encrypted), and they are the only thing Peeku uses to match your face against the live camera signal.

This is important to be honest about. Feature vectors are not reversible into a picture (they cannot be "decoded" back to a photograph), but they are also not encrypted or locked behind a password. The threat model: if someone gains access to your Mac's home directory, they could read these vectors. The broad defence against anyone reading files off a Mac they physically hold, this file included, is FileVault full-disk encryption, which a lock screen alone does not provide. However, the vectors alone are not useful (they only mean something within the context of Peeku's comparison algorithm).

What You Can Verify

You do not have to take Peeku's word for it. You can independently verify that on-device processing is happening.

Why On-Device Detection Matters

The difference between on-device and cloud-based detection is not just technical. It has real consequences for what risks you are taking.

Resilience. If a cloud service goes down or the company shuts down, cloud-based detection stops working. On-device detection continues to work because it has no dependency on external infrastructure.

Minimal data collection. Cloud architectures, by definition, move data to a server. Even with encryption in transit, this creates a stored record. On-device processing never creates a log of when you were at your desk. There is no history to be breached, sold, or subpoenaed.

No account lock-in. Services that require accounts create switching costs. You need to delete your account, understand their data retention policies, and trust they actually delete your data. On-device apps do not have accounts, so there is nothing to delete and no service to tie you to.

Transparency. On-device processing is easier to verify. You can see your camera light turn on and watch your network traffic. Cloud processing is inherently harder to audit because the key work happens on servers you do not control.

Honest Limitations of On-Device Approach

On-device detection is not a universal win. It has trade-offs.

• Device-dependent computation. Your Mac must be powerful enough to run vision processing in real time. Older or less capable Macs might struggle. Cloud services can use specialised hardware and larger models, potentially achieving higher accuracy.
• Feature vector storage. As mentioned, face feature vectors are stored unencrypted on your Mac. If you are in a high-threat environment (shared device, untrusted users with physical access), this is a real consideration.
• Simpler matching. On-device processing typically uses simpler matching (is a face present, is it you?) rather than complex analysis (mood detection, precise identity verification). If you need sophisticated features, cloud services might be the only option.

Choosing an Auto-Lock Approach

There is no single "best" architecture. Your choice depends on your threat model and priorities.

Choose on-device detection if you prioritise privacy, want to avoid accounts, prefer not to send your camera feed anywhere, or work with sensitive information and want minimal data trails.

Choose Bluetooth proximity if you prefer simplicity, trust your Apple Watch as a signal, and do not want camera processing at all.

Choose cloud-based detection if you want the most accurate matching, are willing to trade privacy for convenience and advanced features, or work in an environment where centralised account management is required.

How Peeku Implements Privacy-First Detection

Peeku uses Apple's Vision framework to run face presence detection on your Mac. The framework is part of macOS; it is not a third-party dependency. Frames are processed in real time and immediately discarded. The only persistent data is your optional face enrolment vectors, which are stored locally. If you ever decide to remove Peeku, you can delete those vectors and every other file it created.

Peeku does not require a Peeku account, a cloud sync service, or any network call during normal operation. You can download it, install it, and run it completely offline. If you choose to enable remote lock control via the iPhone companion, that communication is direct to your Mac (not routed through Peeku servers).

The full auto-lock version ships outside the Mac App Store (via Gumroad or direct DMG download) because macOS sandboxing would prevent the on-device lock command from working. The App Store sandbox blocks access to ScreenSaverEngine and system-level APIs, so any app in the sandbox (no matter how privacy-conscious) cannot implement real auto-lock. The coaching-only App Store version offers wellness reminders and desk health tracking instead.