Sandboxing requires apps to declare and request a file-access scope

What it is

Desktop apps that once read and wrote any path are increasingly required to say which kind of place they will touch: this file the user picked, this folder the user picked, Downloads, a removable volume. Declaring and requesting a file-access scope is the paperwork sandboxing adds on top of direct access. The capability remains, but every trip outside the container needs a range the OS can enforce, rather than owning the whole disk at launch. This is not the capability contrast of whether desktop can read and write directly. It is that capability turning into a permission that must be asked for, with a boundary that must be named.

Why it happens

The system takes “can touch the disk” out of the app’s identity and grants it by range. Picking in an Open/Save dialog draws a range on the spot. An app can also declare “needs the Downloads folder” in its manifest. A grant can be remembered, so the next launch does not ask again; it can also be revoked in system settings, so a path that opened yesterday becomes a permission error today. People still model “this is my file, of course the software can open it.” The paperwork is a layer added later. Failure looks like a missing file or a broken app unless “this range does not cover that place” is named as the cause. A range that is too wide (the whole disk, the whole home folder) turns the dialog into a blank cheque; the system may refuse it or keep asking. A range that is too narrow makes people re-authorize every time they change project folders, and the paperwork becomes the main task.

Studying it

Have people finish a task that must leave the default container (open a project outside home, import from a USB stick, watch a user-chosen folder). Compare “the first pick remembers that folder” with “every open asks again.”

Independent variables: when the request happens (at first need / a bundle at launch), grain of the range (one file / a folder / the whole disk), whether the rest of the product still works after a refusal. Dependent variables: task completion, rate of immediately dismissing the grant dialog, whether people understand after refusal that it is only this path, whether they can later find and revoke that range in system settings.

A launch-time bundle of permissions turns the study into permission fatigue rather than whether the range is speakable. In the field, people click OK to make the dialog go away; afterwards ask “what did you just allow it to touch.” Split cross-platform conclusions: systems differ in whether they remember a folder and whether it can be revoked in settings.

Where it stops holding

An unsandboxed classic desktop installer may still get the whole disk at install; this paperwork never appears, and people will not expect it. Enterprise-managed machines pre-grant paths by policy, the dialog is skipped, the range is invisible to the user, and failures should point at policy, not the app. A pure container app never requests a range; user documents were never on the disk map. Opening one file once, with no need for its neighbors, is a single-file range; demanding a folder is over-declaring.

Applying it

• Request the range at the moment the path is actually touched, and say in the copy whether this is read or write, this file or this folder. Do not ask for the whole disk at launch.
• Remember a user-picked folder as the range until it is revoked in system settings. Ask again for a new block when the project changes; do not scan the disk silently.
• After a refusal or a revoke, features that do not depend on that path should still work. The error should point at “no permission for this location” and offer a way to pick again.
• Verify: on a fresh install, opening a file outside the container should show a request only for that pick. After refusal the app should still work inside the container. Closing and reopening the same folder should not ask again. Revoke the range in system settings; the next open should fail again and say it is permission, not a vanished file.

Related

• Within the group: K2.12.1 Desktop apps can read and write the user's filesystem, not only a sandbox · K2.12.2 OS differences in paths and naming break cross-platform ports · K2.12.3 Apps that touch the filesystem must handle concurrent external edits
• Adjacent: K1.12 Platform Differences in Permission Models · O2.01 Information design of permission prompts
• Search terms: scoped file access · app sandbox · file access prompt