Chapter 14 — Privacy foundations
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Heat meters reveal lives"]
N2["14.2 Minimisation and purpose"]
N3["14.3 Aggregation as a control"]
N4["14.4 The consumer IoT baseline"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Heat meters reveal lives"]
N2["14.2 Minimisation and purpose"]
N3["14.3 Aggregation as a control"]
N4["14.4 The consumer IoT baseline"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Heat meters reveal lives]
|
v
[14.2 Minimisation and purpose]
|
v
[14.3 Aggregation as a control]
|
v
[14.4 The consumer IoT baseline]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) recognise personal data in smart-meter and building-automation streams; (2) apply data minimisation and purpose limitation; (3) choose aggregation intervals that serve operations without revealing household behaviour; and (4) relate privacy to ETSI EN 303 645 provision 5.8.
14.1 Heat meters reveal lives
LDHP's IoT meters report each household's heat consumption. Hourly readings show when residents wake, cook, travel or are away — the same inference problem that made electricity smart meters controversial. In many jurisdictions such readings are personal data because they relate to an identifiable household.
An hourly profile from one LDHP meter can show a household that stops heating for ten days in February, which tells anyone reading it that the home is empty. Billing needs none of that. This is why the analytics team's request for five-minute household readings in Maya's case met resistance: at that resolution the data show daily routines, not just consumption.
14.2 Minimisation and purpose
Billing needs a monthly total. Network balancing needs neighbourhood flow, not house-level detail. Fault detection may need individual readings, but perhaps daily and retained for weeks, not years. Writing the purpose next to each data flow forces the question "do we need this granularity?"
Maya's answer to the analytics team's request for five-minute household data put a purpose beside each flow: monthly totals for billing, daily per-household readings kept 60 days for leak detection, and street-level hourly aggregates for balancing. Five-minute data were not collected at all, because no purpose had been defined.
14.3 Aggregation as a control
Aggregating 40 households in a street segment before data leave the gateway removes individual patterns while keeping the operational signal. Aggregation is not perfect: if one dwelling dominates the segment, its pattern remains visible, so engineers check the minimum group size.
Maya's design sets the minimum at 20 dwellings per aggregate for balancing data. A street segment with fewer dwellings, or with one large building using most of the heat, is merged with its neighbour before the hourly aggregate leaves the gateway, so no aggregate is effectively one household's reading.
14.4 The consumer IoT baseline
ETSI EN 303 645 provision 5.8 asks that personal data in transit between a device and associated services be protected (for example encrypted), and provision 6 addresses data protection more generally — informing consumers what data is processed and why. A district-heating meter is not always "consumer IoT", but the provisions are a useful checklist.
For LDHP's meters, 5.8 points to the radio link and the gateway's uplink, both of which carry household readings; provision 6 points to telling residents what is collected and why, which Maya's purpose list already does.
Worked example (synthetic LDHP)
The analytics team requests five-minute household readings "for future machine learning". Maya's response: monthly totals for billing; daily per-household readings retained 60 days for leak detection; street-level hourly aggregates (minimum 20 dwellings) for balancing; five-minute household data not collected without a defined purpose and a privacy impact assessment.
Synthetic case — Lakeside District Heating Plant. The analytics request and retention periods are invented examples.
Errors and limits
Pseudonymising meter IDs does not anonymise them if addresses are kept elsewhere. Privacy law varies; this chapter is orientation, not legal advice.
Exercises
- EX040 — Inferring occupancy. Give two things an observer could infer from hourly heat readings of one flat. Rubric: 3 = two plausible inferences (absence, daily routine, number of occupants); 2 = one; 1 = vague; 0 = none.
- EX041 — Granularity per purpose. For leak detection, propose a reading interval and retention period and justify both. Rubric: 3 = daily (or hourly) with weeks-scale retention and reasoning; 2 = values only; 1 = keep everything; 0 = none.
- EX042 — When aggregation fails. Why might a segment containing one large school and five flats fail as a privacy aggregate? Rubric: 3 = school dominates; flats' patterns lost but school's revealed / group too small; 2 = partial; 1 = vague; 0 = none.
Synthesis
Operational IoT data is often personal data; collect it for a purpose, at the coarsest useful granularity, and protect it in transit and at rest.
Continue studying — chapter 14 of 40
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →