Some thoughts on smart phone GPS

I had a car accident two weeks ago. My car was hit from behind and the driver later denied everything. He first claimed he was not involved in any accident on that day. I provided a few photos I took with my smart phone; including one on his car and another on his insurance card (here is a thumbnail of the driver copying my insurance information).

This motivated me to take a careful look at the meta data contained
on those photos. Besides the date and time, we got the exact location of the accident, thanks to the build-in GPS. The photo meta data contains a GPS section, which reads like (37^o49’11”N, 122^o28’43”W). By converting this into a decimal format, we get a coordinate “37.8197,-122.4786”, where longitude need to be changed into negative to reflect the western hemisphere. Google Map understands “37.8197,-122.4786” as a valid search string. Since the phone automatically saved a copy of the photos onto the cloud, there is a third-party source that validates the photos.

The episode did not end here, as the driver later claimed there was no trace of impact on his car, implying the damages on my car were prior to the accident. This certainly has been a quite frustrating experience, as the claim processor was not willing to apply her common sense and the burden of proof fell onto my own shoulder. I then found a plate mark left on my bumper. Applying some Photoshop contrast and edge enhancement tools, I can tell these are letter marks left from the top of his license plate frame. Although it is too hard to read the letters, the contour should provide enough traces to be mapped onto his plate. The claim now moves forward.

This raises a hypothetical question - how can one actually prove a photo was indeed taken at that location and on that date? That is how to prove the meta data has not been manually altered? This leads to an idea that the mobile cloud provider might consider a timestamping service as described on this Wikipedia entry [1]. Presumably when the cloud storage receives a document, it calculates a short hash key (a fingerprint string). Then it sends the hash to a timestamping
authority (TSA) and obtains a string of “signed timestamp and hash” to be stored together with the photo. Now the photo can be trusted by court. The court verification process goes like this: it first verifies the string containing both hash and timestamp was indeed generated by the TSA (by decoding it with the TSA’s public key), which means the hash existed at the said date and time. Since the hash generation algorithm works in such a way that it is nearly impossible to find another document that can be mapped to the exact hash, this proves that the original document indeed existed on the said date and time. This is basically the same process used in many digital lab notebooks systems I happen to be familiar with, and such a document with its hash-and-timestamp string will stand up in court.

There are many interesting applications of GPS on smart phones. Putting privacy aside for the sake of discussion, the GPS data produced by smart phones, if accessible by law-enforcement authorities, may well help identify the other drivers at that time and location, who might be valuable witnesses of the accident. Sure that will be more justifiable for a crime instead of this small accident. In addition, if you ever wonder how Google Map obtains traffic data for local streets, the data also comes from our smart phone GPS[2]!

[1] http://en.wikipedia.org/wiki/File:Trusted_timestamping.gif
[2] http://googleblog.blogspot.com/2009/08/bright-side-of-sitting-in-traffic.html

Resurrection of My Phone

Four days ago I managed to get my new phone soaked in water for a few minutes. The phone was at standby mode, but was not switched off at the time. I grabbed the phone and pressed the power key to turn it off (an unnecessary wrong move!). No greeting message, the phone was dead. I yanked the battery off then shook the phone as hard as I can.

Google search yielded quite a few helpful links for how to fix a water-damaged phone [1-2]. I let a fan blow at the phone for four hours; then buried it overnight in a box of white rice. The second day, I bought two bags of Japanese seaweed soup base just to get the two phone-size packs of lime desiccant inside. Then I let a hair dryer blow at the phone with warm air at a safe distance; sandwiched the phone with the two lime packs, seal them in a small airtight food storage container box. Waited and waited …

Recommendation on the waiting period varies, ranging from 24 hours to 3 days. As a replacement of my phone will cost $500, I waited for four full days. Every day, I hair-dried the lime packs, refilled the box with dry air, prayed a little, and killed the growing anxiety to test the phone. All efforts paid off and the phone resurrected at the end!

What have been equally educational is to learn how carriers have embedded “liquid damage indicators (LDI)” to prevent fraud claims on such devices. Basically the indicator contains a layer of red dye is beneath a layer of white paper, when moisturized, the white paper turns into red and the carrier can easily void any warranty based on the mark. People get “creative” in bleaching the indicator back to white [3]. This is certainly detectable, as bleached indicator no longer turns red when moisturized again, plus there could be other hidden indicators you may not see until you take the phone apart. So the best advice definitely is to be honest here. Nevertheless I need to check if my phone was enrolled in any insurance plan.

1. http://www.wikihow.com/Save-a-Wet-Cell-Phone
2. http://www.popularmechanics.com/technology/how-to/tips/4269047
3. http://www.instructables.com/id/Turn-Your-Cell-Phones-quotI-Got-Wetquot-Indic/

Save the Daylight Saving Time (DST)

Getting home after work can be a different experience in the spring versus in the fall. As now the sun still overlooks the horizon at 6pm, I cannot help trimming my garden, while the dinner is being fixed. When the Daylight Saving Time (DST) just goes into its annual hibernation, driving home in the gloominess has the word "overwork" written all over my body.

Many funny things happen during the on/off switch of the DST. Do you know trains all stopped at 2am for an hour in the spring, but tries to run crazy in the fall because it is suddenly 1 hour behind schedule [1]. We can laugh about this somewhat silly solution to the train problem, but we ought to get serious about how to guard our savings in the bank during the switch of DST.

Say you withdraw $100 at 1:30am; the clock is set back to 1am in 30min; you then withdraw another $100 at the second 1:30am. Can you walk into the bank in the morning and claim you really only did one withdraw and ask for another $100 back into your checking account? If an ATM associates the two transactions with the same text string “Mar 14, 2001, 1:30am”, the bank indeed will have a hard time proving the duplicate withdrawn are not their mistake. We all know there is no free lunch, so how this works?

Computes all use UNIX time [2], i.e., time is not memorized as a text string, but rather as a number. The first “Mar 14, 2001, 1:30am” is recorded as the number 1268530200, i.e., the number of seconds between that precise moment and Jan 1, 1970, 12:00am; the second “Mar 14, 2001, 1:30am” is recorded as 1268533800 (3600 larger than the first one). The banking system has no trouble telling these two transactions apart; software only relies on the UNIX time for all its computing logic, and only use the text format for sole display purpose.

So programmers need to be aware, if you export those transactions from database into a text file, you will only get their text representations and which might well trigger some serious bugs in your data analysis code.

“Spring forward and fall back” is just a zeroth-order approximate to catch up with the sunrise and sunset schedule. With computers and cell phones totally capable of automatically syncing themselves with the Internet, we are well prepared for a DST that is much less disturbance to our daily routines. Here is my idea: the one-hour shift (a step function) during half a year period can be better modeled with a saw tooth function over a year (see figure), i.e., the clock moves forward only 1/3 minute per day in spring and summer, then moves backward 1/3 minute per day day in fall and winter. With such tiny adjustment, the train will run as it should be and we can drive home with the sun positioned where it should be every day.

P.S. If you think a change in a fraction of an hour is hard to accept, you may want to check out the current time in India (http://www.worldtimeserver.com/current_time_in_IN.aspx). It caught me in surprise two weeks ago that the time difference between India and us are 12 hours and 30 minutes!

[1] http://www.webexhibits.org/daylightsaving/k.html
[2] http://en.wikipedia.org/wiki/Unix_time