Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
WebAPI Security Discussion: Sensor API
16 views
Skip to first unread message
Lucas Adamski
May 8, 2012, 2:41:46 PM5/8/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g
Please reply-to dev-w...@lists.mozilla.org
Name of API: Sensor API
Reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=697361
http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/
Brief purpose of API: Let apps access environmental sensor data gathered by devices.
General Use Cases: None
Inherent threats:Privacy
Threat severity: Moderate
== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Monitor environmental sensor data like temperature, barometer, magnetic field,
Authorization model for normal content: Explicit
Authorization model for installed content: Implicit
Potential mitigations: Only available to top-level content while focused
== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Same
Use cases for trusted code: Implicit
Potential mitigations:
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code:
Backlight Dimming based on ambient light
Screen-off based on proximity
Authorization model: Implicit
Potential mitigations:
Note: Many device sensor and motion use cases already covered by DeviceOrientation / DeviceMotion API (http://dev.w3.org/geo/api/spec-source-orientation.html)
Name of API: Sensor API
Reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=697361
http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/
Brief purpose of API: Let apps access environmental sensor data gathered by devices.
General Use Cases: None
Inherent threats:Privacy
Threat severity: Moderate
== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Monitor environmental sensor data like temperature, barometer, magnetic field,
Authorization model for normal content: Explicit
Authorization model for installed content: Implicit
Potential mitigations: Only available to top-level content while focused
== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Same
Use cases for trusted code: Implicit
Potential mitigations:
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code:
Backlight Dimming based on ambient light
Screen-off based on proximity
Authorization model: Implicit
Potential mitigations:
Note: Many device sensor and motion use cases already covered by DeviceOrientation / DeviceMotion API (http://dev.w3.org/geo/api/spec-source-orientation.html)
pther...@mozilla.com
May 31, 2012, 7:06:41 AM5/31/12
to mozilla-d...@lists.mozilla.org
Jonas Sicking
Jun 4, 2012, 5:22:43 AM6/4/12
to pther...@mozilla.com, Doug Turner, mozilla-d...@lists.mozilla.org
Why do we require explicit permission from uninstalled content?
Currently the orientation and acceleration sensors is available to all
uninstalled web pages in several browsers.
We even currently make these sensors available when content isn't
focused, though that's something I think we should fix.
/ Jonas
On Thu, May 31, 2012 at 4:06 AM, pther...@mozilla.com
<pther...@mozilla.com> wrote:
> "Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
>
> On Wednesday, 9 May 2012 04:41:46 UTC+10, Lucas Adamski wrote:
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
Currently the orientation and acceleration sensors is available to all
uninstalled web pages in several browsers.
We even currently make these sensors available when content isn't
focused, though that's something I think we should fix.
/ Jonas
On Thu, May 31, 2012 at 4:06 AM, pther...@mozilla.com
<pther...@mozilla.com> wrote:
> "Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
>
> On Wednesday, 9 May 2012 04:41:46 UTC+10, Lucas Adamski wrote:
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
Paul Theriault
Jun 4, 2012, 8:16:40 AM6/4/12
to Jonas Sicking, Doug Turner, mozilla-d...@lists.mozilla.org
My main concern was side-channel attacks - there have been several
papers released on sniffing passwords based on accelerometer
information. Limiting access to the foreground only would be a elegant
security solution to that specific threat. However on reflection, I
think the permission depends on the type of sensor (or combination of
sensors) being made available. Or is the point of this API that all
sensors must be designed to be safe for untrusted web content?
On 6/4/12 7:22 PM, Jonas Sicking wrote:
> Why do we require explicit permission from uninstalled content?
> Currently the orientation and acceleration sensors is available to all
> uninstalled web pages in several browsers.
>
> We even currently make these sensors available when content isn't
> focused, though that's something I think we should fix.
>
> / Jonas
>
> On Thu, May 31, 2012 at 4:06 AM, pther...@mozilla.com
> <pther...@mozilla.com> wrote:
>> "Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
>>
>> On Wednesday, 9 May 2012 04:41:46 UTC+10, Lucas Adamski wrote:
papers released on sniffing passwords based on accelerometer
information. Limiting access to the foreground only would be a elegant
security solution to that specific threat. However on reflection, I
think the permission depends on the type of sensor (or combination of
sensors) being made available. Or is the point of this API that all
sensors must be designed to be safe for untrusted web content?
On 6/4/12 7:22 PM, Jonas Sicking wrote:
> Why do we require explicit permission from uninstalled content?
> Currently the orientation and acceleration sensors is available to all
> uninstalled web pages in several browsers.
>
> We even currently make these sensors available when content isn't
> focused, though that's something I think we should fix.
>
> / Jonas
>
> On Thu, May 31, 2012 at 4:06 AM, pther...@mozilla.com
> <pther...@mozilla.com> wrote:
>> "Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
>>
>> On Wednesday, 9 May 2012 04:41:46 UTC+10, Lucas Adamski wrote:
Jonas Sicking
Jun 4, 2012, 8:09:50 PM6/4/12
to Paul Theriault, Doug Turner, mozilla-d...@lists.mozilla.org
On Mon, Jun 4, 2012 at 5:16 AM, Paul Theriault <pther...@mozilla.com> wrote:
> My main concern was side-channel attacks - there have been several papers
> released on sniffing passwords based on accelerometer information. Limiting
> access to the foreground only would be a elegant security solution to that
> specific threat. However on reflection, I think the permission depends on
> the type of sensor (or combination of sensors) being made available. Or is
> the point of this API that all sensors must be designed to be safe for
> untrusted web content?
I agree that we should do a per-sensor judgement. For
> My main concern was side-channel attacks - there have been several papers
> released on sniffing passwords based on accelerometer information. Limiting
> access to the foreground only would be a elegant security solution to that
> specific threat. However on reflection, I think the permission depends on
> the type of sensor (or combination of sensors) being made available. Or is
> the point of this API that all sensors must be designed to be safe for
> untrusted web content?
get-information-from-outside-world sensors that we currently have
implemented:
* acceleration/gravity
* magnetic field/orientation
* rotation
* ambient light
* proximity
I think turning the sensor off for background pages and apps would be
the safer thing to do. I can't think of any great use cases that it
would disable off the top of my head, but I could be wrong.
/ Jonas
Jonas Sicking
Jun 5, 2012, 2:33:30 AM6/5/12
to Doug Turner, Paul Theriault, mozilla-d...@lists.mozilla.org
On Mon, Jun 4, 2012 at 6:34 PM, Doug Turner <do...@mozilla.com> wrote:
> Any good nav app would want acceleration events while in the background. These events are very important for turn by turn.
Maybe we could expose throttled events for orientation/rotation
sensors for apps which currently have access to GPS?
That way such apps can't do things like detect keystrokes by using
accelerometer, but they can still augment the information they get
from GPS to track the user's location better.
/ Jonas
> Any good nav app would want acceleration events while in the background. These events are very important for turn by turn.
Maybe we could expose throttled events for orientation/rotation
sensors for apps which currently have access to GPS?
That way such apps can't do things like detect keystrokes by using
accelerometer, but they can still augment the information they get
from GPS to track the user's location better.
/ Jonas
David Clarke
Jul 17, 2012, 7:46:37 PM7/17/12
to Doug Turner, Paul Theriault, mozilla-d...@lists.mozilla.org, Jonas Sicking
Another example:
dialer app, and when you put the phone up to your face. The proximity sensor should detect whether you are in the app or not.
----- Original Message -----
From: "Doug Turner" <do...@mozilla.com>
To: "Jonas Sicking" <jo...@sicking.cc>
Cc: "Paul Theriault" <pther...@mozilla.com>, mozilla-d...@lists.mozilla.org
Sent: Monday, June 4, 2012 6:34:25 PM
Subject: Re: WebAPI Security Discussion: Sensor API
Any good nav app would want acceleration events while in the background. These events are very important for turn by turn.
dialer app, and when you put the phone up to your face. The proximity sensor should detect whether you are in the app or not.
----- Original Message -----
From: "Doug Turner" <do...@mozilla.com>
To: "Jonas Sicking" <jo...@sicking.cc>
Cc: "Paul Theriault" <pther...@mozilla.com>, mozilla-d...@lists.mozilla.org
Sent: Monday, June 4, 2012 6:34:25 PM
Subject: Re: WebAPI Security Discussion: Sensor API
Any good nav app would want acceleration events while in the background. These events are very important for turn by turn.
0 new messages