info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
WebAPI Security Discussion: Geolocation
37 views
Skip to first unread message
Lucas Adamski
May 1, 2012, 9:57:33 PM5/1/12
to dev-w...@lists.mozilla.org
Please reply-to dev-webapps.
Yes, its a bit odd to be discussion a mature API but we should make explicit its behavior for install applications.
Name of API: Geolocation API
Reference: _https://developer.mozilla.org/En/Using_geolocation_
Brief purpose of API: Obtain current location of user
General Use Cases: Mapping applications, GPS navigation, geotagging
Inherent threats:
* Leakage of user's current location to app
* Leakage of user's current location to 3rd party geolocation service
* Profiling of user behavior
Threat severity: Moderate
== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Same
Authorization model for normal content: Explicit (default to not remember)
Authorization model for installed content:Explicit (default to... ?)
Potential mitigations: UI indicator for active geolocation with a path for user to disable
== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Same
Authorization model: Explicit (default to... ?)
Potential mitigations: Same
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Device theft recovery; same
Authorization model: Implicit
Potential mitigations: Same (tho do we want UI indicator in case of theft?)
Yes, its a bit odd to be discussion a mature API but we should make explicit its behavior for install applications.
Name of API: Geolocation API
Reference: _https://developer.mozilla.org/En/Using_geolocation_
Brief purpose of API: Obtain current location of user
General Use Cases: Mapping applications, GPS navigation, geotagging
Inherent threats:
* Leakage of user's current location to app
* Leakage of user's current location to 3rd party geolocation service
* Profiling of user behavior
Threat severity: Moderate
== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Same
Authorization model for normal content: Explicit (default to not remember)
Authorization model for installed content:Explicit (default to... ?)
Potential mitigations: UI indicator for active geolocation with a path for user to disable
== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Same
Authorization model: Explicit (default to... ?)
Potential mitigations: Same
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Device theft recovery; same
Authorization model: Implicit
Potential mitigations: Same (tho do we want UI indicator in case of theft?)
pther...@mozilla.com
May 31, 2012, 7:02:14 AM5/31/12
to mozilla-d...@lists.mozilla.org
"Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
The only change below reflects a discussion from the work week, which suggested that we should always show the geolocation indicator, even though it may be undesirable for a "find my stolen phone" app. The logic in this proposal was that it isn't worth trading the privacy risk all the time, for the relatively unlikely scenario of a recovered lost device (an determined thief could simply turn the phone off)
Name of API: Geolocation API
Reference: _https://developer.mozilla.org/En/Using_geolocation_
Brief purpose of API: Obtain current location of user
General Use Cases: Mapping applications, GPS navigation, geotagging
Inherent threats:
* Leakage of user's current location to app
* Leakage of user's current location to 3rd party geolocation service
* Profiling of user behavior
Threat severity: Moderate
== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Same
Authorization model for normal content: Explicit (default to not remember)
Authorization model for installed content:Explicit (default to... ?)
Potential mitigations: UI indicator for active geolocation with a path for user to disable
== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Same
Authorization model: Explicit (default to... ?)
Potential mitigations: UI indicator for active geolocation with a path for user to disable
The only change below reflects a discussion from the work week, which suggested that we should always show the geolocation indicator, even though it may be undesirable for a "find my stolen phone" app. The logic in this proposal was that it isn't worth trading the privacy risk all the time, for the relatively unlikely scenario of a recovered lost device (an determined thief could simply turn the phone off)
Name of API: Geolocation API
Reference: _https://developer.mozilla.org/En/Using_geolocation_
Brief purpose of API: Obtain current location of user
General Use Cases: Mapping applications, GPS navigation, geotagging
Inherent threats:
* Leakage of user's current location to app
* Leakage of user's current location to 3rd party geolocation service
* Profiling of user behavior
Threat severity: Moderate
== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Same
Authorization model for normal content: Explicit (default to not remember)
Authorization model for installed content:Explicit (default to... ?)
Potential mitigations: UI indicator for active geolocation with a path for user to disable
== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Same
Authorization model: Explicit (default to... ?)
Potential mitigations: UI indicator for active geolocation with a path for user to disable
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Device theft recovery; same
Authorization model: Implicit
Use cases for certified code: Device theft recovery; same
Authorization model: Implicit
Mike Hanson
Jun 4, 2012, 5:56:36 PM6/4/12
to pther...@mozilla.com, mozilla-d...@lists.mozilla.org
Not suggesting a change to the API - just hilighting a cool application.
News.me and Instapaper now have apps that use geofencing to trigger a background notification, which in turn is used to trigger a background download, of new content. The geofence is set around "whereever the user is now". The user scenario is, "whenever I leave the place I am now, go grab some fresh content for me because I probably want to read it soon." [1]
It's a clever use of the API and one that matches user behavior very well. I don't think we've hammered out how permissions are granted to background workers, but if they are inherited from the foreground application, this could just work.
[1] http://www.niemanlab.org/2012/06/the-commuters-dilemma-solved-news-me-and-now-instapaper-ready-stories-when-you-walk-out-the-door/
On May 31, 2012, at 4:02 AM, pther...@mozilla.com wrote:
> "Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
>
> The only change below reflects a discussion from the work week, which suggested that we should always show the geolocation indicator, even though it may be undesirable for a "find my stolen phone" app. The logic in this proposal was that it isn't worth trading the privacy risk all the time, for the relatively unlikely scenario of a recovered lost device (an determined thief could simply turn the phone off)
>
>
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
News.me and Instapaper now have apps that use geofencing to trigger a background notification, which in turn is used to trigger a background download, of new content. The geofence is set around "whereever the user is now". The user scenario is, "whenever I leave the place I am now, go grab some fresh content for me because I probably want to read it soon." [1]
It's a clever use of the API and one that matches user behavior very well. I don't think we've hammered out how permissions are granted to background workers, but if they are inherited from the foreground application, this could just work.
[1] http://www.niemanlab.org/2012/06/the-commuters-dilemma-solved-news-me-and-now-instapaper-ready-stories-when-you-walk-out-the-door/
On May 31, 2012, at 4:02 AM, pther...@mozilla.com wrote:
> "Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
>
> The only change below reflects a discussion from the work week, which suggested that we should always show the geolocation indicator, even though it may be undesirable for a "find my stolen phone" app. The logic in this proposal was that it isn't worth trading the privacy risk all the time, for the relatively unlikely scenario of a recovered lost device (an determined thief could simply turn the phone off)
>
>
> Name of API: Geolocation API
> Reference: _https://developer.mozilla.org/En/Using_geolocation_
>
> Brief purpose of API: Obtain current location of user
> General Use Cases: Mapping applications, GPS navigation, geotagging
>
> Inherent threats:
> * Leakage of user's current location to app
> * Leakage of user's current location to 3rd party geolocation service
> * Profiling of user behavior
>
> Threat severity: Moderate
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Same
> Authorization model for normal content: Explicit (default to not remember)
> Authorization model for installed content:Explicit (default to... ?)
> Potential mitigations: UI indicator for active geolocation with a path for user to disable
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Same
> Authorization model: Explicit (default to... ?)
> Potential mitigations: UI indicator for active geolocation with a path for user to disable
>
> Reference: _https://developer.mozilla.org/En/Using_geolocation_
>
> Brief purpose of API: Obtain current location of user
> General Use Cases: Mapping applications, GPS navigation, geotagging
>
> Inherent threats:
> * Leakage of user's current location to app
> * Leakage of user's current location to 3rd party geolocation service
> * Profiling of user behavior
>
> Threat severity: Moderate
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Same
> Authorization model for normal content: Explicit (default to not remember)
> Authorization model for installed content:Explicit (default to... ?)
> Potential mitigations: UI indicator for active geolocation with a path for user to disable
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Same
> Authorization model: Explicit (default to... ?)
> Potential mitigations: UI indicator for active geolocation with a path for user to disable
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: Device theft recovery; same
> Authorization model: Implicit
> Use cases for certified code: Device theft recovery; same
> Authorization model: Implicit
> Potential mitigations: UI indicator for active geolocation with a path for user to disable
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
Doug Turner
Jun 5, 2012, 3:52:45 PM6/5/12
to mozilla.d...@googlegroups.com, pther...@mozilla.com, mozilla-d...@lists.mozilla.org
On Monday, June 4, 2012 2:56:36 PM UTC-7, Mike Hanson wrote:
> Not suggesting a change to the API - just hilighting a cool application.
>
> News.me and Instapaper now have apps that use geofencing to trigger a background notification, which in turn is used to trigger a background download, of new content. The geofence is set around "whereever the user is now". The user scenario is, "whenever I leave the place I am now, go grab some fresh content for me because I probably want to read it soon." [1]
>
> It's a clever use of the API and one that matches user behavior very well. I don't think we've hammered out how permissions are granted to background workers, but if they are inherited from the foreground application, this could just work.
Totally off topic yes. But since you mentioned it...
> Not suggesting a change to the API - just hilighting a cool application.
>
> News.me and Instapaper now have apps that use geofencing to trigger a background notification, which in turn is used to trigger a background download, of new content. The geofence is set around "whereever the user is now". The user scenario is, "whenever I leave the place I am now, go grab some fresh content for me because I probably want to read it soon." [1]
>
> It's a clever use of the API and one that matches user behavior very well. I don't think we've hammered out how permissions are granted to background workers, but if they are inherited from the foreground application, this could just work.
Geolocation is pretty expensive in terms of power to be running for an application like that. You'd want to do some thing differently in our implementation to support such an app.
Doug Turner
Jun 5, 2012, 3:52:45 PM6/5/12
to mozilla-d...@lists.mozilla.org, pther...@mozilla.com, mozilla-d...@lists.mozilla.org
On Monday, June 4, 2012 2:56:36 PM UTC-7, Mike Hanson wrote:
> Not suggesting a change to the API - just hilighting a cool application.
>
> News.me and Instapaper now have apps that use geofencing to trigger a background notification, which in turn is used to trigger a background download, of new content. The geofence is set around "whereever the user is now". The user scenario is, "whenever I leave the place I am now, go grab some fresh content for me because I probably want to read it soon." [1]
>
> It's a clever use of the API and one that matches user behavior very well. I don't think we've hammered out how permissions are granted to background workers, but if they are inherited from the foreground application, this could just work.
>
> News.me and Instapaper now have apps that use geofencing to trigger a background notification, which in turn is used to trigger a background download, of new content. The geofence is set around "whereever the user is now". The user scenario is, "whenever I leave the place I am now, go grab some fresh content for me because I probably want to read it soon." [1]
>
> It's a clever use of the API and one that matches user behavior very well. I don't think we've hammered out how permissions are granted to background workers, but if they are inherited from the foreground application, this could just work.
Doug Turner
Jun 5, 2012, 3:55:22 PM6/5/12
to mozilla.d...@googlegroups.com, mozilla-d...@lists.mozilla.org
> The only change below reflects a discussion from the work week, which suggested that we should always show the geolocation indicator, even though it may be undesirable for a "find my stolen phone" app. The logic in this proposal was that it isn't worth trading the privacy risk all the time, for the relatively unlikely scenario of a recovered lost device (an determined thief could simply turn the phone off)
This is a good idea. I would also like to see Firefox desktop do something similar. Chrome puts a tic-tac in the URL bar. We should steal that idea.
Doug Turner
Jun 5, 2012, 3:55:22 PM6/5/12
to mozilla-d...@lists.mozilla.org, mozilla-d...@lists.mozilla.org
> The only change below reflects a discussion from the work week, which suggested that we should always show the geolocation indicator, even though it may be undesirable for a "find my stolen phone" app. The logic in this proposal was that it isn't worth trading the privacy risk all the time, for the relatively unlikely scenario of a recovered lost device (an determined thief could simply turn the phone off)
0 new messages