Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
WebAPI Security Discussion:Wifi API
10 views
Skip to first unread message
Paul Theriault
May 8, 2012, 5:24:31 PM5/8/12
to dev-w...@lists.mozilla.org, Mozilla B2G mailing list, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org
Please reply-tod...@lists.mozilla.org
Name of API: Wifi API
Reference:
http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/ed980c42261c5f4a?pli=1
Brief purpose of API: Detect and connect to wifi networks, to support a
wifi management app.
General Use Cases: None
Inherent threats: Privacy(identify user, geolocation, based on wifi
characteristics), Denial of Service, Unexpected or unauthorized network
connections (e.g. connect to home wifi network ?)
Threat severity: High
== Regular web content (unauthenticated) ==
Use cases for unauthenticated code:None
Authorization model for normal content:
Authorization model for installed content:
Potential mitigations:
== Trusted (authenticated by publisher) ==
Use cases for authenticated code:
* Wifi sniffer app
* Wifi provider connection app (e.g. connect to provider X hotspots with
authentication credentials)
Use cases for trusted code: Explicit
Potential mitigations:
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Wifi Manager
Authorization model: Implicit
Potential mitigations:
Name of API: Wifi API
Reference:
http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/ed980c42261c5f4a?pli=1
Brief purpose of API: Detect and connect to wifi networks, to support a
wifi management app.
General Use Cases: None
Inherent threats: Privacy(identify user, geolocation, based on wifi
characteristics), Denial of Service, Unexpected or unauthorized network
connections (e.g. connect to home wifi network ?)
Threat severity: High
== Regular web content (unauthenticated) ==
Use cases for unauthenticated code:None
Authorization model for normal content:
Authorization model for installed content:
Potential mitigations:
== Trusted (authenticated by publisher) ==
Use cases for authenticated code:
* Wifi sniffer app
* Wifi provider connection app (e.g. connect to provider X hotspots with
authentication credentials)
Use cases for trusted code: Explicit
Potential mitigations:
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Wifi Manager
Authorization model: Implicit
Potential mitigations:
Mike Hanson
May 8, 2012, 5:28:41 PM5/8/12
to Paul Theriault, dev-w...@lists.mozilla.org
Another use case - probably "authenticated" - is location inferrence. That would need SSIDs + signal strength but doesn't need all the other bits.
(See http://en.wikipedia.org/wiki/Beacon_frame for what you can get from a Beacon frame)
And - I think the thread caught this - that you can join a network without knowing its SSID, and that this is used as a (poor) security/obscurity feature by some users.
m
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
(See http://en.wikipedia.org/wiki/Beacon_frame for what you can get from a Beacon frame)
And - I think the thread caught this - that you can join a network without knowing its SSID, and that this is used as a (poor) security/obscurity feature by some users.
m
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
Adrienne Porter Felt
May 9, 2012, 11:44:44 AM5/9/12
to dev-w...@lists.mozilla.org
It seems like the WiFi API will contain a few different privileges, and
perhaps each one should be treated differently. (Note: everything in this
e-mail is referring to apps in the "Trusted code" category.)
* See current and nearby SSIDs -- This is essentially equivalent to the
location API, so I think it should be treated as such, with the same exact
UI as location.
* Connect to known networks -- Implicit. I don't see how this could be
harmful, especially if the phone is already set up to automatically connect
to known networks.
* Connect to new networks -- Agreed that this should be explicit. Maybe
this explicit UI could occur at runtime and be a slightly modified version
of the already-familiar "Would you like to connect to one of these new
networks?" dialog.
* Disconnect from networks -- Implicit. I don't see any reason to make
this explicit. It's simply annoying, not harmful, and the user can undo
the action. The Settings app could have a little annotation under "Network
status" that says the name of the app that last disconnected the user from
a network, so the user can identify and uninstall any potentially abusive
applications.
On Tue, May 8, 2012 at 2:24 PM, Paul Theriault <pther...@mozilla.com>wrote:
> Please reply-todev-webapps@lists.**mozilla.org<reply-tod...@lists.mozilla.org>
> browse_thread/thread/**ed980c42261c5f4a?pli=1<http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/ed980c42261c5f4a?pli=1>
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-security<https://lists.mozilla.org/listinfo/dev-security>
>
perhaps each one should be treated differently. (Note: everything in this
e-mail is referring to apps in the "Trusted code" category.)
* See current and nearby SSIDs -- This is essentially equivalent to the
location API, so I think it should be treated as such, with the same exact
UI as location.
* Connect to known networks -- Implicit. I don't see how this could be
harmful, especially if the phone is already set up to automatically connect
to known networks.
* Connect to new networks -- Agreed that this should be explicit. Maybe
this explicit UI could occur at runtime and be a slightly modified version
of the already-familiar "Would you like to connect to one of these new
networks?" dialog.
* Disconnect from networks -- Implicit. I don't see any reason to make
this explicit. It's simply annoying, not harmful, and the user can undo
the action. The Settings app could have a little annotation under "Network
status" that says the name of the app that last disconnected the user from
a network, so the user can identify and uninstall any potentially abusive
applications.
On Tue, May 8, 2012 at 2:24 PM, Paul Theriault <pther...@mozilla.com>wrote:
> Please reply-todev-webapps@lists.**mozilla.org<reply-tod...@lists.mozilla.org>
>
> Name of API: Wifi API
> Reference: http://groups.google.com/**group/mozilla.dev.webapi/**
> Name of API: Wifi API
> browse_thread/thread/**ed980c42261c5f4a?pli=1<http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/ed980c42261c5f4a?pli=1>
>
> Brief purpose of API: Detect and connect to wifi networks, to support a
> wifi management app.
> General Use Cases: None
>
> Inherent threats: Privacy(identify user, geolocation, based on wifi
> characteristics), Denial of Service, Unexpected or unauthorized network
> connections (e.g. connect to home wifi network ?)
>
> Threat severity: High
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code:None
> Authorization model for normal content:
> Authorization model for installed content:
> Potential mitigations:
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code:
> * Wifi sniffer app
> * Wifi provider connection app (e.g. connect to provider X hotspots with
> authentication credentials)
> Use cases for trusted code: Explicit
> Potential mitigations:
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: Wifi Manager
> Authorization model: Implicit
> Potential mitigations:
> ______________________________**_________________
> Brief purpose of API: Detect and connect to wifi networks, to support a
> wifi management app.
> General Use Cases: None
>
> Inherent threats: Privacy(identify user, geolocation, based on wifi
> characteristics), Denial of Service, Unexpected or unauthorized network
> connections (e.g. connect to home wifi network ?)
>
> Threat severity: High
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code:None
> Authorization model for normal content:
> Authorization model for installed content:
> Potential mitigations:
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code:
> * Wifi sniffer app
> * Wifi provider connection app (e.g. connect to provider X hotspots with
> authentication credentials)
> Use cases for trusted code: Explicit
> Potential mitigations:
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: Wifi Manager
> Authorization model: Implicit
> Potential mitigations:
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-security<https://lists.mozilla.org/listinfo/dev-security>
>
Paul Theriault
May 9, 2012, 12:51:01 PM5/9/12
to Adrienne Porter Felt, dev-w...@lists.mozilla.org
I had imagined that trusted would be explicit, but that this trust could
be remembered. But writing this email I am not so sure, as this would
effectively grant persistent access to geolocation information, so maybe
the permission should only be persisted per app session.
On 5/9/12 8:44 AM, Adrienne Porter Felt wrote:
> It seems like the WiFi API will contain a few different privileges, and
> perhaps each one should be treated differently. (Note: everything in this
> e-mail is referring to apps in the "Trusted code" category.)
>
> * See current and nearby SSIDs -- This is essentially equivalent to the
> location API, so I think it should be treated as such, with the same exact
> UI as location.
We expose the location API to untrusted apps, since this is something
that web pages can already get access to. Exposing list of SSIDs is
potentially more sensitive, if for example you are in a location which
has deliberately deployed wireless access points for the purpose of
tracking (the example that has been discussed was "wifarer"-like indoor
wifi based location services).
I don't think this information should be available to untrusted apps (as
location is) since the location could be more granular, and also it is
difficult to convey the implication to the user that allowing wifi
access will enable potentially more granular location tracking.
In the trusted case, I think it needs to remain explicit, as geolocation
is, so the user is in control of their location information.
your account automatically when you are connected to the wifi network,
so you only want to be connected when you authorize it. Maybe it could
be argued that if a trusted app behaved in a way that the user didnt
expect their customers would get mad and uninstall the app, but you
certainly dont want the wifi network changing without your knowledge
(for example at the airport where there are a mix of free and paid wifi
hotspots)
wifi manager app. (I'm not sure if or how we are handling this use case
at the moment)
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
be remembered. But writing this email I am not so sure, as this would
effectively grant persistent access to geolocation information, so maybe
the permission should only be persisted per app session.
On 5/9/12 8:44 AM, Adrienne Porter Felt wrote:
> It seems like the WiFi API will contain a few different privileges, and
> perhaps each one should be treated differently. (Note: everything in this
> e-mail is referring to apps in the "Trusted code" category.)
>
> * See current and nearby SSIDs -- This is essentially equivalent to the
> location API, so I think it should be treated as such, with the same exact
> UI as location.
that web pages can already get access to. Exposing list of SSIDs is
potentially more sensitive, if for example you are in a location which
has deliberately deployed wireless access points for the purpose of
tracking (the example that has been discussed was "wifarer"-like indoor
wifi based location services).
I don't think this information should be available to untrusted apps (as
location is) since the location could be more granular, and also it is
difficult to convey the implication to the user that allowing wifi
access will enable potentially more granular location tracking.
In the trusted case, I think it needs to remain explicit, as geolocation
is, so the user is in control of their location information.
>
> * Connect to known networks -- Implicit. I don't see how this could be
> harmful, especially if the phone is already set up to automatically connect
> to known networks.
Consider the use case of the paid wifi access provider - money comes off
> * Connect to known networks -- Implicit. I don't see how this could be
> harmful, especially if the phone is already set up to automatically connect
> to known networks.
your account automatically when you are connected to the wifi network,
so you only want to be connected when you authorize it. Maybe it could
be argued that if a trusted app behaved in a way that the user didnt
expect their customers would get mad and uninstall the app, but you
certainly dont want the wifi network changing without your knowledge
(for example at the airport where there are a mix of free and paid wifi
hotspots)
>
> * Connect to new networks -- Agreed that this should be explicit. Maybe
> this explicit UI could occur at runtime and be a slightly modified version
> of the already-familiar "Would you like to connect to one of these new
> networks?" dialog.
Agreed - maybe this could be handle by an intent sent to the certified
> * Connect to new networks -- Agreed that this should be explicit. Maybe
> this explicit UI could occur at runtime and be a slightly modified version
> of the already-familiar "Would you like to connect to one of these new
> networks?" dialog.
wifi manager app. (I'm not sure if or how we are handling this use case
at the moment)
>
> * Disconnect from networks -- Implicit. I don't see any reason to make
> this explicit. It's simply annoying, not harmful, and the user can undo
> the action. The Settings app could have a little annotation under "Network
> status" that says the name of the app that last disconnected the user from
> a network, so the user can identify and uninstall any potentially abusive
> applications.
Agreed this should be implicit.
> * Disconnect from networks -- Implicit. I don't see any reason to make
> this explicit. It's simply annoying, not harmful, and the user can undo
> the action. The Settings app could have a little annotation under "Network
> status" that says the name of the app that last disconnected the user from
> a network, so the user can identify and uninstall any potentially abusive
> applications.
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
0 new messages