4.1 Ethical and Social Issues Around Data Collection

What you need to know

• Programs today collect and process enormous amounts of data about people. Personal data can identify someone directly or in combination with other data.
• Privacy: people have a reasonable expectation about how their data is used. Collecting more than needed, keeping it longer than needed, or sharing it without consent violates that.
• Security: stored data can be breached; the more collected, the greater the harm from a breach.
• Bias in data: a dataset that under-represents some groups leads to programs that serve them worse. Analysis is only as fair as the data.
• Consent and transparency: users should know what is collected and why. Terms buried in fine print are legally compliant but ethically weak.
• Programmers are responsible for the systems they build — including anticipating misuse and designing to limit it.

Worked example

A school app records which students open which assignments and when. Useful for spotting who's struggling. But the same data could rank teachers, track students' late-night habits, or be sold to a tutoring company. Responsible design: collect only assignment-completion status, aggregate before sharing, tell students what's stored, and delete it at year end.

Going deeper

The nuance, edge cases, and connections that turn a 3 into a 5.

• This mirrors CSP's 5.5 and 5.6 but through a programmer's lens: you are writing the code that collects and processes the data, so the responsibility is yours.
• Personal data is anything that identifies a person alone or in combination. Names and IDs obviously; but ZIP + birthdate + gender identifies most people too. Combination is the trap.
• Privacy risks in code: storing more than needed, storing longer than needed, logging sensitive fields, sharing between systems without consent, weak access control (public fields, no validation). Each is a design decision, and each can be made better.
• Security risks: any stored data can be breached. The consequence scales with how much you stored. Minimization limits the damage.
• Bias in data sets: if a data set under-represents a group, statistics computed from it (averages, models) will be wrong for that group. Programs that make decisions from biased data make biased decisions — at scale, automatically. Checking representation before analyzing is part of responsible programming.
• Informed consent means people understand what's collected and why, and agreed. Buried terms of service technically count legally; the CED asks you to see that they don't count ethically.
• Transparency: users should be able to find out what data is held about them. Programs that make it impossible are designed badly.
• On the exam this is scenario questions: given a data-collection situation, which action is most responsible? Minimize, consent, anonymize, check for bias, secure it.

Mistakes that cost points

• Picking the maximal-collection option. "Store everything in case it's useful" is the wrong answer.
• Assuming anonymized data can't identify people. Combining fields re-identifies. The exam expects you to know this.
• Treating bias as a data-science-only problem. The program that uses the data inherits the bias.

Practice questions

Written in the style of the real exam. Try each one before revealing the answer.