home search a-z help
University of Cambridge Computer Laboratory
FluPhone Project
Computer Laboratory > Research  > Systems Research Group  > FluPhone

News and intro

Research projects

People and staff



Student projects

Local systems info

FluPhone Software Specification

0 Older Revisions


1 The website

1.1 Introduction

The website is written in PHP. It is split into several files, to make it easier to edit.

1.2 Basic structure

The base directory of the live website is located at /usr/groups/fluphone-data/.
The website is located in two directories on the fluphone server. The https site is in directory “fluphone-secure-site-live” , the http files in "fluphone-insecure-site-live".

1.3 Insecure site

The insecure site basically redirects to the secure site. Apart from that, it contains the FluPhone application for mobile phone downloads (which is less error prone via http): fluphone.jad and fluphone.jar. The file current-version.txt contains the version number of the recent download (do not edit manually, it is updated by the build-process, see below).

1.4 Secure site

The secure site contains a multitude of files. Most of these correspond to actual pages on the web, but some don’t.

1.4.1 Actual pages

admin.php: An administration page, only visible to administrators. See below.

check.php: Used for activation checking.

compatiblephones.php: The list with compatible mobile phones.

contact.php: A page with study contact information.

disclaimer.php: A wrapper page for disclaim.php, to show the disclaimer from a link on one of the other pages.

download.php: The download page. This page is only veiwable by logged in users.

help.php: The help/FAQ page.

index.php: The main page.

mypage.php: Personal page for logged-in users. Contains activation code and status of activation.

• passreset.php: Page that lets users reset their password.

receiver.php: Used to receive the data generated by the phones.

studyinfo.php: The study information page.

test.php: A testbed page, for doing test queries. See below.

testpage.php: A minimal page. See below.

trial.php: Download trial version without registering. Currently disabled.

uploader.php: The “upload files” page. This page is only veiwable by logged in users.

user info.php: The consent/registration form.

validate.php: The account validation page. There is no link TO this page, because that link is sent by the registration form when a user registers on the website.

1.4.2 Not actual pages

common.php: Functions common to all pages, including header and footer generation, and so on.

current-version.php: Contains info about the current version and release data. Do not edit this file manually, it is updated by the build-process (see below).

dbfuncs.php: Database functions. This file wraps MySQL and MSSQL, and handles connecting, processing queries and accessing results.

• dhtml.js: Simple dynamic HTML library, e.g. for showing error messages, from http://selfhtml.org

disclaim.php: Outputs the software disclaimer. This is used both on the consent form, and the download page.

login.php: The target for the login form in the standard header. Attempts to log the user in, and redirects back to the page where the user came from.

logout.php: The target for the logout page. Automatically redirects to the main page, to make sure people don’t view login-only pages while logged out.

news.php: separated this from the main page, back when the main page was very long. This contains the text of the “news” section on the main page.

1.5 Basics

All the pages have the same header and footer. These are written in functions inside common.php.

Most pages rely on the database functions inside dbfuncs.php, but this file is included by common.php because some of the functions there need the database functions. Even the insecure site files include the common.php file from the secure site, for simplicity.

1.6 Database specifics

The database consists of a set of tables, whose names and column names are visible in the dbfuncs.php file. The tables are:

fluphone users - this table contains user id, user name (email address) and a password hash and the salt for the password hash.

fluphone activation - this table contains user id, activation code and Bluetooth MAC address of a user.

fluphone pending users - this table contains all the information that a user inserted into the registration script.

fluphone user info - this table contains most of the information a user inserted into the registration script, except for user name and password, which is stored in the fluphone users table.

fluphone encounters - this table contains encounter information, as user id and Bluetooth MAC address, which Bluetooth MAC address was seen, and when.

fluphone symptoms - this table contains symptom reports, and the user id of the one who reported them.

fluphone locations - this table contains geographic locations, and the user id of the one who reported them.

There is also the administrators table, which contains the email addresses of those few users that are considered “administrators”, and therefore can see the admin.php page.

1.7 Specifics about certain pages

1.7.1 admin.php

This is a simple administration page created to view the tables as seen by the website. All the users’ information is available from here. Because this page can be used to find out quite a lot about every participant in the study, this page is hard to get to. It makes sure to check that the user who is accessing it is an administrator, and if it is not, will simply forward the user to the main page.

