Say your cousin installs a free "Flashlight" app on her Android phone before a power cut. The app just needs to turn the camera's LED on and off — that's it. But when she opens it, a permissions screen asks for her contacts, location, microphone, and photos. She taps "Allow All" because she wants the light to work now, and the cut is starting. Two weeks later she starts getting WhatsApp spam addressed to her by name, from numbers she's never shared with anyone except the people in her phone's contact list.
Nothing was "hacked." No password was stolen. She gave the app permission, herself, with one tap. This chapter is about understanding exactly what happened in that tap — what counts as your personal data, how it moves once you hand it over, why "anonymous" data often isn't, and what the law in India actually says you're entitled to do about it. Privacy isn't about having secrets. It's about who gets to decide what happens to information about you, and CBSE Computer Science expects you to reason about this the same way you'd reason about any system: inputs, processes, and outputs.
What Actually Counts as "Your Data"?
Not all information about you carries the same risk if it leaks. It helps to sort it into three buckets before we go further.
- Direct identifiers — data that points to exactly one person with no ambiguity: your full name, Aadhaar number, phone number, email address, PAN number, or a photo of your face.
- Indirect (quasi) identifiers — data that doesn't name you alone, but narrows things down a lot when combined with other pieces: your PIN code, date of birth, school name, gender, or device ID.
- Sensitive personal data — a special, higher-risk category that includes things like biometric data (fingerprint, iris, face scans), health records, financial account details, sexual orientation, religious belief, and passwords. Indian law treats leaks of this category more seriously than ordinary personal data, because misuse of it causes more lasting harm.
The flashlight app's contacts-list request wasn't asking for direct identifiers about your cousin — it was asking for direct identifiers about every single person in her phone, none of whom had consented to anything. That's the first idea to hold onto: your data decisions can leak other people's data too.
How Data Actually Gets Collected — Three Channels
It's tempting to imagine companies "spying" on you through some mysterious process. In reality, almost all data collection happens through three concrete, traceable channels, and knowing them is what lets you control them.
1. Declared data — anything you type into a form: your name during sign-up, your address at checkout on an e-commerce site, your marks while filling an exam form on a school portal.
2. Observed data (permissions) — anything a device sensor reports because you granted an app access: GPS location, camera, microphone, contacts, call logs, storage. On Android and iOS, each of these is a separate, revocable switch — which is precisely why the flashlight app had to ask for four of them individually.
3. Inferred / tracked data — information nobody typed in directly, but which a system built by watching your behaviour: which links you clicked, how long you paused on a product page, what time of day you're usually online. The core tool behind this on the web is the cookie.
Here's the mechanic behind a cookie, worked through in code. A web server cannot normally tell two visits apart — HTTP is "stateless," meaning each request arrives with no memory of the last one. So the server hands your browser a small ID number on your first visit, your browser stores it, and sends it back automatically on every later visit:
users_online = {}
def visit_website(existing_cookie):
if existing_cookie in users_online:
return f"Welcome back! Session {existing_cookie}"
else:
new_id = len(users_online) + 1001
users_online[new_id] = {"visits": 1}
return f"New visitor. Cookie set: {new_id}"
print(visit_website(None)) # first visit, browser has no cookie yet
print(visit_website(1001)) # second visit, browser sends back the stored cookie
Trace it by hand. On the first call, existing_cookie is None, and users_online is still empty, so None in users_online is False — we fall into the else branch. new_id becomes len(users_online) + 1001 = 0 + 1001 = 1001, that key is stored, and the function returns "New visitor. Cookie set: 1001". On the second call, existing_cookie is 1001, and now 1001 in users_online is True, so it returns "Welcome back! Session 1001". That's all a cookie is: a number your browser carries back and forth so a server can recognise "the same visitor" across requests. It's also exactly how an advertising network, once embedded on many different websites through tracking scripts, can notice that "cookie 1001" viewed cricket shoes on one site and then show cricket-shoe ads on a completely different site later that day.
The Data Lifecycle
Once information is collected through any of the three channels above, it doesn't just sit still. It moves through a lifecycle, and each stage is a separate point where things can go right or wrong.
Read the diagram left to right: you hand over data through collection, it sits in a store (a database or server), it gets run through processing (algorithms that sort, score, or profile it), and it may then be shared or sold to advertisers or other companies. The dashed red arrows show that both storage and processing are places where a breach can happen — a hacker steals a database, or an employee misconfigures a server so it's publicly reachable. The green loop at the bottom is the part most students don't know exists: Indian law gives you a way to reach back into that pipeline and pull your data out, which we cover next.
Why "Anonymous" Data Often Isn't
Companies often claim data is "anonymised" — names removed — before it's shared or sold, and treat that as if it makes the data harmless. This claim deserves scrutiny, and there is real research behind why.
In 2000, researcher Latanya Sweeney showed that, using only three indirect identifiers — ZIP code, date of birth, and gender — about 87% of the U.S. population could be uniquely re-identified from supposedly anonymous records, even with names stripped out. None of those three fields looks dangerous by itself. Combined, they act almost like a fingerprint.
You can see why with simple arithmetic. Suppose a "de-identified" dataset from a neighbourhood clinic lists only PIN code, date of birth, and gender for each patient — no names. Imagine a PIN code area with roughly 5,000 residents. Splitting them by roughly 365 possible birthdates and 2 genders:
people_in_pin_code = 5000
possible_birthdates = 365
possible_genders = 2
average_people_sharing_all_three = people_in_pin_code / (possible_birthdates * possible_genders)
print(round(average_people_sharing_all_three, 1))
That divides 5000 by 730, giving about 6.8. On average, fewer than seven people in that entire PIN code share your exact birthdate and gender — and real populations aren't spread evenly across days of the year, so for many people the true number sharing all three fields is one: just them. This is a simplified illustrative calculation, not a measured statistic — but it's the same reasoning Sweeney's real, published research demonstrated, and it's why data protection law does not treat "we removed the name" as sufficient protection on its own.
Your Rights Under Indian Law
Privacy in India isn't just a company policy — it's constitutional law. In 2017, a nine-judge bench of the Supreme Court, in Justice K.S. Puttaswamy (Retd.) vs. Union of India, unanimously held that the right to privacy is a fundamental right, protected under Article 21 of the Constitution (the right to life and personal liberty). That judgment is the foundation everything below is built on.
The main law that puts this into everyday practice is the Digital Personal Data Protection Act, 2023 (DPDP Act), India's first comprehensive data protection law, passed by Parliament in August 2023. It defines a working vocabulary you should know precisely:
- Data Principal — you, the individual the data is about.
- Data Fiduciary — the organisation that decides why and how your data is processed (the flashlight app's company, a shopping site, a bank).
- Consent Manager — a registered platform through which you can view, grant, and withdraw consent for different fiduciaries in one place, instead of chasing each company separately.
- Data Protection Board of India — the body that hears complaints and can penalise fiduciaries for violations.
The Act gives Data Principals several concrete rights: the right to access a summary of what personal data a fiduciary holds about you and how it's being processed; the right to correction and erasure of your data; the right to grievance redressal through the fiduciary and then the Board if unresolved; and the right to withdraw consent at any time, as easily as it was given. Fiduciaries, in turn, are obligated to use data only for the purpose you consented to (called purpose limitation), keep it only as long as necessary, apply "reasonable security safeguards," and report data breaches.
One provision matters directly to you, at your age: the Act sets special protection for children's data (defined as under 18). A Data Fiduciary must obtain verifiable parental consent before processing a child's personal data, and is barred from tracking, behavioural monitoring, or serving targeted advertisements aimed at children. This is why age-gates and parental-consent screens exist on many apps — they're not arbitrary friction, they're a legal requirement built specifically around students your age.
It's also worth knowing what came before: Section 43A of the Information Technology Act, 2000 (added in a 2008 amendment) already required companies handling sensitive personal data to maintain "reasonable security practices," and made them liable to pay compensation if negligence caused you wrongful loss. The DPDP Act is broader and stronger, but it didn't appear out of nowhere — it built on this earlier foundation.
Correcting a Common Misconception: "I Have Nothing to Hide"
A very common reaction to all this is: "Why does it matter if a company knows my birthday and PIN code? I'm not doing anything wrong." This reasoning has a specific flaw: it assumes privacy is only about hiding wrongdoing, when it's actually about controlling how information about you gets used against your interests, even when you've done nothing wrong. Three concrete ways this plays out:
- Aggregation risk. Each single fact about you (school, PIN code, birthdate) seems harmless. Combined, as shown in the arithmetic above, they can single you out — enabling anything from targeted scams to physical stalking, since location + routine data can reveal exactly when your house is empty.
- Price and opportunity discrimination. Companies use browsing history and device data to show different prices or different opportunities to different people — for example, flight or hotel booking sites are widely known to adjust displayed prices based on signals like how many times you've searched a route, your device type, or your apparent urgency.
- Permanence. Data given away at 13 doesn't expire when you turn 18. A photo, a location history, or a "harmless" quiz app's data collection can resurface years later — during a college admission background check or a job's social-media screening — in a context you never agreed to.
Privacy protects your ability to control your own narrative and your own safety — not just your secrets.
Worked Example: Auditing an App's Permission List
Data protection law places one obligation squarely on companies: data minimisation — collect only what's genuinely necessary for the stated purpose. You can apply this same test yourself. Suppose a "Flashlight" app requests:
requested = ["camera", "location", "contacts", "microphone", "storage"]
necessary_for_flashlight = ["camera"]
unnecessary = [p for p in requested if p not in necessary_for_flashlight]
print(f"Unnecessary permissions requested: {len(unnecessary)} of {len(requested)}")
print(unnecessary)
Tracing it: the list comprehension checks each of the five requested permissions against the one-item necessary_for_flashlight list. "camera" is in it, so it's excluded from unnecessary; the other four ("location", "contacts", "microphone", "storage") are not, so all four land in unnecessary. Output: Unnecessary permissions requested: 4 of 5, followed by the list of those four. A four-out-of-five "excess ratio" like this is exactly the pattern that should make you tap "Deny," not "Allow All" — a flashlight has no legitimate technical reason to read your contacts.
On real Android and iOS devices, an app that is denied a permission at install time can typically still function for its core purpose — it just cannot use that specific sensor. Denying "contacts" to a flashlight app breaks nothing about the flashlight.
Data in Transit: Why the Padlock Icon Matters
Collection and storage aren't the only places data is exposed — it also travels across networks, and that trip needs protection too. When your browser address bar shows HTTPS (not plain HTTP) and a padlock icon, it means the connection between your device and the server is encrypted using TLS (Transport Layer Security): anything you type — a UPI PIN, an IRCTC booking's passenger details, a login password — is scrambled before it leaves your device and can only be unscrambled by the intended server. On plain HTTP, that same data travels in readable plain text, meaning anyone sharing the same public Wi-Fi network (a railway station, a café) could potentially intercept it. This is why every legitimate banking or UPI app forces HTTPS, and why you should treat any payment page without a padlock icon as unsafe.
Practical Controls That Follow Directly From What You Just Learned
- Before tapping "Allow," ask the data-minimisation question from the worked example: does this specific permission serve this app's actual, stated purpose?
- Read the "purpose" line of a consent notice, not the whole document — the DPDP Act requires fiduciaries to state clearly why they want your data, in plain language.
- Use your right to access and erasure: legitimate Indian platforms are now required to provide an in-app way to view or delete your data — look for it in account settings before assuming you have no options.
- Treat your date of birth, PIN code, and gender as a set, not as three separate harmless facts — that's the combination the identifiability arithmetic above was built around.
- Check for HTTPS and the padlock icon before entering any payment or login information, especially on shared or public Wi-Fi.
Practice: Test Your Understanding
- Classify each as a direct identifier, an indirect identifier, or sensitive personal data: (a) your Aadhaar number, (b) your school's PIN code, (c) your fingerprint used to unlock a phone.
- A quiz app for Class 8 students asks for microphone and contacts access before you can take a 10-question multiple-choice quiz. Using the data-minimisation reasoning from the worked example, which permission(s), if any, would you deny, and why?
- Trace this code by hand and give its exact printed output:
visits = {} def check_in(cookie_id): if cookie_id in visits: visits[cookie_id] += 1 return f"Visit #{visits[cookie_id]} for {cookie_id}" visits[cookie_id] = 1 return f"First visit for {cookie_id}" print(check_in(2002)) print(check_in(2002)) print(check_in(2003)) - A shopping site suffers a data breach, and your phone number and past order history are leaked. Name two obligations the DPDP Act places on that company because of this breach, and one right you personally have as the Data Principal in response.
- A dataset removes everyone's name but keeps date of birth, PIN code, and gender, drawn from a single PIN code area of about 4,200 people. Using the same style of calculation shown earlier, estimate the average number of people who would share all three fields, and explain in one sentence what this implies about calling the dataset "anonymous."
Summary
Personal data separates into direct identifiers, indirect identifiers, and a higher-risk sensitive category, and it enters a company's systems through only three channels: what you declare, what sensors observe once you grant permission, and what tracking infers from your behaviour, with cookies as the core mechanism behind that third channel. Once collected, data flows through a lifecycle — collection, storage, processing, sharing — with breach risk sitting at storage and processing, and your legal rights forming a feedback loop back into that pipeline. "Anonymised" data is frequently re-identifiable once a few indirect identifiers are combined, a fact demonstrated by real research and reproducible with basic arithmetic. In India, your right to privacy is constitutionally protected since the 2017 Puttaswamy judgment, and the Digital Personal Data Protection Act, 2023 turns that right into specific, actionable powers — access, correction, erasure, and consent withdrawal — with extra safeguards specifically for users under 18. The habit worth building isn't paranoia about technology; it's the same habit CBSE Computer Science asks you to build everywhere else — trace what a system actually does with its inputs before you decide to trust it.