4.1 - Ethical and Social Issues Around Data Collection
Any time you’re using a computer, your personal privacy is potentially at risk. As a programmer, you should try to safeguard user privacy when you’re building new programs.
Personal data is anything that can be tied back to a specific person: a name, address, birthday, location history, photos, or browsing habits. Once a program collects and stores that kind of data, a few things can go wrong:
- Data breaches: attackers break into the system and steal the stored data, which can lead to identity theft or fraud.
- Sharing or selling: the data gets passed along to other companies, often without users really knowing where it went.
- Tracking: lots of small pieces of data put together (locations, purchases, searches) can reveal a lot about someone, like where they live, their daily routine, or their health.
- It sticks around: stored data can last for years, and once it’s been copied or shared, it’s hard to take back.
Some ways programmers can protect users’ privacy:
- Only collect the data the program actually needs.
- Store it securely, for example by encrypting it and limiting who can access it.
- Tell users what’s being collected and why, and let them opt out or delete their data.
- Remove names and other identifying details when the data is only being used for analysis.
Algorithmic bias describes when a program produces repeated, systematic errors that create unfair outcomes for a specific group of people. It’s important to understand how a data set was collected and to think about whether that collection method could have introduced bias, before you use that data to draw conclusions or make predictions.
For example, say a resume-screening program learns what a good hire looks like from a company’s past hires, and most of those hires were men. The program can learn to rank women’s resumes lower. The code itself might not have a single typo, the unfairness comes from the data it learned from. That’s what makes it systemic: it happens over and over, to the same group, every time the program runs.
Bias can also come from how the data was collected. Say you want to know how much time teens spend on homework, so you post a survey on a gaming website. The only people who answer are ones who visit that site and chose to respond, so the results probably don’t represent all teens. Before drawing conclusions from a data set, ask who collected it, how they collected it, and who might be missing.
Some data sets are just incomplete or contain inaccurate data, and using data like that can make your program behave incorrectly or inefficiently.
For example, a data set of student ages might have blank entries, typos like 166 instead of 16, or the same student listed twice. A program that averages those ages without checking will give a wrong answer, and a blank entry can even crash a program that tries to turn it into a number. Good programs check for missing or impossible values before using the data.
Also worth remembering: a data set collected for one specific question or topic might not actually be appropriate to use for a totally different question. Just because the data exists doesn’t mean it’s the right data for the job.
For example, a data set of one school’s cafeteria sales can tell you which lunch is most popular at that school. It can’t tell you what students across the whole state prefer, and it can’t answer a different question entirely, like how much sleep students get. Pick a data set whose contents actually match the question you’re trying to answer.