1.7.2 check.php

This “page” is used by cell phones to check the activation code and Bluetooth MAC address, and see that they match. It was also designed to return a hexadecimal string, that was to be used as an encryption key for whatever system was being used to encrypt the data. Since no encryption was implemented, this feature is unused.

1.7.3 contact.php

This page contains contact information. That is its only purpose.

1.7.4 disclaimer.php

This page wraps the disclaim.php disclaimer as a web page. It is used at one point when the user is supposed to be able to click a link and get the disclaimer in a different browser window.

1.7.5 download.php

This is the download page. It contains the download link and instructions on how to install and set up the fluphone application on a mobile phone.

1.7.6 help.php

This is essentially a FAQ page. It is meant to be expanded when it new questions come up.

1.7.7 index.php

This is the main page. Its text is more or less defined by the study protocol document, and care should be taken when editing the main text of this document.

On the other hand, the news.php file which contains the news items on the right hand side of the page is not specified in the study protocol and is therefore easier to change.

1.7.8 mypage.php

This page is where the user can find his/her activation code, and whether or not he/she has managed to activate their phone. This is also where the user can change certain data about themselves.

1.7.9 receiver.php

This “page” accepts new data from cell phones. It takes the given file and places it in the secure fluphone folder’s subfolder uploads. From there, arcdae processes the files. Just as check.php was intended to provide the data encryption key to the FluPhone application, receiver.php was intended to use the encryption key to decrypt the data before saving it to the uploads folder. The encryption parts of this have not been implemented.

1.7.10 resetpass.php

This page lets users reset their password by sending themselves an email with a reset code.

1.7.11 studyinfo.php

This page was originally in the study protocol, but the decision was made to make it a part of the main page. Then, after getting the suggestion that it should be a page of its own again, it was made into its own page. It contains information about the study in questions-and-answers form.

1.7.12 test.php

This page was a testing ground for functions. There is no link to it, and primarily it should do nothing.

Preferably, this page, like the admin page, shouldn’t exist here, but possibly in a non-live version of the website.

1.7.13 testpage.php

This page was set up so that people could see what the application downloaded when doing registration checks. This file has since been replaced by check.php.

1.7.14 uploader.php

This is an uploading script that has had (roughly) this shape and form. It is used to upload whole database files to the server, for those users that can’t or won’t let their phones send data via GPRS.

I have not changed this file much, which is why it still requests the user name and password from the user uploading. Which is rather redundant, because you have to be logged in to see the page.

I’m not sure if this page works properly. But if it does, it should upload data to the uploads/<user name>/ folder.

1.7.15 user info.php

This is the file that generates both the registration form, and the consent form. It also generates the email with the validation link, when the user has filled in the registration form correctly.

1.7.16 validate.php

This is the page that validates a registration. It also makes sure to log you in, just so that the user doesn’t have to do that, too. A user’s activation key should be sent to them via email, just in case. This is the logical file in which to do that. It is only (successfully) accessed once per user, and it creates the activation key. The key doesn’t exist before the user gets to this page, which makes it impossible to send the activation key before this.

2 The FluPhone application

2.1 Introduction

The application is written in Java/J2ME. JSR-82 is used for Bluetooth, JSR-179 for GPS. IIs is signed by Thawte (see below). An antenna script is available to build the application (see below).

2.2 Basic structure

There are a lot of helper files, which are mostly located in their own folders inside the src/ folder, The GUI, for instance, is located in the src/gui folder. But the Settings.java, FlubookMIDlet.java and Dispatcher.java files are not. The FlubookMIDlet.java file contains the main class, where all execution starts. The Settings.java file contains global settings, some of which can be changed in the class, but most are set by the build system.

2.3 GUI

The gui code is a bit of a mishmash where some of it (mainly old code) is written using J2ME forms, and some of it (mainly code written after rewriting the symptom reporting form) is written as a subclass of FPForm, which is a subclass of Canvas. This makes the different “windows” look different. The FPForm class has functions for things like outputting text lines, supporting a scroll bar, drawing png images, etc. 

2.4 Settings

