On 10/09/13 19:05, Chris Peterson wrote:
Our location service (and stumbler) also collects cell data, so we can
geolocate with Wi-Fi AP and/or cell data.
Sure. But in the rural areas I am thinking about, cells cover many
square km. The wifi access point has a much smaller range, and therefore
On 9/11/13 9:59 AM, Hanno Schlichting wrote:
But at this point it seems clear to me, that there's likely no way to share any
meaningful subset or aggregated version of this data publicly at all.
No way to share the Wi-Fi data. Our stumblers are also collecting cell
tower data and I don't see
On 10.09.2013, at 20:23 , ianG i...@iang.org wrote:
On 11/09/13 03:27 AM, Daniel Veditz wrote:
private means we can't even /look/ at it, rather than merely can't
store it?
The data regime might be simply put as this: you can't store a number
suitable for tracking (or any derivative of it
On 10.09.2013, at 17:41 , Daniel Veditz dved...@mozilla.com wrote:
That can't be right, so your database must be more complex. If you're
storing more than originally implied that may have some impact on a
security assessment.
We apparently haven't been clear about the scope of the proposal. It
On 11.09.2013, at 02:06 , Gervase Markham g...@mozilla.org wrote:
On 10/09/13 19:05, Chris Peterson wrote:
Our location service (and stumbler) also collects cell data, so we can
geolocate with Wi-Fi AP and/or cell data.
Sure. But in the rural areas I am thinking about, cells cover many
On 9/9/13 6:13 PM, Brian Smith wrote:
I assume by prevents people from tracking individual access points
means the following: Some people have a personal access point on them
(e.g. in their phone). If somebody knows the SSID and MAC of this
personal access point, then they could track this
On 10/09/13 00:58 AM, Chris Peterson wrote:
I'm looking for some feedback on crypto privacy protections for a
geolocation research project I'm working on with the Mozilla Services
team. If you have general questions or suggestions about the project,
I'm happy to answer them, but I'd like to
On 10/09/13 06:05, Chris Peterson wrote:
The device would scan for nearby APs and send the hash of each AP's MAC
and SSID to our location server. Our server would not need to worry
about the hash of hashes pairs because that would only be used for
published data. The server would return an
On 10/09/13 08:04, Henri Sivonen wrote:
1) Android has a mechanism for detecting when it is connecting to a
portable AP provided by another Android device. Can we use the same or
a similar detection mechanism to detect portable APs and filter them
out?
I suspect actually connecting to the
On 10/09/13 00:25, R. Jason Cronk wrote:
Is the data aged?
Not AFAIAA.
What happens if I move?
The raw database notes that you are now being detected in a new
location. What happens then is up for debate. I'd argue that if your
position was fixed for N months before, and it seems fixed again
On 09/09/13 22:58, Chris Peterson wrote:
Google's Location Service prevents people from tracking individual
access points by requiring requests to include at least 2-3 access
points that Google knows are near each other. This proves the
requester is near the access points.
Related question:
On 10/09/13 10:48, ianG wrote:
If that is the case, why not flip it around. Instead of trying to
interpolate the existing data that is broadcast out there, why not write
a protocol to broadcast the direct location from the wireless access point?
Because only a tiny, tiny fraction of devices
On 9/10/13 3:46 AM, Gervase Markham wrote:
I believe the plan is to have a database of raw findings, then a
processed database used by the web service, and a published database
which may have even more data reduction.
Chris P: can we get permission to store the raw SSID in the
_unpublished_
On 9/9/13 6:13 PM, Brian Smith wrote:
On Mon, Sep 9, 2013 at 2:58 PM, Chris Peterson cpeter...@mozilla.com wrote:
Google's Location Service prevents people from tracking individual access
points by requiring requests to include at least 2-3 access points that
Google knows are near each other.
On 9/10/13 3:46 AM, Gervase Markham wrote:
Related question: it would be great if there were some way to lift this
restriction, at least for the web service if not for the database, while
preserving the necessary privacy protections. My family's house, which
is in a rural area, has a single
On 10.09.2013, at 03:46 , Gervase Markham g...@mozilla.org wrote:
On 10/09/13 10:48, ianG wrote:
If that is the case, why not flip it around. Instead of trying to
interpolate the existing data that is broadcast out there, why not write
a protocol to broadcast the direct location from the
On 9/10/13 11:53 AM, Stefan Arentz wrote:
I wonder if it makes sense to ban specific MAC address ranges (vendors) from
appearing in this database. For example I think it would be possible to detect
specific chipsets as being mobile devices vs stationary access points.
Our stumbler does some
On 10.09.2013, at 03:39 , Gervase Markham g...@mozilla.org wrote:
BTW, how does the service figure out the lat/long of an AP? Do we do
anything at all with signal strengths? Could we?
This is a bit off-topic for the security discussion.
I suggest starting a new thread on dev-geolocation, if
On Sep 9, 2013, at 9:13 PM, Brian Smith br...@briansmith.org wrote:
On Mon, Sep 9, 2013 at 2:58 PM, Chris Peterson cpeter...@mozilla.com wrote:
Google's Location Service prevents people from tracking individual access
points by requiring requests to include at least 2-3 access points that
On 9/10/2013 3:46 AM, Gervase Markham wrote:
On 10/09/13 00:25, R. Jason Cronk wrote:
Does this give Mozilla the
ability to historically track me if I move my device?
Yes; this is why publishing the full raw stumbled data sets is sadly
going to be not possible.
Why would we have two
On 9/10/2013 10:09 AM, Hanno Schlichting wrote:
As of this moment, we filter out any AP that has been detected in two
different places (where different means more than ~1km away from each
other). This is very conservative approach and we'll relax that
later.
What do you mean by filtered out?
On 11/09/13 03:27 AM, Daniel Veditz wrote:
On 9/9/2013 11:21 PM, Chris Peterson wrote:
The primary motivation for hashing the MAC+SSID was to avoid uploading
the SSID (which is considered private data in some European countries)
private means we can't even /look/ at it, rather than merely
I haven't done a full analysis but do have a few questions
On 9/9/2013 5:58 PM, Chris Peterson wrote:
Our private database maps access point hash IDs to locations (and
other metadata). Assuming:
H1 = Hash(AP1.MAC + AP1.SSID)
H2 = Hash(AP2.MAC + AP2.SSID)
I assume + means
On Mon, Sep 9, 2013 at 2:58 PM, Chris Peterson cpeter...@mozilla.com wrote:
Google's Location Service prevents people from tracking individual access
points by requiring requests to include at least 2-3 access points that
Google knows are near each other. This proves the requester is near the
Chris,
I have some basic and perhaps stupid questions.
1. How do I bootstrap? I turn on my device and want to get the coordinates of
the aps I see. That requires a lat long for neighbors. What now?
2. As asked previously will the db be published or query able?
3. What is the lat/long
On 09.09.2013, at 18:41 , Eric Rescorla e...@rtfm.com wrote:
1. How do I bootstrap? I turn on my device and want to get the coordinates of
the aps I see. That requires a lat long for neighbors. What now?
We build the database by having people use a stumbler application to sent us
On Mon, Sep 9, 2013 at 7:15 PM, Hanno Schlichting
hschlicht...@mozilla.com wrote:
On 09.09.2013, at 18:13 , Brian Smith br...@briansmith.org wrote:
On Mon, Sep 9, 2013 at 2:58 PM, Chris Peterson cpeter...@mozilla.com wrote:
[T]here's one crucial difference between Google and us: We would
like
On 9/9/13 4:25 PM, R. Jason Cronk wrote:
On 9/9/2013 5:58 PM, Chris Peterson wrote:
Our private database maps access point hash IDs to locations (and
other metadata). Assuming:
H1 = Hash(AP1.MAC + AP1.SSID)
H2 = Hash(AP2.MAC + AP2.SSID)
I assume + means concatenate. I might suggest
28 matches
Mail list logo