Inferring the user location from emitting FM radio frequencies

[David Bruant]

Hi,

This is a followup to recent discussion on this same mailing-list [1]
about how the FMRadio API [2] could be abused to infer the user
geolocalization without its consent.

I think dev-webapi isn't the best list to share this info, but I don't
know which other mailing-list would be relevant. Feel free to forward to
relevant mailing-lists and cc me.


# Background

The FMRadio API is currently available to any app. No need to be a
privileged or certified app.
The FMRadio API contains two convenient methods seekUp and seekDown.
These methods automatically find the next frequency (higher or lower
respectively) which emits a radio station. When a frequency is found, a
"frequencychange" event is fired and the current frequency can be
retrieved thanks to the FMRadio.frequency property.

# Inferring the geoloc using frequencies

## Getting all frequencies emitting something

Using seekUp and the frequency property, it's possible to find all
frequencies available to a user at a given time. I've written a script
[3] to that effect. In about 30 seconds, it was able to find all
frequencies available to me [4] (I live in Bordeaux, France). The only
thing this script requires is an antenna plugged to the phone. Any
headset will do the role of an antenna, users may have handsets plugged
for other reasons than Antenna, like a phone call, listening to music or
online TV/film.

## Radio frequency databases

In a matter of minutes, I've been able to find a database of all
frequencies available in France [5], region by region.
I assume it is quite easy to do the same for any country and build up a
database of all used frequencies for a given region.

## Matching infos

A quick look at the page of where I live [6] shows a very strong (but
not perfect, a handful are missing) match between these frequencies and
the one found by my script. A look at frequencies in other places show a
very strong mismatch (not entire mismatch of course, some same
frequencies are used in different places).
I feel it's pretty clear that the user geolocalization can be inferred
from the set of used frequencies to the accuracy of maybe 10/20km radius.

# Threat to privacy

Since any app can use the FMRadio API, any app can ship a small library
inferring the user geolocation based on frequencies (if the user has a
handset plugged in) without the user consent.

# Recommendation

Since the geolocalization of the user can be inferred at a small
granularity, I recommend moving the FMRadio API to a privileged API.

David

[1]
https://groups.google.com/d/msg/mozilla.dev.webapi/viKr7qCiKaM/1mInwM9HRXsJ
[2] https://developer.mozilla.org/en-US/docs/DOM/WebFM
[3] https://gist.github.com/DavidBruant/5118781#file-freqs-js
[4] https://gist.github.com/DavidBruant/5118781#file-bordeauxfreqs-json
[5] http://www.annuradio.fr/
[6] http://www.annuradio.fr/index.php?mode=searchville&choixville=BORDEAUX

[David Bruant]

Le 08/03/2013 20:21, David Bruant a écrit :
> I feel it's pretty clear that the user geolocalization can be inferred
> from the set of used frequencies to the accuracy of maybe 10/20km radius.

That was a guesstimate. Let's try to make a more educated approximation.
The Gironde department has 12 "radio agglomerations" [1].
Gironde is 10,725km² [2], so finding the proper "agglomeration" is
roughly finding a 893,75km² area which is a circle of 16,87km of radius.

That's a rough but realistic estimate (which actually is much better
than what HTML5 geoloc provides sometimes :-/)

David

[1] http://www.brume.org/radios/index.php?mode=searchdep&nodep=33
[2] http://fr.wikipedia.org/wiki/Gironde_%28d%C3%A9partement%29

[Doug Turner]