The settings.java class contains settings to affect the programs behavior. The things that can be changed are indicated by comments in the class file. Things usually changed often (e.g. debug on/off), can be specified at build-time and do not need a change of the source code.

2.5 Getting data

The code gets/generates data in the gps/GPSReader.java8, bt/BTUtility.java and gui/SymptomForm.java files. The Bluetooth an GPS readers are run from the dispatcher. The symptom form is meant to run as part of the program’s gui. All these generate their data, and then hand it off to the dispatcher.

The Bluetooth and GPS scanners also make entries, when no Bluetooth devices were found, resp. GPS is not available (e.g. indoors). Thus, we can distinguish between not scanning and scanning, but not detecting anything.

2.6 The “Dispatcher”

The “dispatcher” is a set of functions that processes data the different parts of the code create. It implements the main loop for getting and processing data in its own thread. For stability reasons, it serializes the access to Bluetooth, GPS, the RecordStore and the network as much as possible. This also has the advantage, that Bluetooth and GPS queries are synchronized (for each Bluetooth scan there is a GPS scan).

The dispatcher also checks to see that the data was delivered properly and periodically goes through the data bases to find any data not sent and sends those again.

2.7 Databases

This is a J2ME-specific persistant storage where each “database” is a single table with an integer key, and a byte-array value. The application maintains four such databases: one for GPS data, one for Bluetooth data, one for symptom data, and one for settings. Currently the only setting saved is the activation code.

2.8 Encryption key setting

I have set up a setting for the encryption key used to encrypt the data, although not specified what kind of encryption will be used, or anything like that. This encryption key should not be stored in the settings data base, because that makes it very easy to get at.

The encryption key setting is set by the activation process, where an ok signal also includes the encryption key. Right now, the response is the same for all users, and that value should not be used as an actual encryption key.

2.9 GPS code

There are two methods to retrieve the GPS location via the JSR-179. The synchronous method is simple to use, but tended to freeze after some time on the Nokia 6730 phones.
Thus, we switched to the asynchronous version.

GPS can be enabled or disabled at build-time. When enabled, it is synchronized to the Bluetooth scans.

2.10 Fake Disease

The fake disease experiment simulates the spread of diseases via mobile phones transmitting disease info by Bluetooth. This function can be enabled or disabled at build-time. The java classes are located in the fakedisease package.

When enabled, a Bluetooth service is registered in the phone, allowing other phones to connect and transmit disease code as clients. This function is controlled by the dispatcher, client and server behavior is also implemented sequentially.

The implementation supports multiple diseases, defined in the settings.java class. Three different compartmental models are available: SI (for the baseline disease), SIR, SEIR.
Together with the infection, a history is transmitted containing all the phones, the disease has been on before. This is saved in the phone's persistent memory and can be dumped to a file on the memory card (Dump file menu option). If GPRS is enabled, changes in infections are automatically transmitted to the server. These files are stored at: /usr/groups/fluphone-data/fluphone-secure-site-live/uploads/

This function introduces stability issues. To improve stability, the service scan is disabled and replaced by a static list of devices, that have the service. It is easy to use this in a small study, however phones cannot be added dynamically. To change to service scans, just replace the usage of class DiseaseServiceDiscovererList (this contains the list of device addresses) with DiseaseServiceDiscovererScan.

Another problem is, that the server component, which accepts the Bluetooth connections, only runs for about 400 times. After that, an OutOfMemory exception is thrown. Anyhow, in most situations, 400 times is enough for one day.

2.10.1 Disease Configuration
D0 (base line): SI,   p=1.0
D1 (SARS): SEIR, p=0.8, a=24H, t=30H
D2 (FLU): SEIR, p=0.4, a=48H, t=60H
D3 (COLD): SEIR, p=0.2, a=72H, t=120H

p is probability of infecting another device.
a is the duration in the exposed state.
t is the duration in the infectious state.

2.11 Antenna Build System

To produce builds of the FluPhone application, ant and antenna are used. This is generally recommended instead of building with an IDE, e.g. with Eclipse.

- Download and install the J2ME Wireless Toolkit from Sun,
- Download antenna from http://antenna.sourceforge.net
- Download proguard from http://proguard.sourceforge.net
- Create a link to the antenna-bin-xxx.jar in the parent folder:
 ln -s /install/path/antenna-bin-xxx.jar ../antenna.jar
