Thuta Learning
AdvancedSecurityintermediate

App Permissions and Tracking

What you'll walk away with

  • Explain the core ideas behind App Permissions and Tracking
  • Read the diagram/checklist and trace how the threat, control, and decision connect
  • Explain how this applies to your own digital life or developer workflow

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.

text
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

javascript
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));
You should see
[
  {
    "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-DefenseDigital Privacy & Modern Security

Easy traps

  • 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.
  • This is not a restart of the Cybersecurity Basics course -- it assumes passwords, 2FA, phishing, malware, encryption, and backups are already covered there. This course adds what that one doesn't: passkeys, public Wi-Fi/VPN, browser security, privacy, developer-focused auth/API security, and AI security.

Exercise

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.

You'll know it worked when: [ { "name": "BrightTorch", "requestedPermissions": [ "camera", "location", "contacts" ], "mismatchedPermissions": [ "location", "contacts" ], "flag": "REVIEW — permission does not match stated purpose" }, { "name": "TrailMaps", "requestedPermissions": [ "location" ], "mismatchedPermissions": [], "flag": "OK" } ]

App Permissions and Tracking | Thuta Learning