Web apps and native apps: How much of your device can they access?
Suppose a writing tool offers both a website and an installed app. Either can do the work, but the choice changes what the service’s code can reach on your device. Here, “web app” means page code running inside a browser; the browser itself has its own operating-system access. “Native app” includes desktop and mobile apps and command-line tools.
First compare which files or device features the code can access. Then consider whether it can send information it obtains. A web page can send information you give it, too.
What device information and features can the code access?
The answer depends on where the code runs. Follow three examples of an ordinary app or web page before you grant it additional access.
Desktop app or CLI
The signed-in user’s access
An ordinary Windows desktop program often runs with the signed-in user’s permissions. It may read a file that account can read without separate approval for that file. A temporary-file location does not by itself isolate files per app; whether each file is readable still depends on its protection. A list of running process names can also give clues about which apps are in use on the device. File protections and app sandboxes can narrow access.
draft.txtDraft textFile content reaches the program File protections and sandbox rules still apply
Mobile native app
Its own app sandbox
Android and iOS isolate an app from another app’s private data. That does not make every device feature ask for approval. For example, Android apps can obtain raw accelerometer readings without a dedicated runtime consent prompt; background use and sampling rate have separate limits.
No dedicated runtime approval prompt
Web app page
Access through browser APIs
A normal page has no general API to scan your home directory or list the operating system’s processes. For a local file, the browser can give the page a file you select. The page receives that scope; it does not inherit the browser’s full operating-system access. Selection and ongoing permission details depend on the browser API.
draft.txtOther files and the OS process list are not directly handed to the page
An app’s packaging and operating-system protections matter. A sandboxed desktop app can have a narrower boundary than an ordinary desktop process. Apple: macOS App Sandbox (external site)
Can information it obtains leave the device?
Yes. Native apps can make outgoing Internet connections without a new approval for each message. A web page can also send information it has received through browser networking APIs. Accessing a file or sensor and sending what it yields are separate questions. The paths below show possibilities, not actual behavior by a particular app.
The routes differ. A normal web page cannot open raw TCP or UDP sockets; it uses browser-provided protocols such as HTTP and WebSocket. Cross-origin rules often limit which responses a page may read; they do not generally prohibit sending information. Local networks and localhost have their own rules. A site can restrict its own destinations with Content Security Policy (CSP), but that policy belongs to the particular site.
Does no permission dialog mean no access?
No. On Android, a developer declares INTERNET in the app manifest, and the system automatically grants this normal permission at installation. The app does not ask you to approve each outgoing connection. Microphone recording is different: the developer declares RECORD_AUDIO and the app must request a runtime permission. If you have not already granted it, Android shows an approval prompt. A developer declaration, an automatic grant, and your approval play different roles.
Which form should you choose for the same task?
If the web version meets your needs, the browser enforces a boundary around what the page can do to your device. A normal page cannot directly read arbitrary files or enumerate operating-system processes just because the signed-in user or browser can; it receives files through browser-provided paths, such as a file you select. As long as that boundary works as designed, the browser blocks those direct operations without relying solely on the site’s restraint or on you noticing every access. Some work requires a native app, whose actual sandbox and default access still matter. When both can do the job within the browser’s boundary, you can give the service less device access from the start.
These are capabilities, not evidence that any particular app has collected or uploaded information.