- Create a link to the WTK root directory in the parent folder:
 ln -s /install/path/WTK2.5.2 ../WTK
- Copy the proguard.jar to the WTK/bin folder

- ant clean: remove build files
- ant pack: compile and create jar/jad files with debug info. Use this for development.
- ant obfuscate: compile and create obfuscated jar/jad files without debug info.
- ant run: run the previously created jar file
- ant sign: obfuscate and sign (see the section about the digital signature below)
- ant deploy: creates all files necessary for distribution on the fluphone.org site and installs it on the live site (CAREFUL!).

Increase the "midlet.version" number in build.xml before using this function, then the update will automatically be detected by older versions and the user is prompted to update.

You can also define parameters to enable/disable certain functions. For deploy, you should use the defaults (no additional parameters)!

Parameters and their defaults:
- BT_ENABLED=true (Bluetooth scanning enabled/disabled)
- BT_SCAN_PERIOD=300 (sec. to wait after scanning)
- BT_SCAN_MAX_VAR=60 (random sec. to wait after scanning, is added to above value)
- GPRS_ENABLED=true (enable the transmitting of data to the server in real-time)
- GPS_ENABLED=false (GPS on or off)
- LOG_COUT=false (if true, writes log messages to the console, good for debugging with the emulator)
- DISEASE_ENABLED=false (enable for fake disease experiment)
- D0_SEED=false (makes an initial infection on disease D0, enable above parameter)
- D1_SEED=false (initial infection on D1)
- D2_SEED=false
- D3_SEED=false
- VERSION: do not change this on the command line, rather edit the property "midlet.version" in the build.xml file.

E.g. to compile, obfuscate and sign with GPS, fake disease and an initial infection with D2:
$ ant -DGPS_ENABLED=true -DDISEASE_ENABLED=true -DD2_SEED=true sign

2.12 Digital Signature

Signed MIDlets can be granted less strict permissions. Thus, the user is bothered with less questions for his approval.

For the FluPhone application, the CL has a certificate from Thawte (can be used for other MIDlets as well). To be able to sign FluPhone with the "ant sign" command, you have to import the certificate into your keystore. You can use the keystore file in the Flubook_1.1a directory (e.g. copy it to ~/.keystore to make it your default). The file Flubook_1.1a/code-signing-howto.txt contains details on the certificate.

2.13 Phone Compatibility

The FluPhone J2ME application is currently compatible with a range of Noia Symbian phones. The file Flubook_1.1a/phone-compatibility.ods contains the complete list. Representative phones (for each platform, each display resolution, ...) were tested via Nokia's Remote Device Access.

3 The arcdae application

3.1 Introduction

The arcdae application runs on the web server, processes the data that the participants’ phones collect and stores the data in the database.

3.2 Basic structure

The arcdae application is in fact a set of applications. The first is the arcdae-start shell script, which ensures that arcdae is run at the right location (the secure fluphone website directory). Then there is the arcdae application. It looks for files to process in the "uploads" directory and calls the arcdae-helper application on each. It should be noted that while the arcdae application does not search for user-uploaded data base files10, the arcdae-helper application can parse these files.

This helper application parses the files given to it, and both uploads the data to the database, and moves the files to either the “processed files” folder or the “suspicious files” folder. Uploading the data into the database involves using a few PHP functions located in the file arcdae-funcs.php, which is intentionally excluded from the secure website part of the SVN repository, because it is included in the arcdae part of the SVN repository. The reason for using PHP, is so that the functions in arcdae-funcs.php can utilize the current settings of dbfuncs.php, which determine if the MSSQL or MySQL database is being used, what the tables are called, what the table columns are called, etc.

3.3 Running arcdae

arcdae is run from a cronjob on the www-fluphone server once per hour. It is installed in tn266's crontab:

0 * * * * cd /usr/groups/fluphone-data/arcdae && ./arcdae-start

3.4 Daily DB Dumps

The database is dumped to flat text files each day, by the /usr/groups/fluphone-data/arcdae/dbdump.php file on the fluphone server. It is a small script that dumps the three database tables for contacts, locations and symptoms. These text files can then easily be parsed using tools like awk to do offline number crunching with.

