Securing my data for international travel

By Regus Patoff, Anonymous Person

I have a complicated international trip coming up, and I want to protect my private information from border officials. Abroad or in the US, border officials can and do abuse their discretionary power to interrogate travelers, seize electronic devices, demand passwords, and generally inquire into matters unrelated to border safety. This post summarizes my plan. Later I’ll let you know how it went.

 

I’m hard to find online

I started preparing by making my Twitter account anonymous and taking down my personal blog. Now I don’t pop up in Google, so I’m protected from a casual search on my name. It took a full year for my name to fade off of Google, so start this in advance if you want to do it.

I’m not a “target”

I am not important enough to need to worry about state security agencies, and this post isn’t for people who are. . I just want to provide zero information to border guards. All they need to know is that I’m not carrying weapons on a flight, and beyond that, in matters of my heart and mind, they can piss off. My border crossings double as resistance to the erosion of my legal and human rights.

I carry a lot of electronic equipment with me when I travel, though no more that what a typical business traveler might. Basically, a phone, a tablet, and a laptop, though no laptop on this trip . I’m leaving behind many computer services that I need to stay in touch with:

  • A computer server providing websites for myself and others, and also DNS. I need administrative access to that even when traveling.
  • Hidden Tor services that I host.
  • Other various backup services hosted by a major cloud services provider.
  • My personal email hosted by another cloud services provider.
  • A backup email provider, a big one, just in case.
  • My private cloud that I host, full of information that I like to have available all the time and on any device, but which I don’t want to trust to a vendor.

Devices I’m taking along

These are the devices I’ll be carrying:

  • An Android phone (cell and Wi-Fi connectivity, with an add-on SD-card for storage). Serves as a phone, of course, but also as a music player.
  • An Android tablet (Wi-Fi connectivity, with an add-on SD-card for storage). This, with an accessory keyboard and mouse, serves as a full-service computer substitute, an ebook reader, and a mapping+navigation device.

Why Android?

I know that iOS devices are regarded as more secure by the extremely careful and/or extremely threatened. I’m not an Android expert who can improvise my own iOS-equivalent security. However, I am not trying to defend myself against intelligence services at the border, I’m just trying to beat border guards. Stock Android with encryption will work. I prefer Android because I like to tinker, so that’s what I’m taking. Loyal iOS users reading this will have no trouble translating its suggestions into the language of their favorite mobile platform.

I’m also carrying a philosophy

Don’t be a hostage to your stuff. My travel devices are cheap and/or old enough to make losing them to government seizure acceptable. It’s the data that matters.

Sensitive data

My data protection strategy is to keep my sensitive data in the cloud where I can access it when it is safe to do so. My sensitive data in this case includes:

  • Contacts
  • Email
  • Calendar
  • Bookmarks
  • Browser history
  • Passwords
  • Cryptographic keys
  • Photographs

Backups

I’ll be keeping data of this sort in the cloud (private or public) and accessing them through secure connections (HTTPS, SSH) or by secure synchronization services (Android sync, Google Drive, Mozilla sync). I also store configuration profiles for important applications (for example, email) so I don’t have to remember them. I have made several layers of backups for everything, in several locations, including my private cloud and a virtual machine I pay a cloud services provider for. If the sync services fail or I lose my devices, I’ll be able to access my important data from any Internet-connected computer.

Passwords

Passwords are a problem. I use around one hundred strong, random passwords for various websites and services, which means I have to use a password manager to keep track of them. I don’t care much for the hosted password management services, so I run my own and sync its database through my private cloud. My Android devices automatically sync up with my password database.

However, to be truly independent of particular devices and safe from government seizure, I need to carry a few strong but unforgettable passwords in my head. I use one to access my private cloud, where everything important is stored. I have another memorized password for my password database, which is itself encrypted, and one more for my backup email account. In general, the correct-battery-horse-staple (https://xkcd.com/936/) method of password building is the way to go for these master, memorized passwords.

Non-sensitive data

In addition to the sensitive data, I’ll be carrying some relatively bulky, non-sensitive stuff:

  • Music files
  • Map files
  • Ebooks

I’ll keep this data on the external MicroSD cards in each device, unencrypted. I’ll avoid carrying anything controversial. These things are already backed up at home, but are too bulky to sync if I lose them. Worst case scenario, I can’t listen to LCD Soundsystem on the funicular. It’s something of a technical trick, though, to keep sensitive data from being saved to those cards by the ever-helpful Android operating system.

My pilot protocol

Putting all this together, here is my planned device security protocol for before and after entering a country:

  1. Before: Factory reset the devices. Do not begin device setup.[Non-random thought: Will border officials be annoyed to find a factory-reset device? I imagine the Israelis would be annoyed, or the authorities in Urumqi. An alternative would be to set up a false/alternative identity on the device, which would take planning and time. A secondary and very uninteresting Google account would do the trick. However, DO NOT GET CAUGHT LYING TO THE AUTHORITIES. When I was living in {oppressive regime}, I planned my lies very carefully and kept them effectively unfalsifiable.]
  2. After border crossing, set up the devices using Google account credentials.
  3. Choose option to restore from a cloud backup, including apps.
  4. Finish setup, and when prompted, have the device restore all apps.
  5. Retrieve email configuration from the cloud.
  6. Set up SSH keys.
  7. Re-sync browser bookmarks.
  8. Rebuild the home screen, which in my experience is not restored.

Coming soon: How this worked in a “liberal democracy” with draconian security measures, and in an “undemocratic regime” with the same.

 

TA3M October 16, 6pm-8pm UW CMU 104

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, October 16, 6-8pm
Where: University of Washington Seattle Communications Building CMU 104.

We are looking forward to a great talk from Michelangelo van Dam about the new privacy rights and international effects of the General Data Protection Regulation in the EU. Michelangelo is a senior software engineer, co-founder and CEO of In2It, community leader at PHP Benelux, and a coach with Coder Dojo.

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

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.

Here’s a template for universal video surveillance, but at least it’s GREEN!

Isn’t this a lovely logo with a lovely message? Silicon and chlorophyll, kissed by the sun in a circle of life….

But the solar lighting company Sun-In-One has more to offer than just lighting. It also offers street lamp modules with motion detection, video surveillance, and mesh networking. Now cities can light roadways and record every movement of their citizens — all in one, convenient, extensible package. Image analysis software included!

Attention Seattle Police Department: Get those facial recognition databases ready.

Attention Seattle City Light: The ATF won’t have to work through you anymore to put up illegal cameras.

Read the product brochure for details.

[pdfviewer]https://seattleprivacy.org/wp-content/uploads/2017/06/SkyEye-Street-Light-System-2.pdf[/pdfviewer]