Handling Privacy and Utility Together in Transport Data Assignments

You’re not just playing with CSV files—you’re simulating the work of a privacy analyst. Each data row represents a real person’s movement pattern.

Decoding the Privacy Mandate

Your job isn’t only technical—there’s a legal mandate. In the Westeros assignment, that’s the Westeros Privacy Law, which states:

“No individual can be re-identified in any publicly-released dataset.”

You must show if re-identification is possible, and if so, recommend or apply privacy-preserving techniques that still allow the organization to draw useful insights.

This legal framing isn’t filler text—it defines how you assess risk, utility, and trade-offs.

Knowing What Success Looks Like

In assignments like this, “success” doesn’t mean “finding a solution”—it means:

• Showing evidence of re-identification
• Demonstrating how utility is impacted by modifications
• Proposing techniques like suppression, generalization, or perturbation
• Arguing whether privacy law is upheld

In short, you’re defending your recommendations like a privacy consultant.

Approaching Each Task Methodically

The assignment may be structured in “Tasks” (like Task 1–4), each building upon the other. Here’s how to break them down:

Task 1: Roleplay, Re-identification, and Linkage

This is your reconnaissance mission. The goal is to prove that the data is not as anonymized as claimed.

Re-identifying Yourself

You’ll be given a character profile with approximate travel times, routes, and companion info. Use filtering tools in Excel or scripts in Python/Pandas to find matching journeys. Search for:

• Time windows (±5–10 minutes)
• Matching stations
• Matching card types

Keep narrowing until only 1–2 CardIDs match. That’s your likely identity.

Re-identifying Your Friend

Use the co-travel pattern. Did your friend always get on with you but got off at a different station? Were they sometimes on a different route but the same time?

Use those patterns to identify another unique CardID.

Performing a Twitter Linkage Attack

This is where things get interesting. You’re given a tweet like:

“Just arrived at the Business District. Time: 15:43, Friday.”

Use this external data to scan the dataset:

• Filter for Friday around 15:40–15:50
• Look for arrivals at “Business District”
• Cross-check other consistent patterns (same CardType, nearby stations, recurring times)

If you find a unique record, you’ve re-identified a public persona—breaching the privacy law.

Task 2: Utility vs Privacy Analysis

This section flips your role: you become a privacy expert, not just a hacker.

Removing Attributes to Preserve Privacy

Which columns in the data actually matter for the company’s goal (e.g., determining number of tap-ons per station per time window)? Hint: CardID is not essential. Neither is CardType in most cases.

Evaluate:

• What can be dropped?
• What generalizations make sense?

Then assess whether re-identification is still possible without those fields.

Making a Privacy Recommendation

Write your own mini-report:

• “Removing CardID prevents linkage attacks like those in Task 1.”
• “Utility is preserved because station-time frequencies are intact.”
• “We recommend this minimal generalization for compliance with Westeros Law.”

Back your claim with evidence. Use charts, counts, or logical reasoning to make your case.

Applying Privacy Techniques

This is the technical heart of the assignment. You’re asked to implement generalization or noise, and compare results.

Generalization via Time Rounding

If you choose to round times to the nearest 5 minutes:

• Write a function (in Python or Excel formula) to round each time value (e.g., 14:12 → 14:10).
• Check whether patterns are still unique.
• Recalculate average tap-ons per station, per time block.

This shows how slight imprecision affects both privacy and utility.

Suppressing Time Granularity

Alternatively, you might suppress the hour, leaving only minutes. This destroys more detail:

• 09:45 → 45
• 18:45 → 45

Clearly, this drastically reduces uniqueness—but at a major cost to temporal analysis. Station usage between 9am and 6pm will be muddled.

Evaluate the trade-off:

• Privacy ↑
• Utility ↓

Choosing the Best Approach

After applying both methods, compare them:

• Which method better preserves the station-time counts?
• Which method better prevents re-identification?

Use metrics or simple examples:

• Original → 5 unique tap-ons at 09:12
• After rounding → 5 tap-ons at 09:10
• After suppression → 23 tap-ons at :12 (across all hours)

Conclude based on legal compliance + analytical utility.

Advanced Privacy with Noise Injection

In some versions of this assignment (like Task 4), you are asked to apply bounded noise, e.g., add or subtract up to 5 minutes randomly. This is a form of differential privacy-lite.

Understanding Bounded Noise

For each timestamp:

• Add a number between -5 and +5 (uniformly at random)
• E.g., 09:45 → any time from 09:40 to 09:50

This makes exact matching impossible, but introduces fuzzy matching.

Then, for analysis:

• Count how many people were shifted out of the 4–6pm window
• Count how many people were accidentally included

Use probability math:

• Each record has a 11/60 ≈ 18% chance of moving out of a 60-minute window when B=5

Calculating Error Margin

For large datasets, noise smooths out. But for small station counts, errors may be significant.

• Original: 50 tap-ons at 09:00–10:00
• Noise may cause ±10% count fluctuation

Determine if the business can tolerate that.

Making a Final Recommendation

This is your consultant moment.

Answer:

• Is this noise level sufficient to prevent Twitter-style linkage?
• Is the accuracy good enough for planning station upgrades?

Based on your analysis, recommend:

• Bounded noise
• Time generalization
• Attribute suppression
• Or a mix (hybrid model)

Support your answer with evidence, not guesswork.

Final Thoughts: Building Reusable Skills

Data privacy assignments like COMP3300 are more than exercises—they mirror real-world data ethics dilemmas. By working through each stage:

• You learn data wrangling using time and location features
• You simulate linkage attacks
• You evaluate utility vs privacy
• You apply privacy-preserving algorithms

Whether it’s transport logs today, or health or banking data tomorrow, the core skills stay the same.

💡Pro Tip: Save your scripts, tools, and logic flows. They’re reusable in future internships or jobs where privacy compliance is not just academic—it’s regulatory and financial.

So next time you see an “anonymized” dataset, don’t take it at face value. Question it. Probe it. Protect it.