Preliminary Analysis of the iPhone Location Log
Yesterday, security researchers announced that iPhones and 3G iPads maintain a log of the phone's position over time. Today, another researcher released a python program to dump the equivalent log from Android devices. While it has been common knowledge that cellular phone carriers store customer location data for a while now, it comes as a surprise to learn that client devices are carrying their own logs as well. These logs are included in backups on the user's computer and rogue applications could easily steal the data if left unencrypted. Even more troublesome are reports that Michigan State Police are using a device from a company named Cellebrite to extract data from people's cellular phones during routine traffic stops.
So what data, exactly, is contained in the consolidated.db file? And just how accurate is the positioning data contained within? After unencrypting my iPhone backups in iTunes, I used the information in Pete Warden's documentation on GitHub to pull the information into a spreadsheet. I had 12,380 records in total starting on 9/3/2010. That's the day I purchased my iPhone 4. On average, that's 61 location entries per day! After spending some time with the data, here are some preliminary observations:
1. The log appears to be limited to cell phone tower data, not GPS data. The values in the Horizontal Accuracy column never fall below 500 (meters) which suggests this is approximate location data from cell towers. Moreover, the VerticalAccuracy and Speed columns are always -1, which is what the Significant Location Change service reports when GPS is not in use.
2. The MCC and MNC columns represent some combination of carrier and/or country code. These columns have values of 310 and 410, respectively, whenever I was in the United States. This includes trips to both coasts, so I'm fairly certain these values apply to AT&T anywhere in the country. In Europe, these columns take on different values for each country. It appears that the MCC column might be a country code and the MNC column is a carrier code.
3. Timestamps are only updated after a significant location change. Surprsingly, the same timestamp value is shared across many location entries. This behavior seems rather strange, as it is trivial to grab the current system time when writing locations to the database. Apparently the column was intended to represent the phone's arrival in a certain area. Generally, travelling a distance of 5 kilometers is enough to trigger a new timestamp but this is not guaranteed. I have many timestamp updates at less than 1km traveled and quite a few updates of over 5km without a timestamp change. It appears that driving somewhere quickly (i.e. using the freeway) is more likely to trigger a timestamp change than by slowly moving to a new location (i.e. on foot). This is not a reliable metric by any means, as I had some blocks of entries with the same timestamp span upwards of 20 miles within a city.
4. A stationary phone can generate many log entries. Building on the idea that timestamps only change when the phone is moved a significant distance, I started mapping blocks of entries with the same timestamp value. It turns out the phone logs quite a few location entries while the phone is technically stationary, even in buildings with great reception. This is not surprising, as received signal strength from nearby towers will vary significantly as I walk through a building. The following image shows location entries while I was in my apartment, which has excellent reception: (Note: I translated all of the values by the same offset for some anonymity)
These consolidated.db entries were logged over the course of 11 hours in one building with great reception.
5. Averaging entries with the same timestamp comes remarkably close to the phone's actual location, but only if reception is good and cellular towers are dense. Averaging a random sample of consolidate.db entries with late-night timestamps yielded coordinates only 690 meters from the actual location of my apartment. The average of a block of entires on a Saturday gave me coordinates only 630 m from my girlfriend's house. Both of these locations have great reception and are moderately-dense suburban neighbors. On the other hand, averaging entries during the week put me a full 8.1 km from the actual location of my office. We have terrible reception in my office, so this is not too surprising.
The average of these points with the same timestamp is within 650 meters of my actual location
6. 50% of location changes occur after 1 km of [perceived] movement. 33% occur after 500 m of movement. A full 90% occur within 5km. These distances are calculated from the estimated locations in consolidated.db. It would be interesting to log actual GPS location in parallel and compare the two values.
Relative frequency of the distance between updates
7. Locations with good reception have far more entries than locations with poor reception. I expected the opposite to be true, as buildings with poor reception tend to have higher received signal strength fluctuations and therefore trigger more perceived location changes. Instead, the phone infrequently logs locations whenever reception is poor. This could be a side effect of some built-in mechanism to only log locations when the phone is relatively stationary and receiving a stable signal. As a result, it's very difficult to pin down the phone's location if reception is poor.
8. Older entries are less frequent. This one is just a rough observation. It's entirely possible that I've been more mobile lately than when I first bought my iPhone. However, my log has far more entries with timestamps in the past several months than it does from the beginning of the consolidated.db log. This could be due to changes in the iOS software to log more often. It could also indicate that the iOS software prunes older entries over time to keep consolidated.db from growing too large, but I'm not so sure this is the case.
So what does this mean for iPhone users? Not a whole lot, as long as you remember to encrypt your iPhone backup in iTunes to make it a bit more difficult for rogue applications to access. Still, I'm not sure why iOS and Android OS find it necessary to keep location logs. The only logical explanation I've heard so far is that it might help speed up future geolocation queries. It will be interesting to see how Apple and Google respond to this, if at all.
iPhone Background Location Service
Location Updates After 2 Days in San Diego
Apple's iOS operating system famously doesn't allow applications to run in the background. It does, however, allow them to perform seven narrowly-defined background services such as audio streaming and receiving 'significant location change' updates. The significant change updates don't use the iPhone's highly accurate but power-hungry GPS in the interest of preserving battery life. Instead, the phone uses the relative signal strengths from nearby cellular towers to triangulate a rough approximation of the iPhone's location. The phone's baseband must continuously communicate with the carrier's cellular towers when your phone is turned on anyway, so gathering location data from these communications should have a negligible effect on battery life.
So just how accurate are these triangulated data points, and what exactly constitutes a 'significant' location change to the iPhone's iOS? The only information I could find comes from a developer who tested phones in Tokyo, Chicago, and Melbourne. He concluded that 2500m (approximately 1.5 miles) as measured by the phone's own background location service, was enough to trigger location updates 95% of the time. Moving 750m triggered an update 50% of the time. Good information, but it doesn't tell us anything about the accuracy of the background updates.
The problem seemed interesting enough, so I spent a Saturday morning putting together a small test suite. I created a simple iPhone app that registered with the iOS significant location change service and logged all updates in an SQLite database and CSV file. I also built a Ruby on Rails app to receive real-time location updates from the phone and pushed it to Heroku for some quick (and free) hosting. Finally, I made a point to record every time I got into or out of my car in my notes for a week so I could compare the background location results to my actual whereabouts.
Some observations:
1) False location change events occur randomly when the signal is weak - At my apartment where the cellular signal is strong, the background location service is generally within 1km of my actual location. When I'm at my office building, where signal strength is so bad we struggle to complete phone calls indoors, the phone will randomly register location events up to 10km away. Usually these events are triggered as I walk from one side of the building to another, but occasionally they will occur while I'm seated at my desk.
2) It doesn't use nearby WiFi networks for location - The above problem could be mitigated somewhat if the OS would use nearby WiFi networks to aid in location. After all, the iPhone already queries a massive database of WiFi router locations to assist with GPS lookups, and I've used my GPS at home and my office enough for the phone to associate my WiFi router's BSSID with a physical location. On the other hand, scanning for WiFi networks would provide some additional battery drain. Dealing with mobile hotspots like the MiFi would be problematic for a WiFi-assisted location scheme as well.
3) Location updates occur at regular intervals while moving, but not always - For my first test of my location tracking app, I drove 13 miles across town to a coffee shop. Upon arrival, there were exactly two pins on my map: my apartment and the coffee shop across town. I assumed the background location tracking waited until I stopped moving and my location stabilized to register a location change event. Clever. Then, on the drive home, my app diligently registered location events every few kilometers along the freeway until I was home. So much for that theory. Since then, I've received updates while moving more often than not, but very rarely I won't see any location update events until I arrive at my location.
In the screenshot to the left, I ended up driving all of the visible freeway segments (yellow lines) over the course of two days. For the upper (I-80) and rightmost (I-215) segments, the application received location change updates at roughly the same location each time. The segment on the left (I-15) did not register any location events in this snapshot, but on other days driving the same I-15 segment would register location change events every 2-4 km.
The good news is that I always seemed to register a location change event when I arrived at my destination and parked the car. In some cases, these location change events were 15km apart. This only seems to happen when traffic isn't present, allowing me to maintain a constant 65mph on the freeway.
4) If the application is terminated, background location services will restart it automatically - Once the app calls [[CLLocationManager sharedLocationManager] startMonitoringSignificantLocationChanges] the familiar location 'compass' arrow shows up in the taskbar, even though the GPS isn't running. Terminating the application does not remove this arrow as I expected. Rather, the OS will launch the application again when the next significant location change event occurs. The only way to remove the compass arrow and stop location change events is to call [[CLLocationManager sharedLocationManager] stopMonitoringSignificantLocationChanges] from within your application. Unfortunately, there is no way to list which applications are monitoring your location. I can imagine frustrated users killing all of their applications one by one in an attempt to turn off location updates.
5) Activating the GPS will register a location change event, even if the phone hasn't moved - Opening the Maps application, checking in on FourSquare, or any other activity which uses the actual GPS will trigger a significant location change event. These are easy to distinguish from background location events because they have real values for CLLocation.VerticalAccuracy, CLLocation.Altitude, and CLLocation.Speed, whereas background location updates have values of -1, 0, and -1 respectively.
Choosing the Right Tire for your Mountain Bike
Riding Beacon Hill in Spokane, WA
This is a guide for choosing the best tire for your mountain bike. Too many riders obsess over lightweight frames and top-dollar components while ignoring the all-important tire. Tires connect your bike to the trail. They set the limit for how hard you can corner, accelerate, and brake. Changing a tire can completely change the way a bike handles. It pays to invest some time and money into finding the best tire for your setup.
The best starting point for choosing a tire is to ask the other riders at your favorite trails which tires they prefer. Local bike shop employees are usually helpful as well. Online opinions and reviews in forums are useful, but unless you're browsing forums for your particular region you may end up with tire recommendations that are sub-optimal for your local trail conditions.
I typically go through 8 tires or more per season, and I keep a stack of different tires in my garage to swap out depending on the trail, the weather, or if I just want to try something new. Through trial and error I've learned what to look for in a tire, and what to avoid. Here are the most important things to look for:
1. Tire Width
Wider tires tend to grip better during cornering and over rough terrain, at the expensive of increased rolling resistance and weight. Wider tires will also float better in sandy conditions and are much more resistant to pinch flats when riding over sharp rocks or off of drops. For moderately rocky cross-country use, the sweet spot is between 2.0" and 2.3". If you primarily ride smooth hardpack or travel at a leisurely pace, choose a 2.0" or even a 1.8" tire. Likewise, if you tend to corner hard on the downhill and ride rough terrain, lean toward a 2.3" tire. For downhill mountain biking where pedaling efficiency is less of an issue, look for a tire between 2.3" and 2.6". Tires up to 3.0" wide are available, but rolling resistance becomes very significant past 2.6".
The front tire is typically subjected to more cornering forces than the rear tire. Likewise, the rear tire is usually loaded with more weight while pedaling. Consider using a wider tire in the front with a slightly narrower tire in the back to get the cornering benefits of a wider tire with the rolling resistance advantages of a narrower tire in the rear. I've had good luck with a 2.5" tire up front with a 2.3" tire in the rear on my downhill bike.
Also note that widths are approximate. I've got a 2.3" tire which measures 2.5" wide with my calipers, and a 2.4" tire which is actually only 2.25" wide. Make sure that your frame and fork have enough clearance to support the width of the tire. Maximum tire sizes are listed in the owner's manual. If you ride through mud often, allow for even more tire clearance to keep mud from building up between the tire and frame.
2. Compound (a.k.a. Durometer)
42/40a compound tire. Left: Brand new. Middle: Used as a rear tire for four days of downhill. Right: Used as a front tire for four days of downhill.
The hardness of the tire's rubber compound dictates how soft and sticky a tire is. Softer compounds grip better at the expense of shorter tire life. Likewise, a harder tire will last longer but have less traction. Softer compounds also have a higher rolling resistance because the softer rubber absorbs more energy as it conforms to the ground.
Hardness is measured by the tire's durometer with higher numbers indicating a harder compound. A standard cross-country tire will have a durometer around 60a (the 'a' is omitted by some manufacturers) and will last for one to three seasons of moderate weekend riding. A 50a compound will provide noticeably more grip under cornering and braking, but might last only one season. 40a and 42a tires are the softest available compounds and will provide the most traction, but plan on replacing these tires at least twice a season. Some tires are available with a 70a compound for the ultimate longevity, but these are only really useful if you're riding on pavement or the smoothest off-road trails.
The rear tire will wear faster than the front tire due to higher loading, braking, pedaling, and sliding forces it sees. Consider using one step harder of a compound in the rear to minimize this effect with little impact on overall performance. Riders who slide the rear end a lot will definitely want to avoid soft 40a and 42a compound tires in the rear. If you do use the same tires front and rear, rotate your tires halfway through the season to get the most life out of the set.
Foreground: Soft 42a tire (ab)used as a rear tire. Background: Same tire, brand new
Multi-compound tires can be the best compromise of the above factors. Maxxis' 3C tires use a hard base rubber for lower rolling resistance with softer compounds on the surface and for the side knobs for better grip. For example, a 70/42/40 compound tire would have a 70a hardness base rubber under the surface, with 42a center knobs and 40a side knobs for the best cornering. From my experience, they tend to last about as long as a 42a tire with the slightly better cornering of a 40a tire.
3. Bead (Wire vs. Foldable, Steel vs. Kevlar)
The bead is the inner edge of the tire that holds the tire to the wheel. This edge is either wire reinforced (steel) or foldable (Kevlar or Aramidd). Foldable beads are about 50 grams lighter and allow the tire to be folded up. Tires with steel beads cannot be folded up, but hold up slightly better under heavy downhill riding.
I always run foldable tires on my cross country and all mountain setups, but after a few bad experiences on my downhill bike I stick to steel bead tires for downhill. Most downhill tires are only available with a wire bead anyway.
4. Number of Plies (1-Ply vs. 2-Ply)
The casing (internal structure) of a tire is a nylon cloth wrapped from one bead to the other. A single ply tire has one layer of nylon fabric, while a dual ply tire has two layers for additional durability at the expense of additional weight. Single ply tires are generally fine for cross country, but for all mountain or downhill riding you will definitely need a dual ply tire. Some 2-ply tires have an additional butyl rubber insert sandwiched between the plies in the sidewalls for even more pinch-flat resistance.
5. Threads per Inch (TPI)
A tire's thread per inch count refers to how many nylon threads cross through one inch of a single ply of the casing. Lower TPI tires have larger individual nylon threads while higher TPI tires have smaller, more tightly woven threads. High TPI tires have less rolling resistance and weigh less due to the smaller threads, but the thinner weave is more easily damaged than a lower TPI tire. A TPI of 60 is best for downhill and all mountain, and a TPI of 120 is fine for lighter cross country.
6. Weight
Tire weight is proportional to width and durability. A super strong wide downhill tire can weigh up to 1.4kg (3.1lbs) while some narrow, paper-thin, race-only cross country tires can weigh as little as 285g (0.6lbs). I wouldn't recommend super-light tires for any use (even racing), but if your riding is limited to cross-country on smooth trails a 450g tire can be strong enough . For all-mountain, anything less than 600g is probably not as durable as I would like. Downhill tires start at around 1kg, but the extra weight is a small price to pay for the added durability.
As long as you're picking an appropriate class of tire for your bike and riding style, it's not worth obsessing over a difference of a few 100g between tires. It is interesting to note, however, that the weight of a tire has almost twice as much influence on your bike's inertia than any non-wheel parts of your bike. When you accelerate or brake, you are not only fighting the linear inertia of your tires, but also the rotational inertia of the tire as well. Usually this effect is too small to notice, but it's an interesting fact nonetheless.
7. Knob Pattern
The tread pattern and knob locations can provide insight into how the tire will handle, but these are very difficult to read. Trying a tire out for a few days is the only way to truly know how a tire will handle, but there are a few guidelines you can use to judge a tire:
- Tread patterns with lengthwise-overlapping knobs will have a lower rolling resistance because they maintain a smoother contact between the road and the tire as it rolls
- Knobs with ramped leading edges in the center of the tire have a lower rolling resistance
- Widely spaced knobs will shed dirt and mud better at the expense of higher rolling resistance
- Knobs with channels cut through the center have more edges and therefore grip more, but wear faster than solid knobs
- Patterns with a large gap between the center knobs and side knobs can require more leaning in corners to get a solid bite but grip better under hard cornering
8. Tubes vs. Tubeless
Tubeless mountain bike tire setups have become more popular recently due to their lighter weight and self-healing properties when used with an appropriate sealant. A tubeless setup requires either special UST wheels which are airtight, or standard wheels modified with an additional strip of rubber to be airtight. I'm not a big fan of the modified wheel approach but many people have no issues with it. A UST wheel can in theory be used with a UST tire without additional liquid sealant, but the added protection of a sealant is definitely worth it. Any other tire or wheel combination will absolutely require a liquid latex sealant inside of the tire, as standard tires are not actually 100% airtight and their bead is not designed to form an airtight seal with the wheel.
Perhaps the biggest advantage of a tubeless setup is the ability to run very low pressures without worrying about pinch flatting a tube. A tubeless setup with sealant will also seal any tiny punctures from thorns automatically. The downsides are the additional cost of UST wheels and tires and the added difficulties of mounting a tubeless tire. (Hint: Use a lot of soapy water on the rim first!) Also, sealants are messy and dry out over time, requiring refills every 1-2 months for maximum effectiveness. Always carry a spare tube and tire levers anyway in case your tire is punctured with a hole too large for the sealant to properly seal.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=7802a203-b3b8-4bab-84c7-abacbf2be1e1)
Little Cottonwood Canyon Ruins
Last Wednesday I hiked up Little Cottonwood Canyon to revisit the strange ruins at the top of the trail. The trail that runs parallel to the road from the base of the canyon is my favorite after-work mountain biking trail. Across the river from the top of the trail you can see some ruins hidden among the trees. Unfortunately, the river is fueled by all of the melting snow from higher up the canyon, so the water level remains too high to cross for most of the year. This fall the water level finally fell low enough to cross.
The ruins as seen from across the river
The building itself, or what remains of it, was definitely worth the hike and the river crossing. All of the walls were precisely constructed from stacked granite rocks gathered from the surrounding area and held together with mortar. The only exceptions were the wood planks surrounding the door and window frames and some relatively ornate concrete arches over each of the window openings. I can't even imagine how much effort it would have taken to collect and stack all of those rocks into a building of that size. Given the fact that the building was mostly reduced to rubble, it wasn't the most robust construction method, but it definitely has a visual impact that is hard to match with any of the modern construction methods.
This hole in the floor drained into a tunnel that flowed out to the river
I had a difficult time finding any evidence of what the building might have been originally used for. After many years of snowy Utah winters, curious hikers, and what looked like a few seasons of abnormally high river waters carrying mud into the building, there was little evidence of the original purpose of the building. I managed to find a pair of small metal hooks near the door, perhaps just large enough to hold two sets of keys. A hole in the floor gave way to a small drainage tunnel that must have carried drain water out to the river. What remained of the roof trusses appeared to be constructed with the same attention to detail applied to the rest of the building. Whatever material the roof was originally constructed from had long since decayed or washed away.
Mother Nature is slowly winning this battle
I searched the internet for some clues about the old building, but never came up with anything useful. Little Cottonwood Canyon was used by the Mormon pioneers as a source of quartz monzonite to build the temple in downtown Salt Lake City, but it sounds like most of the stone came from the mouth of the canyon 3 miles below this building. Still, given the rather ornate construction of the building and my lack of a better explanation, I'm inclined to guess that the structure was constructed for use as a church. Definitely worth a visit if you've got a few hours to spare in the Fall.