I've discovered a technique enabling any app to infer the user location without its consent to a probably 10/20km radius using the FMRadio API. Description at https://groups.google.com/d/msg/mozilla.dev.webapi/9IqWCLnjnNE/NVxzDc2_jRkJ I recommand moving the FMRadio app to a privileged API for this reason.

Jonas & Lucas - Thoughts?

I'm curious whether a similar or better granularity be determined just by the IP address of the device? Certainly seems true for wifi, not sure about cell.

10/20km was a guesstimate. I've done a more educated approximation [1] and found ~17km radius. Lucas Adamski from comment #2 : > I'm curious whether a similar or better granularity be determined just by > the IP address of the device? Certainly seems true for wifi, not sure about > cell. I've been wondering about how it compares to other techniques. Do we have a guideline of what's acceptable in terms of probability/accuracy to infer the user's location without its consent? [1] https://groups.google.com/d/msg/mozilla.dev.webapi/9IqWCLnjnNE/ybJOqHdbTYQJ

I definitely suspect that being able to position the user within a 17km radius is not something we're cool with. IP addresses can be manually obscured by using VPNs. Additionally I think IP addresses are hard to use for location when connecting through cell networks.

Randy, are you the right assignee for this?

OK, I will try to do this.

Curious, why not tef? on this bug? Seems like if we were to fix this, we would want to fix this in v1.01 and subsequent branches. Or is this not bad enough to tef block?

Noming this up to tef - very safe patch that protects against determining a user's location within 10/20 km radius with FM Radio app seems like something we really should take into v1.01.

(In reply to Jason Smith [:jsmith] from comment #9) > Noming this up to tef - very safe patch that protects against determining a > user's location within 10/20 km radius with FM Radio app seems like > something we really should take into v1.01. Note - when I say this, I mean we're preventing hosted apps (web type) from having this capability. Only privileged apps would then get access to FM Radio, which will go through formal code reviews on marketplace for safety.

(i don't see a reason to not take this in tef)

Several things: 1. As stated by Lucas here and myself on the parallel argument on dev-webapi, I don't think you get better granularity with this than you get with pure IP geolocation. And that's even true with cellular access, at least here (and knowing the network structure, it should be true anywhere too). 2. It's been stated that you can hide your IP using a VPN or a proxy. Only you can't since we don't support proxy configuration nor any kind of meaningful VPN AFAIK. And it's much easier, quicker and reliable just to use IP than using radio matching geolocation. 3. We're making this more restrictive than pure Geolocation. If we still think this is a problem, why not make it an explicit permission instead of just denying it? 4. Doesn't this patch break the tests? I'm thinking on [1], concretely. [1] https://mxr.mozilla.org/mozilla-central/source/dom/tests/browser/browser_webapps_permissions.js#30

1. I think the fmradio api should be privileged because if we allow installed AP to use this kind of HW related api, the AP may not control the fm function well and result in a.noise output b. power leakage. 2. oh...test case..thanks for your reminding. I will change it and make sure it can pass.

I hope we're planning on supporting VPN down the road. But if we expose this API now, it means that we can't change that (or at least it'll be very hard to change that) once we have VPN support. Note that this patch isn't denying FMRadio access. It just means that you have to be a privileged app. So anyone can still get access to it by submitting a app to the firefox marketplace. I think changing the API to being explicit would work great too. But there's no way to add that UI at this point. But it's something we can look at doing for v1.1

(In reply to Antonio Manuel Amaya Calvo from comment #12) > 1. As stated by Lucas here and myself on the parallel argument on > dev-webapi, I don't think you get better granularity with this than you get > with pure IP geolocation. And that's even true with cellular access, at > least here (and knowing the network structure, it should be true anywhere > too). During the study, I've noticed that I don't make a perfect match. It would require much more work, but maybe inference on missed frequencies could provide better accuracy. It's much more work on the attacker side (much more complex modeling), but might work. Regardless, as a security non-expert, radio non-expert, in about an hour of work, I've demonstrated a realistic technique to geolocalize a user to an approximated 17km. I feel this is enough to demonstrate a privacy risk. An attacker with more resources can improve the technique, maybe cross it with other different techniques (like IP) to make even more accurate measurements, etc. > 2. It's been stated that you can hide your IP using a VPN or a proxy. Only > you can't since we don't support proxy configuration nor any kind of > meaningful VPN AFAIK. Is there a bug about that? That sounds like a valuable expert feature. > 3. We're making this more restrictive than pure Geolocation. If we still > think this is a problem, why not make it an explicit permission instead of > just denying it? Very good point. I suggested to make the API privileged out of lack of a better idea, but I feel "prompt" permission would work too. If a user is asked access to the radio for applications where the user doesn't expect the radio to be used, it would probably be enough for the user to think something fishy is going on. Privileged and certified apps have gone through a security review, so no need to prompt the user. Hmm... But the API is sync. How do we ask for permission without blocking the entire app?

I may remove the fmradio test item in the browser test app locate in dom/tests/browser. waiting try-server result. Is there exist any test case I cab add for privileged test case?

https://tbpl.mozilla.org/?tree=Try&rev=89be243ec862 try server result.

Not sure why this needs to be privileged. Simply making it explicit would take care of the main risk, which is silent profiling of user location.

(In reply to Lucas Adamski from comment #18) > Not sure why this needs to be privileged. Simply making it explicit would > take care of the main risk, which is silent profiling of user location. Certainly true, but we haven't implemented strings for FM Radio perm prompts nor have tested that flow. So switching to a PROMPT_ACTION approach introduces a late-l10n risk. It might be better at this point to go for privileged apps only for v1.01. For v1.1, we should push for PROMPT_ACTION support on a hosted web-based app.

I'm not convinced that PROMPT protect us there. When we prompt for geolocation it's clear that we will get the user location. When we prompt for FM radio, the user can still be tracked and the bad behavior hidden by some seemingly legit use.

It's tef+, do we still want to fmradio api to be privileged?

Yes, let's do privileged here. I agree that making it prompt might be a better solution (though explaining to user is tricky), but that's too big of a change right now. We'd need both supporting code and supporting strings. But please file a followup to look into that later.

Comment on attachment 724252 [details] [diff] [review] path2 Review of attachment 724252 [details] [diff] [review]: ----------------------------------------------------------------- r=me, but do a try build before landing.

The try server result seems fine. https://tbpl.mozilla.org/?tree=Try&rev=89be243ec862

(In reply to Jonas Sicking (:sicking) from comment #22) > Yes, let's do privileged here. On behalf of third-party devs everywhere: Yay!

Someone might want to file the followup bug doing the work to get PROMPT_ACTION support with FM Radio in a hosted app.

https://hg.mozilla.org/releases/mozilla-b2g18/rev/c1ff1962f8e5 https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/3ef0e10bb5c4

Should I add this info to the MDN docs now: that FMRadio permission requires privileged apps?

(In reply to Mark Giffin from comment #30) > Should I add this info to the MDN docs now: that FMRadio permission requires > privileged apps? I'd just change the FM Radio permission in the App Permissions page to indicate that that app has to be privileged now.