Archive for July, 2017

TA3M Seattle Monday July 17 2017

Greetings!

Techno-Activism Third Mondays (TA3M) is an informal meetup designed to connect software creators and activists who are interested in censorship, surveillance, and open technology. Currently, TA3M are held in various cities throughout the world, with many more launching in the near future. In Seattle, thanks to a special donor, there will be free pizza!

When: Monday, July 17, 2017, 6:30 – 9:00 PM
Where: Tor Office, Pioneer, Square https://goo.gl/maps/aun6E4r4s5E2 80 S. Washington st. Suite 203 Seattle
WA, 98194


Pump.io by AJ (7pm)

Pump.io is a promising project to create a federated social network – think email, where you can have multiple providers that all work together, but for social networking. It stagnated for a while, but the project has recently completed the transfer of governance and code maintenance to the community. This presentation will talk about pump.io’s history (right up to its newly-created community governance), its API, and why it’s pretty freakin’ neat. We’ll end with the work that’s gone out the door in recent releases, the work that remains, and how you can (should?) get involved. Attendees will walk out with an understanding of the historical context behind pump.io, an understanding of how the software works on a technical level, and how it fits into wider social web efforts. No prior knowledge necessary, although a basic familiarity with JSON and HTTP will help.

AJ is a core developer of the Pump.io reference implementation.


Lightning Talks (8pm)

Sign up to give a Lightning Talks by emailing the list. Feel free ask questions of the list too!

Talks:

  • Paul English – Why & How to use 2 Factor Authentication

 


Join the email list!

https://lists.ghserv.net/mailman/listinfo/ta3m-seattle


We’re on Twitter!

To best support the global TA3M meetup, please tweet using the #TA3M hashtag.

@TA3Mseattle
@SeattlePrivacy
@TechnoActivism

Introducing Threat Modeling for Seattlites

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.

Define “required”

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:

  • Government
  • Employer
  • Third-party

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:

  1. Choose category: commute.
  2. Identify Methods of commute.
  3. List data-gathering technologies.
  4. List potential defenses.
  5. List cost of defenses.
Method Tech that gathers data Defense Cost of defense
Walk Camera (Mounted)

Camera (Mobile)

Microphone

SmartApp

Meshnet

RF

Threats: cameras, microphones, smart apps,

Cell

Wi-Fi

RFID/NFC/Bluetooth

Do nothing

Clothing

Avoid officers and known cameras

Stay home

Turn off devices

Airplane mode

Farraday pouch

Policy

Join SPC and advocate

Privacy loss

Social stigma (tinfoil hat)

Financial

Time

Backlash unintended consequences

Stress

Loss of convenience of device

Watchdogging

Meetings

Drive own car
Bike
Carshare
Ride corporate bus

Next steps

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.