Linked by Thom Holwerda on Thu 21st Apr 2011 21:59 UTC, submitted by Martin
Apple There's a bit of a stink going on - even in major media - about something iOS 4's been doing. Apparently, iOS 4 has been storing a list of locations and timestamps to a hidden, but readable file in a standard database format. The locations are triangulated using cell towers, and generally aren't as accurate as for instance GPS. Still, the file is stored without any form of protection on both your iPhone as well as your desktop.
Thread beginning with comment 470872
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: why wait?
by galvanash on Sat 23rd Apr 2011 04:43 UTC in reply to "RE[5]: why wait?"
galvanash
Member since:
2006-01-25

Can one of you fanboi apologists for Google/Apple please provide a use case where it makes sense to keep track of previous locations at an OS level?


It can take a few seconds to get a gps fix... Until you do get a fix, you have no idea where you are, so any mapping app has to wait idly until the fix is done. Having coordinates of cell towers you recently communicated with let's you get an approximate fix instantly. This can dramatically improve the user experience, because you can instantly set an appropriate zoom level and center the map on the approximate location while waiting for a more accurate gps fix.

The point is gps is not instant - there is latency involved. There is also latency with the mapping API itself (downloading map tiles and such). This let's you hide both latencies.

Also, gps is not always available - especially when indoors. This offers a fallback. Not as accurate, but better than nothing.

You can't get tower location info on demand... You get it when it happens (when the cellular radio picks one up or switches between them). Therefore to actually use the information for this type of purpose you have to log it.

Btw, the geolocation Apis in both iOS and android do all of this stuff for you - it's built into them. Hence why the OS itself does the logging. Apps do not ever read these logs directly, the apis used to get position fixes do that for you (without telling you how the information was derived, it just returns coordinates and an accuracy indicator).


That explain it well enough?

Edited 2011-04-23 05:02 UTC

Reply Parent Score: 3

RE[7]: why wait?
by Not2Sure on Sat 23rd Apr 2011 19:45 in reply to "RE[6]: why wait?"
Not2Sure Member since:
2009-12-07

That explain it well enough?


Nope. That explains the need to require the last known location. Not the last 100, 1000 etc, and again that would be an application use case not an OS one.

You are obviously without a clue how AGPS works on the CDMA/GSM networks. Go troll somewhere else.

Ask for a fanboi response, get one I suppose.

Reply Parent Score: 1

RE[8]: why wait?
by JAlexoid on Sat 23rd Apr 2011 21:35 in reply to "RE[7]: why wait?"
JAlexoid Member since:
2009-05-19

"That explain it well enough?


Nope. That explains the need to require the last known location. Not the last 100, 1000 etc, and again that would be an application use case not an OS one.

You are obviously without a clue how AGPS works on the CDMA/GSM networks. Go troll somewhere else.

Ask for a fanboi response, get one I suppose.
"

Technically, the last N entries for locations of WiFi hotspots and cell towers leads to lowered traffic to the same geolocation servers.
This lowers traffic considerably when you are stationary at a intersection of many cell towers, because you may switch from one to another every few seconds. Imagine the traffic to the geolocation servers in that scenario....

Reply Parent Score: 2

RE[8]: why wait?
by galvanash on Sat 23rd Apr 2011 23:07 in reply to "RE[7]: why wait?"
galvanash Member since:
2006-01-25

Nope. That explains the need to require the last known location. Not the last 100, 1000 etc,


I NEVER said there was a need to store the last 100 or 1000, just enough to compute an approximate location (at most 5-10 towers I would think)... I'm not defending what Apple is doing (i.e. long term logging of the information) - I was simply explaining why there is a valid reason to log _some_ of it. You said you could not think of a single valid reason to keep any of this data - I gave you one.

...and again that would be an application use case not an OS one. You are obviously without a clue how AGPS works on the CDMA/GSM networks. Go troll somewhere else.


How can you say this is an application use case when applications on iOS/Android cannot access either GPS hardware or Cellular radio hardware directly (and therefore could not log raw data themselves)? The apis expose your coordinates, not those of nearby cell towers. You could not log such data even if you wanted to - there is no way to get it (without going around the OS anyway).

I was sincerely just trying to answer your question, and you go all flaming assh*le on me? I've written softare using location apis on iOS and blackberry (haven't done Android yet) and I know enough to tell you have no idea what the f*ck you are talking about...

A-GPS is NOT the same thing as cellular triangulation (which is what I am describing). A-GPS does not eliminate the need to do triangulation, it speeds up GPS locking by giving the GPS hardware information about the closest satellite and can enhance accuracy, but it still relies primarily on GPS and GPS is both slow and power hungry...

Cellular Triangulation is done by the OS using data logged from the network and the reason to do so is so that you can do it when the GPS hardware is turned off. UTDOA (Uplink Time Difference on Arrival) data is used on GSM networks to do this - it has absolutely nothing at all to do with GPS or A-GPS. The UTDOA data is what is being logged in these files everyone is talking about (at least the cellular data part).

Ask for a fanboi response, get one I suppose.


Glad I could help ;)

Reply Parent Score: 2