geoip is < 40km for many countries already. (see maxmind's db)

[Doug Turner]

geoip is < 40km for many countries already. (see maxmind's db)



On 3/8/13 11:42 AM, David Bruant wrote:

[Doug Turner]

geoip is < 40km for many countries already. (see maxmind's db)



On 3/8/13 11:42 AM, David Bruant wrote:

[David Bruant]

Le 08/03/2013 20:52, Doug Turner a écrit :
> geoip is < 40km for many countries already. (see maxmind's db)

Interesting.
Accuracy is debatable in the different countries [1]. I wonder how this
compares with the radio frequency technique.

David

[1] http://www.maxmind.com/en/city_accuracy

[David Bruant]

Also, IP geoloc can be bypassed with a proxy/VPN for those who really care.
Hard to achieve the same level of protection against a 30sec script
running directly on your phone and can be hidden in any app.

David

[Doug Turner]

It is a neat attack surface, but I am not sure you'll get the precision
for anything meaningful. In any case, exposing FM Radio to every app
never felt right.

[Mounir Lamouri]

On 08/03/13 21:05, Doug Turner wrote:
> It is a neat attack surface, but I am not sure you'll get the precision
> for anything meaningful. In any case, exposing FM Radio to every app
> never felt right.

Given that FM Radio is behind a preference, I think this problem is
highly mitigated. It's then up to the UA to show a UI that makes it
clear that allowing fm-radio to an application is more than just giving
access to the FM hardware but also to the user location.

Is this API available to any web content or only installed applications?

Cheers,
--
Mounir

[David Bruant]

[Larissa: I'm cc'ing you to get your opinion. Search for your name to
understand where. For context, full thread at
https://groups.google.com/forum/#!msg/mozilla.dev.webapi/9IqWCLnjnNE/NVxzDc2_jRkJ
]

Le 09/03/2013 11:06, Mounir Lamouri a écrit :
> On 08/03/13 21:05, Doug Turner wrote:
>> It is a neat attack surface, but I am not sure you'll get the precision
>> for anything meaningful. In any case, exposing FM Radio to every app
>> never felt right.
> Given that FM Radio is behind a preference, I think this problem is
> highly mitigated.

What do you mean by "behind a preference"? It's currently available to
any app without consent ("implicit" in terms of the security model)

> It's then up to the UA to show a UI that makes it
> clear that allowing fm-radio to an application is more than just giving
> access to the FM hardware but also to the user location.

Taking the freedom to cc Larissa Co to get her opinion on the topic as
she's been working on UX/UI related to security recently.

> Is this API available to any web content or only installed applications?

The security page [1] says that Web Content has the "Explicit"
Authorization model. But usually, "explicit" means that you need to add
the permission to a Manifest, which doesn't apply to web content... so
I'm not sure what that means.

David

[1] https://wiki.mozilla.org/WebAPI/Security/FMRadioAPI

[Andy Buckingham]

Just to add some background with experience as a radio broadcaster and
with specific interest in the areas of identifying radio stations from
broadcast parameters...

This method of identification is slow and complicated, put significant
resource burden on the party interested in looking up received params
to stations (and thereby location) and likely to offer similar
accuracy to simple GeoIP. The available data in each region for
stations available is inconsistent and generally of very poor quality.
Weather, buildings and other changing variables impact on FM reception
from day to day make it very hard to reliably reuse received data from
one day to the next.

Nokia have shipped far in excess of 100 million+ handsets with FM
radio support and the appropriate FM api work, as have a number of
Android devices and Windows Phone - all capable of the same steps
outlined above. To the best of my knowledge none apply specific
security around FM radio access and there have been no reported issues
or negative feedback from users.

> I feel it's pretty clear that the user geolocalization can be inferred from
> the set of used frequencies to the accuracy of maybe 10/20km radius.
>

[Doug Turner]

[Doug Turner]

On 3/10/13 1:15 AM, Andy Buckingham wrote:

[Doug Turner]

Andy,

Thanks for your feedback. This is what I expected to hear.

Regards,
Doug

On 3/10/13 1:15 AM, Andy Buckingham wrote:

[Doug Turner]

Andy,

Thanks for your feedback. This is what I expected to hear.

Regards,
Doug

On 3/10/13 1:15 AM, Andy Buckingham wrote:

[Doug Turner]

Andy,

Thanks for your feedback. This is what I expected to hear.

Regards,
Doug

On 3/10/13 1:15 AM, Andy Buckingham wrote:

[ANTONIO MANUEL AMAYA CALVO]

On the same line, I don't think you can get a finer location using this method than the one you can get just by using just the user IP. And any app (or web page actually) can get that without any permission.

Best regards,

Antonio

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Larissa Co]

On 3/9/13 4:00 AM, David Bruant wrote:
> [Larissa: I'm cc'ing you to get your opinion. Search for your name to
> understand where. For context, full thread at
> https://groups.google.com/forum/#!msg/mozilla.dev.webapi/9IqWCLnjnNE/NVxzDc2_jRkJ
> ]
>

Hi all,

I don't know how useful it is for me to reply since the thread seems to
have resolved itself already. I can offer a couple of thoughts from UX
though.

First of all-- David, thanks for the very concise first post. I usually
have to piece together an understanding of the security issue from
numerous threads before I really get it ;-)

From Andy et. al.'s comments, it sounds like the security threat is
fairly low risk. Given that, I would be hesitant to even inform the user
that he could potentially be sharing his location by granting access to
the FM radio. It's not something that is intuitive to users so I think
it would create unnecessary concern, especially for novices who don't
have the sense for how small or how big the risk is. In any case, if
there is a clear security risk, I think it's our job to mitigate it when
we can, rather than warn the user and rely on their best judgement.

In terms of what "explicit" means: It means that for Web content, the
user has to grant explicit permission before it can access FM radio.
This permission likely comes in the form of a doorhanger or dialog at
the moment when the web content requests access (IIRC). I like that
we've chosen this model because it informs the user in the context of
his task, and helps him decide whether it's a valid permission to
provide at the moment.

Whether we decide that we should escalate the risk for FM radio and make
this permission explicit for installed web apps too is something for the
Security team to decide. Of course, every time we ask for permission, we
interrupt the user's task, so we have to weigh that interruption against
the potential risk and the magnitude of that interruption.

Incidentally, a similar question has already come up regarding access to
media storage and inadvertent access to any geolocation metadata
associated with that media. I think it's worth me touching base with the
B2G security folk at some point to address the general UX response we
want for these kinds of situations.

Best,
Larissa

[Mounir Lamouri]

On 09/03/13 04:00, David Bruant wrote:
> [Larissa: I'm cc'ing you to get your opinion. Search for your name to
> understand where. For context, full thread at
> https://groups.google.com/forum/#!msg/mozilla.dev.webapi/9IqWCLnjnNE/NVxzDc2_jRkJ
> ]
>

> Le 09/03/2013 11:06, Mounir Lamouri a écrit :
>> On 08/03/13 21:05, Doug Turner wrote:
>>> It is a neat attack surface, but I am not sure you'll get the precision
>>> for anything meaningful. In any case, exposing FM Radio to every app
>>> never felt right.
>> Given that FM Radio is behind a preference, I think this problem is
>> highly mitigated.
> What do you mean by "behind a preference"? It's currently available to
> any app without consent ("implicit" in terms of the security model)

I meant 'permission' not 'preference'. Apps have to list fm in their
permission list, right?

--
Mounir

[Josh Carpenter]

+1 for Larissa's comments. Full agreement.

> Incidentally, a similar question has already come up regarding access to media storage and inadvertent access to any geolocation metadata associated with that media. I think it's worth me touching base with the B2G security folk at some point to address the general UX response we want for these kinds of situations.

That would be great, Larissa.

Lucas, I know this isn't your beat anymore: can you point us to the right person to engage? Paul Theriault perhaps?


—
Josh Carpenter
UX Lead, Firefox OS
Mozilla

On Mar 12, 2013, at 12:15 PM, Larissa Co <l...@mozilla.com> wrote:

> On 3/9/13 4:00 AM, David Bruant wrote:
>> [Larissa: I'm cc'ing you to get your opinion. Search for your name to understand where. For context, full thread at https://groups.google.com/forum/#!msg/mozilla.dev.webapi/9IqWCLnjnNE/NVxzDc2_jRkJ ]
>>

> Hi all,
>
> I don't know how useful it is for me to reply since the thread seems to have resolved itself already. I can offer a couple of thoughts from UX though.
>
> First of all-- David, thanks for the very concise first post. I usually have to piece together an understanding of the security issue from numerous threads before I really get it ;-)
>
> From Andy et. al.'s comments, it sounds like the security threat is fairly low risk. Given that, I would be hesitant to even inform the user that he could potentially be sharing his location by granting access to the FM radio. It's not something that is intuitive to users so I think it would create unnecessary concern, especially for novices who don't have the sense for how small or how big the risk is. In any case, if there is a clear security risk, I think it's our job to mitigate it when we can, rather than warn the user and rely on their best judgement.
>
> In terms of what "explicit" means: It means that for Web content, the user has to grant explicit permission before it can access FM radio. This permission likely comes in the form of a doorhanger or dialog at the moment when the web content requests access (IIRC). I like that we've chosen this model because it informs the user in the context of his task, and helps him decide whether it's a valid permission to provide at the moment.
>
> Whether we decide that we should escalate the risk for FM radio and make this permission explicit for installed web apps too is something for the Security team to decide. Of course, every time we ask for permission, we interrupt the user's task, so we have to weigh that interruption against the potential risk and the magnitude of that interruption.
>
> Incidentally, a similar question has already come up regarding access to media storage and inadvertent access to any geolocation metadata associated with that media. I think it's worth me touching base with the B2G security folk at some point to address the general UX response we want for these kinds of situations.
>
> Best,
> Larissa
>

[ptheriault]

Josh, Larissa,

On Mar 15, 2013, at 2:01 PM, Josh Carpenter wrote:

> +1 for Larissa's comments. Full agreement.
>
>> Incidentally, a similar question has already come up regarding access to media storage and inadvertent access to any geolocation metadata associated with that media. I think it's worth me touching base with the B2G security folk at some point to address the general UX response we want for these kinds of situations.
>
>
> That would be great, Larissa.
>
> Lucas, I know this isn't your beat anymore: can you point us to the right person to engage? Paul Theriault perhaps?

I think would be a really useful exercise, I would be really keen to be involved in that. I'll contact you off list to work out a time.

[David Bruant]

Le 15/03/2013 03:07, Mounir Lamouri a écrit :

> On 09/03/13 04:00, David Bruant wrote:
>> [Larissa: I'm cc'ing you to get your opinion. Search for your name to
>> understand where. For context, full thread at
>> https://groups.google.com/forum/#!msg/mozilla.dev.webapi/9IqWCLnjnNE/NVxzDc2_jRkJ
>> ]
>>

>> Le 09/03/2013 11:06, Mounir Lamouri a écrit :
>>> On 08/03/13 21:05, Doug Turner wrote:
>>>> It is a neat attack surface, but I am not sure you'll get the precision
>>>> for anything meaningful. In any case, exposing FM Radio to every app
>>>> never felt right.
>>> Given that FM Radio is behind a preference, I think this problem is
>>> highly mitigated.
>> What do you mean by "behind a preference"? It's currently available to
>> any app without consent ("implicit" in terms of the security model)
> I meant 'permission' not 'preference'. Apps have to list fm in their
> permission list, right?

Yes yes. I don't see how having "FM" listed in the app permissions
mitigates the fact that the API is available to any app. Taken from a
different angle, I've been surprised as an app developer to have to list
FM is the permission (with '{}' as value :-/) to use the API as I assume
it was supposed to be available to all anyway.

David

[Lucas Adamski]

I think Paul + Larissa would be the dream team for this conversation. :) That said I'd love to have that/this conversation in the already public thread.
Lucas.

On Mar 14, 2013, at 8:01 PM, Josh Carpenter wrote:

> +1 for Larissa's comments. Full agreement.
>
>> Incidentally, a similar question has already come up regarding access to media storage and inadvertent access to any geolocation metadata associated with that media. I think it's worth me touching base with the B2G security folk at some point to address the general UX response we want for these kinds of situations.
>
>
> That would be great, Larissa.
>
> Lucas, I know this isn't your beat anymore: can you point us to the right person to engage? Paul Theriault perhaps?
>
>

> —
> Josh Carpenter
> UX Lead, Firefox OS
> Mozilla
>
> On Mar 12, 2013, at 12:15 PM, Larissa Co <l...@mozilla.com> wrote:
>

>> On 3/9/13 4:00 AM, David Bruant wrote:
>>> [Larissa: I'm cc'ing you to get your opinion. Search for your name to understand where. For context, full thread at https://groups.google.com/forum/#!msg/mozilla.dev.webapi/9IqWCLnjnNE/NVxzDc2_jRkJ ]
>>>

[ptheriault]

On Mar 15, 2013, at 8:10 PM, David Bruant wrote:

> Le 15/03/2013 03:07, Mounir Lamouri a écrit :

>> On 09/03/13 04:00, David Bruant wrote:
>>> [Larissa: I'm cc'ing you to get your opinion. Search for your name to
>>> understand where. For context, full thread at
>>> https://groups.google.com/forum/#!msg/mozilla.dev.webapi/9IqWCLnjnNE/NVxzDc2_jRkJ
>>> ]
>>>

>>> Le 09/03/2013 11:06, Mounir Lamouri a écrit :
>>>> On 08/03/13 21:05, Doug Turner wrote:
>>>>> It is a neat attack surface, but I am not sure you'll get the precision
>>>>> for anything meaningful. In any case, exposing FM Radio to every app
>>>>> never felt right.
>>>> Given that FM Radio is behind a preference, I think this problem is
>>>> highly mitigated.
>>> What do you mean by "behind a preference"? It's currently available to
>>> any app without consent ("implicit" in terms of the security model)
>> I meant 'permission' not 'preference'. Apps have to list fm in their
>> permission list, right?
> Yes yes. I don't see how having "FM" listed in the app permissions mitigates the fact that the API is available to any app.

It means that it this API isn't available to regular web content - the content must be in an app that has to be explicitly installed by the user. This is not a strong mitigation, but we did actually consider this threat when doing the secreview and concluded (arguably prematurely) that it wasn't a significant threat, especially considering geoip considerations.

FWIW, there are a few papers on the subject:
* http://research.microsoft.com/en-us/um/people/horvitz/rightspot_constraints.pdf
* METROPOLITAN-SCALE LOCATION ESTIMATION USING FM RADIO WITH ANALYSIS OF MEASUREMENTS: Shih-Hau Fang, Jen-Chian Chen, Hau-Ru Huang, and Tsung-Nan Lin (dont have link sorry...)

However IIRC, the approach in both of those papers requires features which the API doesn't provide.

> Taken from a different angle, I've been surprised as an app developer to have to list FM is the permission (with '{}' as value :-/) to use the API as I assume it was supposed to be available to all anyway.

We have a taken a "least privilege" approach to permissions in Firefox OS - that is apps which ask for no additional privileges are treated no differently to web content. The original intent was that app need to declare any permission they want to use, and also to document a reason why they need it. These usage intentions were dropped somewhere along the way, but I hope to see them returned in future versions.

BTW {} is the value for all most permissions. Only those which allow further controls over granularity have attributes inside the {}. See the "access" property in https://developer.mozilla.org/en-US/docs/Apps/App_permissions. Or the code https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsTable.jsm#36





>
> David

[Larissa Co]

On 3/15/13 4:34 PM, Lucas Adamski wrote:
> I think Paul + Larissa would be the dream team for this conversation. :) That said I'd love to have that/this conversation in the already public thread.
> Lucas.
>
>

I agree about keeping it on a list. Is dev-webapi the best list for
this? Or are there broader issues that require a different list?

Paul, Don't know the best way to start this. Do you have outstanding
issues in mind, or do you want to do a UX audit of the current
permission model with me, and have the list involved? Let me know!

Larissa

[Jonas Sicking]

Same here, please invite me to whatever meeting is set up.

/ Jonas

On Mar 15, 2013 4:34 PM, "Lucas Adamski" <lada...@mozilla.com> wrote:

> I think Paul + Larissa would be the dream team for this conversation. :)
> That said I'd love to have that/this conversation in the already public
> thread.
> Lucas.
>

