In May, one of our board members, Adam Shostack, author of Threat Modeling, Designing for Security, issued a challenge to the Seattle Privacy Coalition discussion list:
“I would like to ask Seattle Privacy to think about privacy more holistically: What threats exist? How are we, as residents and citizens, tracked, monitored, or analyzed throughout the day?”
Adam said something I think we all know: there are so many ways that data is gathered on any one of us at any given time, it’s hard for us to wrap our heads around it, much less muster defenses.
He asked us to take the tool well-known to technical experts, threat modeling, and apply it to ourselves and our fellow Seattle residents. Another board member, Number Six, rose to the challenge, and “Threat modeling for Seattlites” was underway.
Four questions to start with
At our first meeting at Delridge Public Library, Adam got us started by making a chart on a whiteboard with the following columns across the top. Then we proceeded through an imaginary day:
- What are you doing? (The task you want to accomplish, and what information is involved.)
- What can go wrong? (How might your personal information be gathered in ways that are bad.)
- What are your possible defenses? (Are there alternatives you can use to avoid the risk?)
- What are the costs of your alternatives?
We brainstormed “A Day in the Life of a Seattlite” for three hours. The result was an epic spreadsheet.
Somewhat absurdly, with our fitbits, phone-based alarm clocks, CPAP machines, instructions to Alexa, Siri, Google Home, or whoever, and our social media time, it took us an hour to list the potentially gathered data before we would even leave our imaginary homes to start the day.
As we worked through the day, encountering various aspects of the internet of things both private and publicly owned, it emerged that we needed another column. Is the task, and the corresponding use of the technology, required or optional?
For example, it’s easy enough to use a cheap old-fashioned non-connected scale to weigh yourself in the morning, instead of an internet-connected device. Or is it? What if your health insurance requires that you transmit this data to keep your policy? Or, what if you can get a lower premium if you opt to transmit the information?
This means that we need to characterize the data collection: is it easy to avoid? Required by law? Easy to avoid if you’re rich? (In particular, we don’t want to fall into the trap of treating ‘opt-in/opt-out’ as if it’s a
reasonable and nuanced thing.)
It also became clear that who was collecting data needed categorization. We settled with three categories for starters:
A few surprises
I learned a few tidbits during this process that were new to me, although I’ve been tracking privacy issues for a few years now. For example, I learned that some types of car insurance offer usage- or behavior-based policies, in which your driving habits, such as rate of acceleration or speed relative to speed limit, are captured and evaluated to adjust the cost of your policy. Perhaps this is also already happening, I don’t know, but one person had read recently that insurers were considering sending along tips to drivers about how they might improve their driving (and thus lower their premiums).
I also learned that it is already not-uncommon for insurers to insist upon the use of connected CPAP machines or blood sugar monitors, to ensure that the insured is actually using the care paid for. Doctors can also remotely check the status of these devices.
Building out the model
In our second meeting, in July, we began thinking about what we needed to do next. Our data set was fairly messed up, because we hadn’t made any effort to normalize it while brainstorming, and we knew we’d captured only those tasks and data-gathering technologies that those of us in the room knew about. We knew we needed to run our data by many more people before we could consider it complete.
We also started thinking about ways to communicate the information we were gathering. We thought about ways to graph “effort against hurdles,” such as:
- x,y, where x is task and y is Legal Requirement | Benefit | Cost to Avoid | Effort
- Pie charts, where size represents total effort.
- Stoplight charts that could indicate relative risk, and allow people to drill into details if they want them.
We concluded that we definitely wanted to make our data free for others to use and easily available to incorporate into presentations of all kinds.
(Here is a downloadable version of our first very rough cut at the data. Much more to do, and we’ll set it up for proper use when we’re farther along. Threat Model grid v3.)
Trying a walkthrough
We decided to try to walk through fleshing out one example. We selected “Commute.”
An area that we struggled with was how to define when we had enough information to be useful to share with others. This sort segued into discussion about the right level of modeling versus detail. That’s an open issue. Here are the steps we followed just to get something down that we could respond to:
- Choose category: commute.
- Identify Methods of commute.
- List data-gathering technologies.
- List potential defenses.
- List cost of defenses.
|Method||Tech that gathers data||Defense||Cost of defense|
Threats: cameras, microphones, smart apps,
Avoid officers and known cameras
Turn off devices
Join SPC and advocate
Social stigma (tinfoil hat)
Backlash unintended consequences
Loss of convenience of device
|Drive own car|
|Ride corporate bus|
Obviously, we still have a lot of work to do. Here’s how we plan to do it:
- We will meet again in August to finish the commute example, so that we have something substantial to share with reviewers. Watch twitter for an announcement; it will be in Delridge again.
- We’ll present a prototype for feedback to Seattle-TA3M in October and ask for volunteers to help us continue fleshing out the data set.
- We’ll reach out for help finding under-represented communities who can supplement our data set and help us understand what kinds of building blocks would make it useful for scenarios we might not have thought of.
- Finally, we’ll identify ways that our information about the total cost of privacy invasions can be used to help educate policy makers, technologists, and individuals.
This project is fun and fascinating. If you are in the Seattle area and are interested in participating, please do join us for our next meeting in August. We also welcome ideas about how our data set might best be used.