It is run by a conjob (tn266's crontab):

30 4 * * * cd /usr/groups/fluphone-data/arcdae && php -f dbdumps.php

The dumps are stored in /usr/groups/fluphone-data/dbdumps/

4 A note on data encryption

As it stands, the software that runs on the phone uses SSL to encrypt the data as it is sent to the server. This does cost somewhat, as the overhead for transferring data this way regularly exceeds 95%. There are three possible ways of encrypting the data, all with their own pros and cons. Study was done before the application was able to use SSL (we were unaware of how to set the phones we were experimenting with so that they would accept the fluphone.org SSL certificate). There will be pros and cons of different encryption schemes in general.  

4.1 Symmetric key encryption

The first scheme I’ve looked at is to use a symmetric key cipher12 to encode the data sent to the receiver script. The good thing about using symmetric key encryption is that something like CFB13 can be used, which doesn’t neccesarily add any significant overhead14. There are several implementations of AES/Rijndael online, besides the BouncyCastle.org implementation. The bad thing about symmetric key encryption is that it produces a key distribution problem. Using the same key for all users, and storing it in the application is not acceptable, because then an attacker would only have to register once and download and analyze the application to find the encryption key.

4.2 Public key encryption

Another scheme to use public/private key encryption16 to encode the data sent to the receiver script. The good thing about using a PKS, is that it doesn’t create a key distribution problem, since every user can use the same key without problem. No other implementations than BouncyCastle.org for RSA or any similar such PKS. The bad thing about using a PKS, is that it adds (potentially a lot of) overhead. Also, getting a working implementation for J2ME is a problem.

Another bad thing about using a PKS is that they are generally very slow, and require a lot of processing. This could completely kill battery time for the participants. Just like using SSL to encrypt the AES key, as described below, a PKS could be used the same way. This hybrid model would cut down on overhead, while also cutting down on the cost of encryption.

4.3 SSL

Using SSL, aka HTTPS. The good thing about using HTTPS is that it’s already implemented. Just add “s” after “http” in the URL in the Settings.java and Settings.xml files, and it’ll just work. No key distribution problem, no changes to the current code, no changes to the receiving code, to make it able to decrypt. The bad thing about using HTTPS, is that it doesn’t always seem to work. Using HTTPS requires the correct root certificates to be installed on the participant’s phone, and the root certificate on which www.fluphone.org relies, is sometimes installed on phones, and sometimes not. Even when it is installed, such as on the test phones, it may have to be turned on manually by the user.

Another bad thing is that using HTTPS causes a jump in overhead, from some 1K, to 2KB or 9KB. This causes the data usage estimate to jump from 0.5 MB20 per day (pure HTTP) to maybe 4.5 MB per day, or from 15 MB per month (30 days), to 130 MB per month21. That would most likely be a dealbreaker for most participants. One possible solution to the overhead problem, is to let the activation check go via HTTPS, which encrypts the data traffic, and let the application get the encryption key along with an OK signal regarding the activation check. This encryption key would then be used by a symmetric key system, as described above. This would minimize the overhead and solve the key distribution problem in one go. A downside is, of course, that the receiver script would have to handle decrypting the data as it comes in.

4.4 BouncyCastle.org - why it’s not being used

When attempting to use BouncyCastle.org’s implementation of encryption. It took more than 10 minutes22 to compile the code. This was regardless of whether or not the code contained errors, in which case, of course, the compiler spat out error messages after 10 minutes. These errors had then to be fixed, and the code compiled again - taking another 10 minutes...you get the picture.

5 BTStressTest

There are a couple of issues with the JSR-82 (Bluetooth API) implementation in the J2ME. Although the functions seem to be quite standard and well tested, bugs can be observerd in "extreme situations", like:

- running the functions repeatedly (a lot of times),
- moving in and out of reception range during operations,
- having a LOT of devices in reception range (~10).

Additionally, some phones keep popping up alerts for every connection (e.g. Nokia Series40). Signing the app does not help.

5.1 Functionalities

To test the Bluetooth implementation on a certain phone, the BTStressTest app was developed (same SVN location as Flubook_1.1a). It can do the following tests:

- Repeated inquiry scan (scan for other Bluetooth phones repeatedly)
- Repeated service scans (query services of a selected device repeatedly)
- RFCOMM client/server (one phone sends data, another receives, via RFCOMM protocol)
- RFCOMM Burst (same as above, but in each repeated connection, only a small packet is transmitted)
- L2CAP client/server (
one phone sends data, another receives, via L2CAP protocol)

- L2CAP Burst (same as above, but in each repeated connection, only a small packet is transmitted)
- DTN Sim (combination of functions: 1. inquiry scan, 2. service scan, 3. transmit data via RFCOMM, 4. open RFCOMM server for a couple of minutes)

5.2. Identified Problems

5.2.1 Problem 1

Device A: just sitting there (Bluetooth on and visible)
Device B: Repeated service scans on A
Device C: Repeated service scans on A
Device D: Repeated service scans on A

Then I moved B, C, D around, especially to the edge of Bluetooth reception.

As a result, B jammed.
B was stuck in the service scan (the Bluetooth symbol flashes)

5.2.2 Problem 2

A: Bluetooth server (RFCOMM), accepts connections and reads until end-of-file. Then, accepts next connection, and so on.
B: BurstClient on A (continuously connects to server, sends 512 bytes of data, closes connection, waits a few milliseconds and starts over again).
C: BurstClient on A
D: BurstClient on A

Then I moved B, C, D around, especially to the edge of Bluetooth reception.

As a result, A and B jammed.
A did not accept any Bluetooth connections any more.
B was stuck in connecting (the Bluetooth symbol flashes)

5.2.3 Problem 3

A: Server (RFCOMM or L2CAP)
B: BurstClient

Leave it running for a couple of minutes, no movement.
At about the 400th - 470th iteration:

A: jams in AcceptAndOpen, not recoverable by program restart or BT off/on
A: OutOfMemory Exception

6 Database Tables

6.1 dbo_fluphone_encounters

|     Reporter      |    ReporterMAC     |      SeenMAC      |      Timestamp       | DataSourc | ServiceClas | MajorCla | MinorCla |
|                15 | 002669AA25F3       | 00236CAC2900      | 1270810140558        | gprs      |     3670016 |      256 |       12 |
|                33 | 0025D0E080DA       | 00236CAC2900      | 1270810054100        | gprs      |     3670016 |      256 |       12 |
|                32 | 002669AA04F3       | 00236CAC2900      | 1270810033732        | gprs      |     3670016 |      256 |       12 |

|   LocalFileTime   |  ServerFileTime   |
| 1270810154        | 1270809922        |
| 1270810058        | 1270809907        |
| 1270810043        | 1270809913        |

- If SeenMAC==000000000000, then no device was detected at that time.

6.2 dbo_fluphone_locations

|        uid        |     longitude     |     latitude      |      Timestamp       |    DataSource     |   LocalFileTime   |  ServerFileTime   |
| 29                | 0.000000          | 0.000000          | 1270800428877        | gprs              | 1270800440        | 1270800316        |
| 29                | 0.095367          | 52.212421         | 1270799109631        | gprs              | 1270799122        | 1270798997        |
| 29                | 0.100296          | 52.216113         | 1270798892929        | gprs              | 1270798906        | 1270798781        |

- the "uid" field corresponds to the "Reporter" field of the encounters table.
- If longitude==0.0 and latitude==0.0, then the GPS location could not be determined at that time.

6.3 dbo_fluphone_symptoms

|     Reporter      |      Timestamp      |    Q1     |    Q2     |    Q3     |    Q4     |    Q5     |    Q6     |    Q7     |    Q8     |
|                27 | 1270809347370       | yes       | yes       | no        | no        | no        | no        | no        | no        |
|                27 | 1270742190794       | no        | no        | no        | no        | no        | no        | no        | no        |
|                29 | 1270740581154       | yes       | no        | no        | no        | yes       | no        | no        | no        |

|    Q9     |    Q10    |    Q11    |    Q12    |    Q13    |    Q14    |    Q15    |    Q16    |   SymptomStartDate   |    FeverStartDate    |
| no        | no        | no        | no        | no        | yes       | no        | no        | 1270767600000        | 0                    |
| yes       | no        | no        | no        | yes       | yes       | no        | no        | 1270681200000        | 1270681200000        |
| yes       | no        | no        | no        | yes       | yes       | no        | no        | 1270681200000        | 1270681200000        |

|      DataSource      |    LocalFileTime     |    ServerFileTime    |
| gprs                 | 1270809426           | 1270809290           |
| gprs                 | 1270742232           | 1270742098           |
| gprs                 | 1270740772           | 1270740645           |

- Q1: fever (yes/no)
- Q2: blocked/runny nose (yes/no)
- Q3: cough (yes/no)
- Q4: sore throat (yes/no)
- Q5: headache (yes/no)
- Q6: muscle and/or joint pain (yes/no)
- Q7: chest pain (yes/no)
- Q8: stomach ache (yes/no)
- Q9: diarrhoea (yes/no)
- Q10: nausea (yes/no)
- Q11: chills (yes/no)
- Q12: weakness (yes/no)
- Q13: eye irritation (yes/no)
- Q14: not used
- Q15: Did your fever come suddenly? (yes/no/unsur)
- Q16: Encountered anyone with flu last week? (yes/no/unsur)

6.4 dbo_fluphone_activation

|        uid        |       code        |        mac        |
|                 6 | 2110872393        | not set           |
|                 7 | 964089716         | 0025D04B2B3F      |
|                 8 | 1025654460        | EC9B5B009E8F      |

- uid is same as Reporter above
- code is the activation code
- After registration on website, mac is set to "not set". When activation
  is completed, it contains the Bluetooth MAC address.
6.5 dbo_fluphone_users

|        uid        |       name        |   password_salt   |   password_hash   |
|                 6 | fluephone@yoneki. | YvAS1UewVWNZnpmcj | d73134b97e1876332 |
|                 7 | jonread@liv.ac.uk | SDo7F8aRUMSWeD0xl | b4a1b38c203d56c83 |
|                 8 | m.g.semple@liv.ac | 5IGqGrkibpblFKVbp | 62cbcc9127f24a0ad |

6.6 dbo_fluphone_pending_users

|     PendingID     |     Username      |     Password      |       CRSID       |        DOB        |        Sex        |   PostcodeHome    |
|        1261894705 | blah@blah.com     | sdljfsdlkj        | df764             | 1970-01-01        | male              | BS1 1BS           |

|   PostcodeWork    |     UniLiving     |   ShareKitchen    |    Occupation     |      College      |       Phone       |  NetworkProvider  |
| CB3 9DJ           | yes               | 1                 | Undergraduate of  | Not applicable    | nokia2730         | 3                 |

|    PaymentPlan    |    HeardAbout     |
| postpay           | tv                |

6.7 dbo_fluphone_user_info

|        uid        |     PendingID     |       CRSID       |        DOB        |        Sex        |   PostcodeHome    |   PostcodeWork    |
|                 6 |                 6 | Not set           | Undisclosed       | nope              | SG8 9BL           | CB3 0FD           |
|                 7 |                 7 | Not set           | 1970-08-15        | male              | cw12 3es          | ch64 7te          |
|                 8 |                 8 | Not set           | 1968-03-10        | male              | CH42 8LH          | L12 2AP           |

|     UniLiving     |   ShareKitchen    |    Occupation     |      College      |       Phone       |  NetworkProvider  |    PaymentPlan    |
| no                | 1                 | Postgraduate or   | Not applicable    | nokia2730         | 3                 | prepay            |
| no                | 1                 | "Employed, full   | Not applicable    |                   | 3                 | postpay           |
| no                | 4                 | Undergraduate of  | Not applicable    |                   | T-Mobile          | postpay           |

|    HeardAbout     |
| email             |
| email             |
| email             |

6.8 Time synchronisation

Each phone might have a different time (at least a couple of minutes). To estimate the difference to the time in the server, we do the following:

1. When a file is transmitted via https, the phone adds its current time to the filename (microseconds since 1970).
2. When the receiver.php saves the file, it adds the server's timestamp (seconds since 1970).

Assuming, that it only takes a small amount of time to trasmit a data file, the difference between the two filestamps tells us the offset of the phone's time.

3. Both timestamps are stored in the database for encounters, symptoms, locations (seconds since 1970).


Contact: FluPhone Project Team email: flu-phone@cl.cam.ac.uk