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 https://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.
Setup:
- Download and install the J2ME Wireless Toolkit from Sun, https://java.sun.com/products/sjwtoolkit/download.html
- Download antenna from https://antenna.sourceforge.net
- Download proguard from https://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
Targets:
- 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 (RFCOMM or L2CAP)
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
or
A: OutOfMemory Exception
6 Database Tables
6.1 dbo_fluphone_encounters
Example:
-------------------------------------------------------------------------------------------------------------------------------------
|
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 |
-----------------------------------------
Notes:
- If SeenMAC==000000000000, then no device was detected at that time.
6.2 dbo_fluphone_locations
Example:
------------------------------------------------------------------------------------------------------------------------------------------------
|
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 |
------------------------------------------------------------------------------------------------------------------------------------------------
Notes:
- 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
Example:
-------------------------------------------------------------------------------------------------------------------------------------------
|
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 |
----------------------------------------------------------------------
Notes:
- 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
Example:
-------------------------------------------------------------
|
uid
|
code
|
mac |
-------------------------------------------------------------
|
6 | 2110872393 | not
set |
-------------------------------------------------------------
|
7 | 964089716 |
0025D04B2B3F |
-------------------------------------------------------------
|
8 | 1025654460 |
EC9B5B009E8F |
-------------------------------------------------------------
Notes:
- 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
Example:
---------------------------------------------------------------------------------
|
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
Example:
---------------------------------------------------------------------------------------------------------------------------------------------
|
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
Example:
---------------------------------------------------------------------------------------------------------------------------------------------
|
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
|