MYP Design Data Privacy and Cybersecurity Notes

Personal Data Is Anything That Points Back to a Person

1. Personal data is any information that can be traced back to a living person, either on its own or once it is put beside something else you hold.
2. The obvious ones are a name, a home address, an email, a photo of a face, a date of birth and a phone's unique device identifier.
3. The less obvious ones stack up: a year group plus a form class plus a favourite subject can single out one student in a room of thirty.
4. Some categories are treated as more sensitive than the rest, health information among them, and the safe rule for a school project is not to collect them at all.
5. Anonymised data has the identifying parts stripped out, so "participant 17, hand width 82 mm" keeps the measurement and loses the person.
   1. Anonymising afterwards is weaker than never collecting, because until you strip it the raw version is sitting in somebody's account.

Consent Has to Be Asked For, Not Assumed

1. Consent means the person understood what you were collecting and why, and agreed before you started collecting it.
2. Agreement given because refusing meant being left out of the class activity is not real consent.
3. Say three things when you ask: what you are collecting, what you will do with it, and when you will delete it.
4. Where your testers are under 16, a parent or guardian usually has to agree too, so check with your teacher before a survey leaves the classroom.
5. Withdrawing consent should be as easy as giving it, so tell testers how to ask you to take their data out.
6. Photographing a user testing your prototype is collecting personal data.

Collect Only What You Actually Need

1. Data minimisation means asking for the smallest amount of information that can still answer your question.
2. If the question is whether hand size affects grip, you need a hand measurement and you do not need a name.
3. Every extra field is one more thing to store safely, one more thing to delete later and one more thing to lose.
4. Label people with a code such as P07 rather than a name, and either keep the list linking codes to names somewhere separate or never write it down.
5. Set a deletion date at the start of the project and then delete on it.
6. Survey answers parked in a shared drive folder the whole year group can open are already leaked, whatever the folder is called.

Passwords Fail for Predictable Reasons

1. Password strength comes from length far more than from punctuation, so four random words beat a short word with symbols swapped in.
2. Using one password everywhere means a single leaked website hands an attacker every other account you own.
   1. Attackers automate that: taking email and password pairs from one breach and trying them on hundreds of other sites is called credential stuffing.
3. A password manager generates and stores a different long password for every site, so the only one you memorise is the one that opens the manager.
4. Two factor authentication asks for something you know plus something you have, usually a six digit code from an app on your phone.
5. An app generated code is safer than a text message, because a phone number can be moved to an attacker's SIM by someone convincing enough on a phone call.

Phishing and Malware: The Attacks Aimed at People, Not Machines

1. Phishing is a message pretending to come from someone you trust, built to make you type your password into the wrong page.
2. The tells are urgency, an address that is almost right, a link whose real destination differs from the words shown, and a request you were not expecting.
3. Hover over a link and read the actual domain before you click, because the text of a link is only text.
4. Malware is software written to damage or spy: a virus spreads inside other files, ransomware locks your files and demands payment, spyware quietly records what you do.
5. Most of it arrives through an unexpected attachment, a pirated download of expensive design software, or a browser that has not been updated in a year.
6. Updates matter because a large share of successful attacks use holes that were fixed months earlier in a version nobody installed.

Encryption in One Line

1. Encryption scrambles data with a key, so anyone who intercepts it reads nonsense instead of your message.
2. Encryption in transit protects data while it travels, which is what HTTPS and the padlock beside the address are doing.
3. Encryption at rest protects data sitting on a disk, which is what saves you when a laptop full of user testing is left on a bus.
4. Encryption is only as strong as the key, so a first rate algorithm guarded by the password 1234 protects nothing at all.
5. Nobody expects you to write encryption yourself, only to choose services that already use it and to say in your folder which ones.

What a Student Designer Must Do When a Product Collects User Data

1. Write down in the folder exactly what your product collects and why each field exists, before you build the form.
2. Ask for consent in plain words before any testing, and keep the wording you used as part of your evidence.
3. Store what you gather in one named place behind a password, rather than scattered across group chats, phones and shared drives.
4. Strip identifying details before anything reaches your ePortfolio, so a chart shows P07 and never a full name.
5. Blur faces, names and school logos in photographs and screenshots unless you have been told you may show them.
6. State what happens to the data when the project ends, then actually do it.

A Quick Check Before Anything Goes Public

1. Open every screenshot at full size and look for names, emails and timetables left visible in the corner.
2. Check any spreadsheet you attach for a hidden sheet or a hidden column holding the raw names.
3. Ask whether you would be comfortable if the person in row 12 read the folder, and fix whatever makes you hesitate.