Build the mental model
Every app requests permissions on install: camera, microphone, photos, contacts, location, files, Bluetooth, notifications. A permission should map to the app's actual stated purpose.
A maps app asking for location makes sense. A flashlight app asking for location, contacts, or microphone does not — that mismatch is worth questioning, not assuming malice.
Tracking technologies — cookies, device identifiers, analytics, advertising identifiers — let a company understand how their product is used.
Not all analytics is malicious
Legitimate product analytics helps a team fix bugs and improve the product in ways that genuinely benefit users too. The goal is awareness and periodic review, not blanket rejection.
- Account visibility settings
- Ad and privacy controls
- Each installed app's actual permissions
- Location sharing still turned on for apps that no longer need it
- Connected third-party applications
- Devices and sessions still logged in
This doesn't need to happen daily. A calm, occasional pass — every few months, or after installing something new — catches what quietly outlived its purpose.
PERMISSION VS STATED PURPOSE
----------------------------
App: Flashlight Requests: camera, location, contacts
Stated purpose: light the camera flash
camera -> MATCH (needed to control the flash)
location -> MISMATCH (not needed for a flashlight)
contacts -> MISMATCH (not needed for a flashlight)
App: Maps Requests: location
Stated purpose: show maps and directions
location -> MATCH (core to the app's purpose)Connect it to a real scenario
The function below runs the "does this permission match the purpose" check across a whole list of apps at once, using a small lookup table of expected permissions per category.
For each app, anything requested that doesn't belong to its category's expected list is collected into mismatchedPermissions, and the app is flagged REVIEW with exactly what triggered it.
Flashlight app
Requests camera, location, contacts — location and contacts flagged as mismatches.
Maps app
Requests only location — comes back clean, OK.
Running a check like this across every installed app turns a vague sense of "I should review permissions sometime" into a specific list of what to check first.
Privacy Settings Review
Try the working example
function reviewAppPermissions(apps) {
const purposeToExpectedPermissions = {
flashlight: ["camera"],
maps: ["location"],
messaging: ["contacts", "notifications", "microphone", "camera"],
photoEditor: ["photos", "camera"],
};
return apps.map((app) => {
const expected = purposeToExpectedPermissions[app.purposeCategory] || [];
const mismatches = app.requestedPermissions.filter((p) => !expected.includes(p));
return {
name: app.name,
requestedPermissions: app.requestedPermissions,
mismatchedPermissions: mismatches,
flag: mismatches.length > 0 ? "REVIEW — permission does not match stated purpose" : "OK",
};
});
}
const apps = [
{ name: "BrightTorch", purposeCategory: "flashlight", requestedPermissions: ["camera", "location", "contacts"] },
{ name: "TrailMaps", purposeCategory: "maps", requestedPermissions: ["location"] },
];
console.log(JSON.stringify(reviewAppPermissions(apps), null, 2));[
{
"name": "BrightTorch",
"requestedPermissions": [
"camera",
"location",
"contacts"
],
"mismatchedPermissions": [
"location",
"contacts"
],
"flag": "REVIEW — permission does not match stated purpose"
},
{
"name": "TrailMaps",
"requestedPermissions": [
"location"
],
"mismatchedPermissions": [],
"flag": "OK"
}
]5-minute try-it
Add a new purposeCategory, "weatherApp", expected to request only "location" and "notifications". Add a weather app to the apps list that also requests "contacts", and confirm the function correctly flags the mismatch.
One important caution
Granting every permission an app asks for during setup without checking whether it matches the app's actual purpose.
Treating all tracking as inherently malicious and missing that legitimate analytics can also improve the product for users.
EFF Surveillance Self-Defense — Digital Privacy & Modern Security