Re: WebAPI Security Discussion: Idle API

Showing 1-2 of 2 messages
Re: WebAPI Security Discussion: Idle API Lucas Adamski 4/26/12 7:53 AM
I haven't seen any comments on this for a while so I'll be closing this out and posting on Friday.  Please send any last comments before noon PDT.  Thanks!
  Lucas.

On Apr 15, 2012, at 11:12 PM, Lucas Adamski wrote:

> Please reply-to dev-w...@lists.mozilla.org
>
> Name of API: Idle API
> Reference:  https://wiki.mozilla.org/WebAPI/IdleAPI
>
> Brief purpose of API: Notify an app if the user is idle
> General Use Cases: Notify a web page is a user is idle (e.g. to change a status in an instant messaging program)
>
> Inherent threats:  Privacy implication - signalling mulitple windows at exactly the same time could correlate user identities and compromise privacy
>
> Threat severity: Low
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Event is fired when the user is idle
> Authorization model for normal content: Implicit
> Authorization model for installed content:Implicit
> Potential mitigations: Exact time user goes idle can be fuzzy so as to reduce correlation
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: As per unauthenticated
> Authorization model:
> Potential mitigations:
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: As per unauthenticated
> Authorization model:
> Potential mitigations:
>

Re: [b2g] WebAPI Security Discussion: Idle API Jonas Sicking 5/1/12 12:51 AM
Sorry for not responding until now. Was away on vacation.

> Inherent threats:  Privacy implication - signalling mulitple windows at exactly the same time could correlate user identities and compromise privacy

I think there's another threat, which is simply monitoring if the user
is active on the computer, which is a bit of a privacy invasion. For
example, a user might not expect that a corporate website that the
user is logged in to monitors how active the user is at the computer
to see if he/she puts in a full day of work.

There's also another threat which is easier to solve. The API allows
specifying how long the user has to be idle before the page is
notified. If we allow *very* short idle times, say 0.1 seconds, then
the page can basically sense each time the user presses a key. This is
easily fixed by enforcing a minimal idle time of X seconds. Given that
the main use cases is to do things like notify IM apps when the user
is away from the computer, X can be cranked up fairly high (30 seconds
perhaps) without loosing any important use cases.

> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Event is fired when the user is idle
> Authorization model for normal content: Implicit

I think that for normal content we might not want to allow this API at
all without a prompt. The value to privacy risk ratio is pretty low
given that most apps can do just fine without access to the API.

Alternatively, we could make the Idle API simply monitor activity *on
that page* for uninstalled pages, unless there has been a prompt. That
way we're not exposing *any* new information which couldn't be gotten
through simply monitoring all UI events.

> Authorization model for installed content:Implicit

This one I'm less sure about where it falls. Maybe same as normal content?

> Potential mitigations: Exact time user goes idle can be fuzzy so as to reduce correlation

Yes, definitely think we should do this. But it only addresses the
correlation issue. Not the privacy leak.

> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: As per unauthenticated
> Authorization model:
> Potential mitigations:
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: As per unauthenticated
> Authorization model:
> Potential mitigations:

I'm similarly unsure what to do here. I could see prompting here too
mostly because most apps would do just fine without ability to know
when the user is interacting with the device. At the same time, these
types of apps could potentially figure out when the screen is being
turned off anyway which is essentially the same thing as the user
being idle (we don't have such an API right now, but I suspect we'll
end up with one).

/ Jonas