Module 4: Data Foundations

Privacy and Consent

Lesson 4.4 25–30 minutes 5 activities

Data About People Is Different

Everything we've covered in this module so far has been about making data work well technically. This lesson is about making data work well ethically. Because when your project handles information about people — even just yourself — the stakes change.

Here's the core principle: people have a right to know what data is being collected about them, how it's used, and who can see it. This isn't just a nice idea — it's the law in many places, and it's a fundamental part of building things responsibly.

Even if your project is just for you (like a personal habit tracker), building with privacy in mind is a skill that matters. Every app, website, and service you'll build or work with in the future handles personal data. Learning to do it right now puts you ahead.

How This Applies to Your Project — Track 1

Your habit tracker stores personal behavioral data. Even though you're building this for yourself, think about what happens if someone else uses it. Sleep habits, exercise patterns, mental health routines — this is sensitive information. Where is it stored? Who could access it? This lesson helps you answer those questions.

How This Applies to Your Project — Track 2

If your site has a contact form, you're collecting personal data. Names and email addresses are personally identifiable information (PII). Even if the form doesn't actually send email, the principle matters: what would you do with that data if it did work? This lesson covers the "what" and "why" of responsible data handling.

How This Applies to Your Project — Track 3

Data dashboards can expose sensitive information. A personal finance tracker reveals spending habits. A health dashboard reveals medical patterns. Even aggregated data can be revealing. Think about who can see your dashboard (it'll be at a public URL) and whether the data displayed could embarrass or harm someone.

Answer: Yes. First, you might share your project later. Second, building privacy-aware habits now means you'll do it automatically on future projects that do involve other people. Third, even your own data deserves protection — if your project is online, someone could potentially access it.

What You Can and Can't Collect

There's no universal rule book that covers every situation, but here are principles that apply everywhere:

Only collect what you need.

If your project doesn't need someone's full name, don't ask for it. If it doesn't need their location, don't track it. Every piece of data you collect is data you're responsible for protecting. Less data = less risk.

Be transparent about what you collect.

If your project collects any information about users, tell them. What data, why you need it, how it's stored, and who can see it. No surprises.

Get meaningful consent.

"Meaningful" means the person actually understands what they're agreeing to. A wall of legal text that nobody reads isn't meaningful consent. A clear, plain-language explanation with a real choice (including "no") is.

Extra caution with sensitive data.

Health information, financial data, location data, and anything about a person's identity require extra care. For your first project, it's best to avoid collecting sensitive data about other people entirely.

Special rules for minors.

Since you're likely under 18 yourself, you should know: collecting data from minors has additional legal restrictions in many places (like COPPA in the US). If your project targets users under 13, extra rules apply. For this course, keep it simple and avoid collecting personal data from other people.

Privacy-First Design Principles

Building with privacy isn't something you bolt on at the end. It's a design approach that shapes decisions from the start. Three principles:

1. Data minimization: Collect the absolute minimum.

For every field in your data model, ask: "Do I actually need this?" If a habit tracker works fine with just habit names and check-in dates, don't add fields for user email, location, or device info "just in case."

2. Storage security: Keep data safe.

For your course projects: don't put personal data in publicly accessible places. If using Google Sheets as a backend, make sure sharing settings are restricted. If using code, don't put sensitive information in files that anyone can view in a browser.

3. User control: Let people manage their data.

If your project stores information about someone, they should be able to see what's stored and delete it if they want. This isn't always practical for a first project, but it's the right principle to design toward.

Answer: Remove the fields you don't need. Only collect name and favorite color. Every extra field is extra risk with no benefit. Data minimization means collecting what's necessary, nothing more.

A Simple Privacy Checklist for Builders

Before you launch anything that other people will use, run through this checklist:

  1. What data does my project collect? (List every piece of information)
  2. Why do I need each piece? (Can I remove any?)
  3. How is it stored? (Is it secure? Who has access?)
  4. Have I told users what I'm collecting and why? (Transparency)
  5. Can users see and delete their data? (User control)
  6. Am I collecting data from minors? (Extra restrictions may apply)
  7. What happens to the data if I stop maintaining the project? (Plan ahead)

For your projects in this course, most of you will be building personal tools (data about yourself) or display projects (public content, no personal data). In those cases, privacy is simpler. But running through the checklist is still good practice — it builds the habit for when you build something bigger.

Key Concepts

  • People have a right to know what data is collected about them, how it's used, and who can see it.
  • Only collect what you need (data minimization). Every extra field is extra responsibility.
  • Be transparent: tell users what you collect and why, in plain language.
  • Meaningful consent means people actually understand what they're agreeing to.
  • Privacy is a design principle, not an afterthought. Build it in from the start.

Try It: Privacy Audit Your Data Plan

Apply the privacy checklist to your own project.

  • Pull out your data schema from Lesson 4.2.
  • For each field, answer: "Do I actually need this? What's the worst that could happen if this data was exposed?"
  • Remove any fields you don't truly need.
  • If your project will be used by others: draft a 3–4 sentence plain-language privacy notice explaining what you collect and why.
  • Ask AI: "Review my data plan for privacy concerns: [paste schema]. What data might I not need? What should I be careful about?"

AI Collaboration Moment

Have AI audit your data plan for privacy blind spots.

Use this prompt:

"I'm building a [project description] that will be deployed at a public URL. Here's my data plan: [paste your data plan]. Review it from a privacy perspective. What data am I collecting that could be sensitive? Are there privacy risks I haven't considered? What should I tell users about their data? Write me a simple, one-paragraph privacy notice I could include in my project."

What to do with the response:

  • Add the privacy notice to your project (footer or About page)
  • Address any privacy risks it identified
  • Save this for your Ethics Audit in Module 6

Check Your Understanding

1. What does "data minimization" mean?

Explanation: Data minimization means not collecting information you don't need. Every unnecessary field increases your responsibility and risk. If your project works without someone's email, don't ask for it.

2. What makes consent "meaningful"?

Explanation: Meaningful consent requires understanding. If someone can't easily understand what they're agreeing to, it's not real consent. Plain language, clear explanation, and a genuine option to decline — that's the standard.

3. Your habit tracker works perfectly with just habit names and daily check-ins. A friend suggests adding location tracking "because it might be useful later." What should you do?

Explanation: Data minimization in action. Location data is particularly sensitive, and "might be useful later" isn't a good enough reason to collect it. If you need it later, you can add it then. For now, less is more.

Reflect & Write

Write 2–3 sentences: Think about an app you use regularly. Do you know what data it collects about you? How does that make you feel? How does that awareness change how you think about your own project's data practices?

Project Checkpoint — Major Milestone!

Write your project's data plan:

Using the Data Planning Template (PDF), document:

  • What data your project collects
  • Where each piece comes from (user input, API, etc.)
  • How it's stored and who has access
  • What permissions are needed (if any)
  • Which fields you removed after the privacy audit

If your project will be used by others: include a 3–4 sentence plain-language privacy notice.

By the end of this checkpoint, you have a complete data foundation: schema, validation rules, and privacy plan. You're ready to build.

Find this and all other downloadable resources on the Dashboard Resources page.

Helpful Resource

Data Privacy Basics for Teen Builders (PDF) — A printable quick-reference guide covering the privacy principles from this lesson. Keep it handy whenever you're collecting or handling data in your projects.

Find this and all other resources on the Dashboard Resources page.

Level Up: Coming Next

Module 5: Building Real Things — Structure, Iteration, Debugging, and Shipping. Enough planning — it's time to build your project for real, debug the inevitable problems, and deploy it for the world to see.

Continue to Module Milestone →