So complicated... Just run Android in a VM, and fake the accelerometer inputs. You can make the phone think it's doing anything.

11th circuit court of appeals ruled that you *CANNOT* compel somebody to decrypt their HD.

Click here for link

Also, I wasn't puffing myself up. I only casually mentioned my research, so that my examples would hold more weight then some random person that makes a suggestion. My approach to this thread was more like a Q and A session, where people made suggestions/hypothesis and I responded with how that worked out in research. That was my intent. It was not to come on here like an arrogant prick and tell people how everything works.

First of all, I mentioned using more than one AP in several posts, it probably wasn't in this particular chain. Also, the original problem I was stating, was talking about the problems of trying to interpret signal flux, which is going to be a problem regardless how many APs you have. That's why I never mentioned it in the first post, because it was irrelevant, the problem would still be apparent regardless.

It's not like I was trying to give you guys a dissertation on my research. I was simply shedding some light on a few select scenarios to show how such concerns the original poster had were overblown. I didn't feel it was necessary to go into great details, as I was trying to be simplistic in my explanations, because it's easier for an audience not in the field to understand such concepts in simplistic terms/examples, rather then getting into nitty gritty details.

I was tackling a slightly different problem, so yes I was trying to do things client side.

This is inline pretty much with what I was getting. 15-20ft being 4-6m.

The reason I was talking about unmanaged networks, was because the original poster was talking about Google aggregating information from arbitrary locations to make determinations on the user. If a department store wants to implement a system to track it's users in a store, they can do that pretty well for what their needs are. I was talking about Google trying to aggregate location data from places where equipment was not necessarily deployed with tracking in mind. For example, starbucks could probably give 2 sh!ts where you were in the cafe. If google got a hold of the data of you while at starbucks, they would be in the same position I was referring to.. They have signal strength readings of various APs that they have no idea where they were deployed, how they were deployed, etc. That's a different scenario then if Starbucks were to deploy a purpose-built location tracking system, and then forward the information to Google.

By the way, I tested some server side commercial solutions, but I ran into some interesting scenarios, but maybe it's because the environments I was dealing with have less constrained environments. For example, in our own workspace each office space is not identical, nor is there any pattern to the layouts, as it's the employees choice on the layout. That means we ran into problems even with the commercial solutions, based on how the device was placed. Some people placed the phone on the desk next to keyboard. Some placed it in pocket. Some placed it in jacket pocket. Some placed it behind their monitor out of the way of their work area. Some put it in their flipper cabinet. Due to all this, we were never able to reliably get accuracy below 15ft. Depending on the problem you are trying to solve, that is probably good enough.

But one scenario I tested, involved a restaurant. Even with granularity down to 6ft... That wasn't good enough to differentiate someone sitting at the same table as you from someone sitting at the table next to you, because sometimes the person sitting in the chair in the next table over, is actually closer to you then the person sitting across from you at your own table.

Also, if you are going to create a "map" with a known device, you'll run into other problems. That map will only work with devices of the same make and model of the device you created the map. Every other device will give different results because different devices have the antenna mounted in different locations. Differing hardware also uses different transmit power, so the readings will be different as well. I've tested all sorts of different devices. The only time I got similar readings was when I was using another device of the same make model. So for example, readings on my Galaxy SII was different from my HTC One X, which was different from my Galaxy Nexus, which was different from my Nexus S, etc.

That only works if you assume the device is always going to be in your hand. If you put the device in your pocket, that changes the signal strength readings... take this scenario for example:

You are at point A walking towards point B with the device in your hand. As you are walking you put the phone in your back pocket. When you get to point B, the algorithm could think you are still at A, because the APs that are on the "B" side of the room now have to go through your body to get to your phone. But when you were at A, the phone was in your hand, so APs on the A side of the room at to go through your body to get to your phone's antenna in your hand.

