Privacy claims become useful when you can test them during a normal workday. Before you bring a desktop tool into client work or research, open a document, disconnect the network, make a change, pair a second device, and remove that device again. Watch what the product does at each step. Does the document remain available?
Does the app explain which data it sends? Can you choose the receiving device? Does revoking a device stop future requests without deleting your local copy? Can you tell whether a failed transfer left a complete file or a pending record?
These observations give you a stronger privacy review than a sentence in a marketing page. The checklist below follows the order in which a real project crosses boundaries.
Start with the working copy
Find the place where the app keeps the data you are editing. The location can be a local database, a folder of files, or an application-managed store. You do not need the vendor’s internal schema to answer the question. You need to know whether the app can open the item after the network disappears.
Open a recent item while offline. Search for a phrase you saw earlier. Make a small edit. Close the app.
Open it again. If the edit survives, the device holds a working copy. If the screen turns into a sign-in prompt, the product may keep only a remote projection. That distinction affects travel, outages, and incident response.
Ask about completeness
Some products store a title and thumbnail locally while they leave the body on a server. That can be a sensible choice for a large video or archive. The interface should call the item pending rather than ready. Check whether you can see the size of the missing body.
Check whether a Download action starts an explicit task. Check whether the task reports progress. Check whether a partial transfer stays hidden from actions that require complete bytes. Those details tell you which content crossed the boundary and which content did not.
Check local protections
A local copy needs the same care as any other sensitive file. Turn on operating-system disk encryption. Use a login that locks the device when you step away. Review which applications can read the data directory.
Keep backups under a policy that names their retention period. Ask whether exports include hidden metadata. Local-first design gives you ownership of the copy. It does not make an unlocked laptop harmless.
Find the moment synchronization starts
Watch the first action that moves data away from the device. It may be a Pair button, a Share command, a background rule, or a provider integration. Record what the app shows before you confirm. The confirmation should name the target.
It should name the content scope. It should name whether the operation includes metadata, full content, or both. It should show a route or a transport status while the operation runs. An app that cannot describe its own transfer boundary makes it hard to review.
Test automatic and manual modes
Copy a small text item and a large file. Put a second device into an automatic mode. Observe which item arrives without another tap. Switch the device to on-demand mode.
Repeat the test. The small item may arrive as a header and the large file may remain pending. That behavior lets you keep a project archive on a workstation while you carry a phone with limited storage. The setting should affect transfer policy, not trust.
Changing the mode should not silently add a new device to the trusted set.
Check metadata separately
Titles, tags, filenames, and preview dimensions reveal less than a full document, but they can still identify a project. Ask whether those fields move before you request the body. Ask whether a pending item appears in search on the receiving device. Ask whether tag edits propagate while the body remains pending.
The answer helps you model the information boundary. You can decide that a project name should stay on one device even when a selected note can travel to another.
Identify the authorizing identity
A device name helps you recognize a peer. It does not authorize the peer by itself. Look for an identity that the pairing flow verifies. Confirm the identity on both screens before accepting.
Name the device after you verify it. Check the scope shown in the confirmation. Open the paired-device list after the operation. You should find a record that you can revoke.
Separate trust from route
The network path answers how two devices exchange encrypted frames. The pairing relationship answers whether they may exchange them. A local network can carry an untrusted device if you did not authorize it. A relay can carry an encrypted session for a trusted device.
A VPN address can carry a direct session even when the devices sit in different places. Do not infer trust from an IP range. Read the selected route and the paired identity as separate fields.
Verify revocation
Remove a test device from the paired list. Try to request a new item from that device. The request should fail with an authorization state. Open the original device.
Confirm that its local history remains. Pair removal changes future access. It should not silently erase a copy that you still own. If a product combines revocation and deletion in one button, ask which copies it removes.
The confirmation should leave no ambiguity.
Inspect the transport path
Network privacy depends on more than encryption. You also need to know which path carries the session and where the product records failures. Open the device network summary while a transfer runs. Look for the selected route, selected remote address, selected local address, and connection reuse.
Open detailed diagnostics when a task takes longer than expected. The useful timeline includes discovery, probing, handshake, queue wait, transfer, persistence, and UI refresh.
Direct and relay have different meanings
Direct means the peers exchange session frames without a relay hop. It does not mean the peers share a room or a Wi-Fi network. Relay means an intermediary forwards the encrypted session. It does not mean the intermediary can read the payload.
The product should label the selected result rather than guess from an address prefix. This matters on VPNs and carrier networks.
Read slow timings as stages
A 100 millisecond network RTT can coexist with a four-second sync. The queue may wait behind another task. The connection may retry after a candidate timeout. The receiver may write a large file to slow storage.
The interface may render a state after persistence completes. Ask for stage timings before blaming the network. A diagnostic record that contains only a total duration cannot tell you which boundary needs attention.
Check connection reuse
The first transfer can pay for discovery and handshake. Later transfers should reuse a healthy connection when the peer remains available. Watch the reuse field across two small operations. If each item creates a new session, the app may spend more time setting up than moving data.
If a stale session remains marked healthy, retry timing can become misleading. The product should remove failed connections from the reusable pool and record the replacement attempt.
Review third-party access
Extensions, integrations, and helper applications can widen a data boundary. List the integrations you enabled. Read which content they can request. Check whether the integration receives a rendered copy or the original source.
Turn one integration off. Confirm that local preview and search still work. The app should not require a broad integration permission for a narrow operation.
Treat clipboard access as sensitive
A clipboard tool can see content that never becomes a saved document. Review when the tool samples the system clipboard. Check whether it ignores passwords or private windows when the platform provides that signal. Check the retention count and retention time.
Check whether Trash has a separate policy. Check whether a plugin can read all history or only the selected item. The best default keeps the history local and makes sharing explicit.
Review AI and OCR boundaries
OCR may send an image to a configured provider. Translation may send extracted text. An AI operation may send a selected excerpt, a whole item, or metadata for suggestions. The action should identify the provider and the input scope before it starts.
The output should become a new snapshot instead of overwriting the original. That arrangement lets you delete the derived text without losing the source image. It also lets you review an AI suggestion before saving a tag or edit.
Understand deletion and recovery
Test deletion before you import sensitive material. Move a sample item to Trash. Confirm that it leaves the active list. Restore it.
Confirm that its tags and preview return. Delete it forever. Check whether search removes it. Check what happens on a paired device.
The product should tell you which copy each action changes.
Separate Trash from retention
Trash is a user-visible state. Retention is an automated policy. A retention rule can remove eligible Trash items after a count or time limit. It should not silently remove active history.
The settings page should show the current limit. The confirmation should say whether the operation is recoverable. If your organization needs legal hold or external backup, keep that policy outside the application and document the handoff.
Check deletion propagation
Delete a test item on one paired device. Observe the metadata state on the other device. The receiver may get the deletion before it owns the body. It may also remain pending while the peer is offline.
The product should show that delay rather than implying that all copies disappeared at once. This detail matters when a device is asleep during a retention window.
Verify recovery after failure
Disconnect the network during a large download. The local item should remain either pending or syncing. It should not become a ready file with missing bytes. Reconnect the network.
Retry the task. Check whether the queue avoids a duplicate history item. Open diagnostics and compare the failed and successful timelines.
Look for bounded retries
A retry policy needs a limit. Short control retries can recover a transient packet loss. Long connection timeouts should not repeat forever. The UI should show the attempt count and the next action.
An item that waits for an invisible retry loop can consume battery and data without helping the user. Bounded work also gives support a useful record.
Check foreground behavior
Start a large background download. Open the command palette. Select a ready local item. Press Enter or Copy.
The foreground action should complete without waiting for the unrelated download. If the selected item is pending, the command should say that it needs materialization. This test connects privacy and usability: a blocked command can push a user toward an unsafe workaround.
Inspect diagnostics before sharing
A diagnostic report should help support without becoming a second data leak. Copy the summary mode first. Confirm that it contains no clipboard text, document body, API key, or session token. The summary can include route class, peer correlation id, timing fields, byte counts, and final state.
Raw mode can include local and remote addresses when a network administrator needs them. Review the raw report before sending it outside your team.
Make the report reproducible
Record the operation time. Record the device role. Record whether the device used Wi-Fi, a carrier network, or a VPN. Record the selected route.
Record whether the connection was reused. Record the final state. Avoid adding a screenshot that exposes unrelated history. The report should describe the failing operation, not the entire workspace.
Use diagnostics to ask a better question
“Sync is slow” gives a support engineer little to test. “The selected direct route reports 90 ms RTT, connection reuse is true, queue wait is 3.8 seconds, and persistence is 120 ms” gives them a concrete lead. “The route changes to relay after two five-second connection attempts” points to a different class of problem. Good diagnostics reduce the need to send private content for reproduction.
A five-question review
Use these questions before approving a desktop tool.
1. Where does the working copy live?
Open recent work offline. Make a change. Reopen it. Name the local protection and backup policy.
2. What starts a sync?
Find the action or rule. Check the content scope. Check automatic and manual behavior. Check whether large content can remain pending.
3. Which identity authorizes another device?
Verify the pairing identity. Name the device. Confirm the scope. Revoke it.
Test a future request.
4. What does delete mean?
Try Trash. Try Restore. Try Delete forever. Check retention.
Check propagation.
5. Can you recover without guessing?
Interrupt a transfer. Retry it. Read the diagnostic timeline. Use a ready local item while the transfer runs.
These tests fit into one afternoon and reveal the boundaries that a product description often skips.
FAQ
Does encryption answer every privacy question?
No. Encryption protects content in transit or at rest, but you still need to know which device is authorized, which fields move, and what the service retains.
Is a relay a privacy failure?
Not by itself. A relay can forward an encrypted session without reading the payload. The product should show when it selected a relay and should keep the trust decision separate.
Should a pending item appear in search?
It can, if the index labels the result as pending and explains which content is missing. The label prevents a metadata result from looking like a complete local document.
Does revoking a device delete its local copy?
Revocation should change authorization. Deletion should name the copies it removes. Treat them as separate operations unless a policy explicitly combines them.
What should I send to support?
Send a reviewed diagnostic summary with route and timing fields. Remove clipboard text, document bodies, tokens, and addresses that your policy treats as confidential.
Verification checklist
Open a recent item offline. Edit it and reopen it. Pair a second device. Sync a small item.
Leave a large item pending. Download it on demand. Disconnect during the transfer. Retry after reconnecting.
Compare the diagnostic timelines. Use a ready item while the download runs. Move a test item to Trash. Restore it.
Delete it forever. Revoke the second device. Test a future request. The goal is not to collect a security score.
The goal is to know where your data lives, when it moves, and how you regain control.
Continue reading
Read why local-first software feels different for the broader product model. Privacy becomes manageable when the software gives you a name for each boundary and a way to test it.