> On Mar 14, 2013, at 8:01 PM, Josh Carpenter wrote:
>
> > +1 for Larissa's comments. Full agreement.
> >
> >> Incidentally, a similar question has already come up regarding access
> to media storage and inadvertent access to any geolocation metadata
> associated with that media. I think it's worth me touching base with the
> B2G security folk at some point to address the general UX response we want
> for these kinds of situations.
> >
> >
> > That would be great, Larissa.
> >
> > Lucas, I know this isn't your beat anymore: can you point us to the
> right person to engage? Paul Theriault perhaps?
> >
> >
> > —
> > Josh Carpenter
> > UX Lead, Firefox OS
> > Mozilla
> >
> > On Mar 12, 2013, at 12:15 PM, Larissa Co <l...@mozilla.com> wrote:
> >

> >> On 3/9/13 4:00 AM, David Bruant wrote:
> >>> [Larissa: I'm cc'ing you to get your opinion. Search for your name to
> understand where. For context, full thread at
> https://groups.google.com/forum/#!msg/mozilla.dev.webapi/9IqWCLnjnNE/NVxzDc2_jRkJ]
> >>>

[Doug Turner]

ditto. i know a bit about geolocation and device storage.

[Doug Turner]

ditto. i know a bit about geolocation and device storage.

On 3/16/13 9:26 PM, Jonas Sicking wrote:

[Doug Turner]

ditto. i know a bit about geolocation and device storage.

On 3/16/13 9:26 PM, Jonas Sicking wrote:

[ptheriault]

Re: your note earlier in the thread about the " similar question has already come up regarding access to media storage and inadvertent access to any geolocation metadata associated with that media."

I am not sure these two situations are really that linked. I see the "location disclosed in exif information" issue as an is more an App design issue. (specifically, the activity handlers can and should restrict access to geolocation data, as was done in bug 840208). In the radio case it was more a limitation of our permission model - it would have been nice if we could expose Web FM to all apps, and have a permission prompting mechanism which adequately mitigates the risk of location disclosure. However the conclusion of bug 849335 was the making the FM radio permission explicit for regular web apps was not a strong enough control because it is difficult to convey to the user that allowing an app to access radio may disclose their location.

On Mar 16, 2013, at 11:53 AM, Larissa Co wrote:

> On 3/15/13 4:34 PM, Lucas Adamski wrote:
>> I think Paul + Larissa would be the dream team for this conversation. :) That said I'd love to have that/this conversation in the already public thread.
>> Lucas.
>>
>>

> I agree about keeping it on a list. Is dev-webapi the best list for this? Or are there broader issues that require a different list?
>
> Paul, Don't know the best way to start this. Do you have outstanding issues in mind, or do you want to do a UX audit of the current permission model with me, and have the list involved? Let me know!

Hey this was your idea, you lead the charge! :) UX audit sounds like a useful exercise to me. (new thread maybe? this list is appropriate I think since we did the initial permissions discussions here). But honestly, I am little unclear though what we are trying to 'solve' - is the idea to analyze what we have ended up with for v1 to inform future permissions model UX?

If so, then some initial thoughts to get the ball rolling:
1. For explicit prompts to be effective, users must understand the implications of allowing the API in question (ie. radio problem above)
2. Apps can't be sure when a prompt will be shown (afaik), which leads to...
3. Prompts don't necessarily relate to task user is conducting (e.g. prompting for geolocation when the starts the camera app or everything.me)
4. Prompts are all or nothing (e.g. can't grant access to this location , but not other locations. Or grant access to these photos, but not THOSE photos)
5. (some) Decisions remembered forever, user not reminded of permission decision (blink and you miss it).


-Paul