So its possible (and yes, I've actually seen this with real data), that while at A with phone in hand, you get almost identical readings from all the APs as you did at B with the phone in your back pocket. So now you try to get smart, and try to map all the possibilities. But now you are stuck, because the profile of device at A in hand is identical to the profile of device at B in pocket. So now you need to figure out if the device is in pocket or not.... See how the algorithm quickly gets more complicated? (And this is only the beginning... Detecting when device is in pocket is an even trickier problem to solve then the location tracking was.)

And to add further. There is a difference between active tracking and passive tracking. The technology this article is referring to, relies on passive beacon packets from the mobile device. On Android, for example, it passively scans every 30 seconds. That effects the granularity/resolution of your location tracking because the filters that you have to employ to clean up the data are negatively effected by smaller data sets. To get finer grained location data, you need lots more data points. And I mean orders of magnitude more data points then whatever you can get from a passive beacon.

Think of it this way... Imagine yourself walking into a store with me, with your eyes closed. Now only blink once every 30 seconds, even if you knew our precise location every time you blinked, do you have enough information to know what I was doing in the store, what sections actually appealed to me, and what products I got? You may know that I was in the meats section, but you wouldn't know if I was just passing through, if I paused. If I paused you don't know why I paused, maybe because somebody's cart was blocking me. Your eyes may have been closed when I grabbed the frozen pizza, because that section was near the produce section, which is where you blinked, but I was able to get to the frozen pizzas and grab a pizza, and walk back to the produce section because I forgot to get some grapes, before you blinked again.

Most of the research I was doing was centered on user-intent. I mentioned this research, becuase the original poster was talking about similar scenarios with regards to how Google might use the information. Determining user-intent is vastly more complicated then simply location tracking, especially with the coarse grained tracking afforded by a passive scan. My original argument was that to do the types of scenarios the original poster was talking about, requires much more then just beacon packet sniffing, which is what Euclid is doing.

sentence got cut off... I was saying that I've seen solutions that touted sub 15ft accuracy, but when I tested those solutions, they almost all made the same assumptions. They assumed the device being tracked would be in hand. The algorithms usually fell apart when you placed the device in your pocket, in your purse, etc. Especially if the device transitioned from being in pocket/purse/bag to being in hand and back while in motion.

Also, there is a difference between location tracking and spatial relationship. Two people can be in the frozen food section and satisfy location tracking, but you'll need spatial orientatation/relationship information to know which product you are specifically looking at. In terms of the original poster, he was worried about apps figuring out who you were "with". You need spatial orientation there too, to differentiate between someone sitting at the same table as you vs someone sitting at the table next to you, etc.

In case you didn't read the original article, the technology in question only looks at wifi beacon packets, it doesn't track anything else from the device. That's why I used the specific research examples that I did. In fact, if you actually read my arguments, I was saying you needed to have other sensor inputs to make the results more accurate.

Where did I say I only looked at situations with a single AP?

Reasonable, perhaps, but still not precise. You have to figure out why the signal went from 60% to 90% at another AP. Did you simply turn around, so that the signal from one AP is now going through your body? Did you just place your phone in your pocket, or your purse, etc? There are lots of things that can cause signal fluctuations. Did the signal reflect off a surface that it was not able to before? When the number of AP's goes up, it can increase granularity to a point, but I've never seen anyone able to reliably get granularity below 15ft. I've seen solutions that touted
But like I said earlier. Rough estimation is fine for most intents and purposes. I was talking to the argument about using these technologies to determine who you were "with", which requires much more fine grain location tracking. For example one thing that comes up in location tracking is orientation. However, orientation of the device does not imply orientation of the user. So how does the app know if two people are facing each other, or away from each other? You could try to rely on orientation of the phone, but you don't know if the user put the phone in their pocket face forwards, face backwards, or if it's actually in a bag situated sideways, etc.Now when you start adding other sensors into the mix (which is what I was talking about earlier), it is more feasible to do, but that's the original argument I was making... That you need to rely on more than just simple wifi beacon packet sniffing.

Have you actually done wireless research? No? Then STFU. I've tracked BT and WiFi simultaneously. Tracking GSM is pointless becuase you will only be in range of a single tower. If you actually read my previous posts, I was talking about using wifi only, because the original poster was talking about wifi only. And yes, I've done configurations where equipment is deployed strategically/and purposely. But that's not what I was talking about in this thread because I was talking about just the use of wifi in a public place with non-managed equipment, because the original poster was talking about Google doing tracking at abritrary locations where the equipment was not necessarily deployed for the purposes of tracking.

That type of tracking is very different.. They geo-tagged the MAC address of the AP (which is what they are doing when they drive their car around). The client software then looks at which AP has the highest signal strength, then they use the GPS location of that AP as your location. I haven't looked in a while, but the maps API used to expose an API where you sent the MAC address, and it returned the GPS coordinates of that AP. I played with it once, and changed the least significant bit on the MAC of my AP, and it said my location was in New Jersey somewhere. So now I know where the person that bought the router that was next to mine on the production line...

The type of tracking I was referring to earlier, was dealing with AP's that were not necessarily geo-tagged, since I was dealing with trying to build something on top of public (or private) infrastructure that wasn't managed by the parties involved. So for example, a proper solution involved deploying a number of AP's in a specific location, in a specific pattern, etc, with the each AP geo-tagged. The solution I was dealing with, was trying to figure out proximity and rough location tracking (think of the game Marco Polo), where you don't know the location of any of the APs around you, as they are not yours.