Ethical and Social Issues Around Data Collection: Study Guide (Computer Science A 4.1)

Programs run on data, and data comes from people

In Unit 4 you start working with collections of data: arrays, lists and tables. Before you write code to process data, this topic asks three questions that a responsible programmer asks first. Where did the data come from? What could go wrong because of how it was collected or stored? Is it the right data for the question?

The skill assessed is to explain the social and ethical implications of computing systems and to judge what knowledge can responsibly be taken from data. There are four ideas.

1. Privacy

When people use a computer, their personal privacy is at risk. Programs collect names, locations, browsing, purchases and messages, and a data set that is collected and stored can be lost, stolen, shared or used in ways the person never expected. When developing new programs, programmers should attempt to safeguard the personal privacy of the user.

Practical safeguards you can name:

• Collect only what the program needs. Data you never collect cannot leak.
• Store it securely and for no longer than necessary.
• Be open about what is collected and why, so users can make informed choices.
• Avoid combining and sharing data in ways that identify individuals.

A privacy question in the exam usually asks you to name a specific risk (for example, a stored location history revealing where someone lives) and a specific safeguard.

2. Algorithmic bias

Algorithmic bias describes systemic and repeated errors in a program that create unfair outcomes for a specific group of users. Three parts of that definition each matter:

• systemic and repeated: not a single slip, but a pattern;
• errors that create unfair outcomes: people are treated worse, not merely differently;
• a specific group: the harm falls on some users more than others.

Algorithmic bias usually comes from the data. A program that learns from, or is tuned on, a data set copies the patterns in it. If the data under-represents a group, the program’s results for that group will be less accurate. If the data reflects unfair past decisions, the program repeats them.

3. How the data was collected

Programmers should be aware of the data set collection method and the potential for bias in it before using the data to extrapolate new information or draw conclusions. Ask:

• Who was included, and who was left out?
• Did people choose to take part (volunteers differ from the rest)?
• Was the data collected in one place, at one time, or by one device?
• Does the group in the data match the group the conclusion is about?

In Figure 1, a program built only from the app data would be tuned mainly to younger riders. Its suggestions could be systematically worse for the oldest group, which is algorithmic bias arising from a collection method.

4. Data quality and the right data set

Some data sets are incomplete or contain inaccurate data. Using such data in the development or use of a program can cause the program to work incorrectly or inefficiently. Missing values, wrong units, typing mistakes and special codes for “no reading” all fall into this category.

Also, the contents of a data set may relate to one question or topic and may not be appropriate to give correct answers, or to extrapolate information, for a different question or topic. A data set about adult sleep tells you little about school-age sleep.

You can see data quality go wrong in code. A sensor reports temperatures but uses the code -999.0 when it has no reading. Compare a program that ignores the code with one that handles it.

public class NaiveSensor
{
    private double sum = 0;
    private int count = 0;

    public void record(double reading)
    {
        sum += reading;
        count++;
    }

    public double average()
    {
        return sum / count;
    }
}

public class CleanSensor
{
    private double sum = 0;
    private int count = 0;
    private int skipped = 0;

    public void record(double reading)
    {
        if (reading == -999.0)          // -999 is the sensor's code for "no reading"
        {
            skipped++;
        }
        else
        {
            sum += reading;
            count++;
        }
    }

    public double average()
    {
        return sum / count;
    }

    public int getSkipped()
    {
        return skipped;
    }
}

Worked example 1: judging a data set before using it

Task. A fictional city wants to decide where to add buses. Its program uses trip data from a journey-planning app. Evaluate the data set using Figure 1.

Step 1: the question and the data. The question is “which routes do all riders need more buses on?” The data are app trips, which cover only riders who use the app.

Step 2: the collection method. Using the app requires a smartphone and a choice to use it. People who do not have one, or choose not to, are missing from the data.

Step 3: compare with the population. In Figure 1, riders aged 65 and over are 20% of all riders but only 3% of the app data; their representation is 3 ÷ 20 = 0.15 of what it should be. Riders aged 18 to 34 are 70% of the app data against 50% of all riders: 70 ÷ 50 = 1.4 times their true share. (These figures are fictional, and the ratios were computed and checked.)

Step 4: the consequence. A program that adds buses where the app shows most trips would favour routes used by younger riders. Routes that older riders rely on could be under-served over and over, which is a systemic, repeated unfair outcome for a specific group: algorithmic bias.

Step 5: possible responses. Collect additional data in other ways (for example on-bus counts), weight the data to match the real mix of riders, or state clearly that the conclusions apply only to app users.

Check. The answer names the group affected, the cause in the collection method, the evidence and a remedy. Privacy also deserves a mention: any app trip data identifies where a person lives and goes, so the city should store it securely and collect only what it needs.

Worked example 2: how bad data breaks a program

Task. Trace the two sensor classes on the readings 20.5, −999.0 (no reading) and 22.5, and decide which average is believable.

Step 1: the naive sensor. Every value, including the code −999.0, is added and counted.

Call	sum	count
start	0.0	0
record(20.5)	20.5	1
record(-999.0)	−978.5	2
record(22.5)	−956.0	3

average() is −956.0 ÷ 3, which is about −318.67. The compiled program printed -318.6666666666667. That is physically impossible for a room temperature, because a “no reading” code was treated as data. The program works incorrectly.

Step 2: the clean sensor. It checks for the code first.

Call	Action	sum	count	skipped
start		0.0	0	0
record(20.5)	add	20.5	1	0
record(-999.0)	skip	20.5	1	1
record(22.5)	add	43.0	2	1

average() is 43.0 ÷ 2 = 21.5, and one reading was skipped. The program printed 21.5 1.

Step 3: an edge case. If a clean sensor receives only the code, then count is 0, and sum / count is 0.0 / 0, which is NaN (not a number) for a double. A careful programmer would test for count == 0 before dividing. This shows that incomplete data must be handled by the design, not only by the data.

Check. On the readings 10.0, 12.0, −999.0, 14.0 the naive average is −240.75 but the clean average is 12.0, with one skipped, both confirmed by running the code.

Common misconceptions

• “Algorithmic bias means a programmer wrote an unfair rule on purpose.” It is defined by the unfair, repeated outcomes for a group, whatever the intent. Often the cause is data.
• “More data fixes bias.” Not if the collection method keeps leaving the same people out.
• “A single wrong answer is algorithmic bias.” It must be systemic and repeated and affect a specific group.
• “If data is anonymous, privacy is no longer a concern.” Combinations of details can still identify people, and the safeguards (collect less, store securely) still matter.
• “A data set that answers one question answers all related questions.” It may not fit a different question or group.
• “Missing data is harmless because it is just missing.” A program that counts a missing-value code as a real value gives wrong results.

Where this leads

Topic 4.2 shows how to represent and plan algorithms for data sets, and Topics 4.3 to 4.5 give you the array code to process them. Introduction to Using Data Sets is next. Practise with the practice questions, consult the revision notes and tick the topic checklist. To recall the broader impact of programs, see Impact of Program Design.