Overview The goal of this app is to automatically assess and ground truth individual vulnerability so that disaster resource

management decisions can be made more intelligently. Vulnerability in the face of a specific disaster has many components, including: 1. Where does the person live? This will determine both how they are affected by geographically-varying disasters as well as their ability to escape. 2. What economic resources does the person have access to? 3. What other resourcesvehicles, generators, food, etc.does the person have access to? 4. Does the individual have friends or family nearby and available to help or look after them? Our end goal is to develop an app capable of measuring multiple dimensions of vulnerability without requiring explicit user input, since users own responses may be lacking or misleading. To assess vulnerability without explicit user input, we want to gather information such as the users activity level, location traces, calling and texting patterns, and potentially scans of nearby devices (wifi, bluetooth, nfc) to determine social, physical, and network connectedness. To ground truth the automatically-gathered data, we want to present each participant with a survey asking them about some of the things we are trying to estimate automatically. So this project has two separate parts: 1. A front-end survey-like interface collecting a set of specific facts about each participant, and; 2. a back-end information gathering component which collects the information needed to automatically estimate vulnerability. Both of these components should reliably and efficiently report data to a backend server for later processing and analysis. If we decide to deploy entirely on PhoneLab, we can use the PhoneLab data collection API for this. Otherwise we will need to develop our own approach, or adopt the strategy of tools like funf that piggyback their data collection on existing reliable data collection tools like Dropbox. The project deliverable should be an Android app that we can deploy on PhoneLab and, ideally, more broadly to determine how to use automatically-gathered user data to estimate individual vulnerability. Frontend Survey Interface Once installed, the app should ask each user to complete a short manual survey asking them a set of questions designed to directly establish their level of vulnerability. Whenever possible, however, we want to do this without revealing that this is the goal of the survey, to avoid biasing responses. So, as an example, instead of asking Do you have friends or family that live nearby that could help you if you needed it during a disaster?, we could ask How many friends and family do you have that live nearby?, or How far away does your closest good friend or family

member live?, or How often do you see friends or family? We will have to work on the survey language carefully in collaboration with Mike, Chris Renschler (UB Geography) and potentially people at FEMA to ensure that it captures the aspects of vulnerability we are interested in, but potential questions include: 1. How old are you? 2. How physically active are you? 3. Do you have any medical conditions that require regular medication or trips to the doctor? 4. Do you require assistance getting around? 5. What kind of vehicle do you drive? 6. What is your rough income level? 7. Do you have at home any of the following items: a. generator b. crank-powered radio c. non-perishable food d. etc. 8. How socially active are you? (See examples above.) Backend Data Collection In parallel, we want to be periodically gathering data about the users movement patterns, use of the phone for socializing (calling and texting), contact with other devices (as a proxy for people), and activity level. At minimum it may be useful to collect the following: 1. Location. Android provides a way to gather location data triggered by other apps via a passive location provider, but we may want to trigger location updates periodically when not triggered by other apps. However, the rate at which location information is collected must be kept reasonable in order to avoid excessive battery drain. 2. Activity. The Google Services package provides an activity recognition interface that uses the sensor to classify the users activity into categories such as still, walking, driving, etc. This information and the associated confidence levels should be recorded. 3. Communications. Both use of the phone and text messaging should be monitored: not for content, but for the metadata. How many phone calls does the user place, potentially the numbers so that area code information can be used to roughly geolocate the recipient, as well as similar information for texting. Our goal is to use this information to try and guess how socially-connected each user is. 4. Contact with other devices. Bluetooth scans may potentially provide a way to scan for nearby electronic devices, under the (potentially questionable) assumption that this information may be able to identify nearby users that both (a) travel with their devices and (b) leave these devices discoverable via Bluetooth.