Section 01Permissions, telemetry and the difference between needed and wanted

Every program you install is a request — not just the one you made when you clicked download, but a continuous series of requests the software makes in return. Access to your files. The ability to phone home. A listener on your network. Most of these happen silently, without a dialog box. Understanding what a program is asking for, and why, is one of the more practical skills you can develop as a computer user.

Section 02What permissions actually are

On a modern operating system, permissions are the rules that govern what a program can touch. A text editor needs to read and write files. A video player needs access to your speakers. These make sense. But the same mental model that makes permissions legible also makes abuses easy to miss — because software designers know you've been trained to click through any box that appears between you and the thing you wanted.

Desktop operating systems vary in how tightly they enforce permissions. Windows has grown more explicit over the years, with prompts for things like webcam access and location, but it still hands a freshly-installed application considerable latitude over the user's own file system. macOS applies a stricter sandbox to apps distributed through its App Store, while apps installed directly (DMG files, for instance) operate with fewer constraints. Linux distributions grant new software the rights of the user who ran it — which can be significant if you're working as an administrator, and is the main reason security-conscious users routinely create separate accounts for routine tasks.

Desktop operating systems vary in how tightly they enforce permissions.

The picture changes sharply on phones. The mobile permission model is more granular and harder to ignore — contacts, camera, microphone, location, background refresh all require explicit grants on both Android and iOS. This has its own complications, which mobile permissions covers in detail, but the underlying principle is the same: a permission is an offer you're making to the software, and it's worth pausing before you make it.

Open terminal window glowing on a monitor in a dark room
an open terminal window on a monitor in a dark room — the desk, where all of this actually happens.

Key facts · the words used here

telemetry
data a program sends to its developer about usage or errors
sandbox
restricted environment limiting what software can access or modify
permissions
rules governing which system resources a program may use
opt-in
a setting requiring active agreement before a feature activates
administrator rights
elevated privileges allowing system-wide changes

Section 03Needed versus wanted

The distinction that matters most is not whether a permission is granted, but whether it's necessary. A flashlight app that asks for your location doesn't need your location to turn on the torch — that's desire, not requirement. A photo-editing tool that requests microphone access has no obvious reason to listen to you. These mismatches between function and request are the clearest sign that a program is doing something beyond what you asked it to do.

The rationale for unnecessary permissions is usually advertising or analytics. An app that knows your location can place you in a demographic; one that knows what else is on your device can build a profile. None of this is intrinsically illegal — the terms of service may mention it, buried in paragraph nineteen — but it is a form of payment you didn't consciously agree to make. The software is free to download because you are, in some meaningful sense, the product.

This is where the difference between free-as-in-cost and free-as-in-freedom becomes practically important. A proprietary application with no price tag has to make money somehow. Open-source software under a licence like the GNU General Public License or the Apache License (from the Apache Software Foundation) gives you access to the code — meaning that if the program were silently harvesting your data, it would be a great deal harder to conceal and rather easier for someone to notice. That's not a guarantee of good behaviour, but it changes the audit surface considerably.

Section 04What telemetry is and when it's reasonable

Telemetry is the data a program sends home about how it's being used. Crash reports. Feature usage statistics. Session lengths. The word sounds clinical because it was borrowed from engineering contexts where tracking a satellite's position is obviously useful — but in software, "telemetry" has become a polite container for practices that range from genuinely helpful to invasive.

At its best, telemetry helps developers fix bugs they'd never encounter themselves. When Firefox crashes on a particular graphics configuration, crash telemetry is what tells Mozilla which configuration failed and how often. This is useful, and Firefox lets you see what it collects and switch it off in its privacy settings, and it asks before sending crash reports. The Free Software Foundation has long argued that even well-intentioned telemetry raises questions about autonomy — the software is doing something on your behalf that you didn't specifically request.

The problems arise when telemetry is opaque, persistent, or gathered at a scope you'd object to if you knew. Windows 10 and 11 collect what Microsoft calls "diagnostic data" by default; the minimum level includes device identifiers, installed software, and crash information, while higher settings add considerably more. Users can reduce the level in settings, but cannot eliminate it entirely in standard editions. The data goes to Microsoft regardless of whether you've agreed to any explicit data-sharing arrangement beyond the initial setup screen.

Many popular productivity applications follow a similar model. The terms of service may permit the collection; the privacy policy may describe it; neither document is written for a person who wants to understand it quickly. This is not accidental. The friction is part of the design.

Section 05How to look before you install

Before you install any program, there are a few practical checks worth running. First, look at what the installer requests during setup. A setup wizard that asks for administrator rights when installing a small utility is asking for more than it needs — and an elevated installer can make system-wide changes, including adding startup entries, scheduled tasks, or background services.

Second, after installation, check what the program launches at startup. On Windows, Task Manager's Startup tab shows what's been registered to run automatically. On macOS, the equivalent is System Settings under Login Items. A music player that quietly adds itself to startup is prioritising its own convenience over yours.

Third, look at the network. Tools like Little Snitch on macOS or GlassWire on Windows show which programs are making outbound connections and where those connections go. A word processor that dials out to an advertising network while you're writing is doing something you probably didn't sanction. You don't need to run this kind of monitoring all the time, but running it for a few hours after installing unfamiliar software is genuinely informative.

Fourth, read what others have already found. Established FOSS projects usually have public bug trackers, forum threads, and sometimes formal audits. The Open Source Initiative maintains a list of approved licences and some commentary on the projects that use them; security researchers publish findings on common tools regularly. You're rarely the first person to wonder whether a given program is trustworthy, and the answer is often already written down somewhere.

Section 06The baseline you're entitled to expect

A well-behaved program asks for what it needs, explains why it needs it, and doesn't take more when you grant access. It makes network connections that relate to its stated purpose. It gives you a real off switch for anything it collects. It doesn't install background services you didn't ask for or resist being uninstalled.

That baseline isn't naive idealism — it describes how many open-source applications actually behave, including tools like KeePassXC, which stores your passwords locally and makes no network requests at all during normal use, or VLC, whose network access is limited to the media streaming features you can choose to use or ignore. These programs exist and work, which is itself a useful counterargument to any claim that data collection is simply an unavoidable cost of functional software.

The gap between what a program is entitled to ask for and what it actually asks for is where your attention should go. You're not expected to read every permission dialog with the suspicion of a security researcher — but noticing when the request doesn't fit the function is a habit that costs almost nothing and occasionally saves you from something you'd have regretted installing.

Free Software Foundation

Referenced in this piece

US organisation that publishes the GNU GPL and advocates for software freedom

Open Source Initiative

Referenced in this piece

organisation that maintains the official definition of open-source and approves licences

Apache Software Foundation

Referenced in this piece

produces the Apache License and hosts major open-source projects

Mozilla

Referenced in this piece

non-profit that develops Firefox and publishes its data-collection practices

Microsoft

Referenced in this piece

publisher of Windows; collects diagnostic telemetry by default

Programs and organisations are named as examples, not recommendations. Where we link, we link the official project page. The desk hosts no files and ranks no vendors.