Sorry I meant the controls suggested in the thread and the bug -
specifically:
* Exact time user goes idle can be fuzzed so as to reduce correlation
* Provide only page idle not system idle, where privacy is a concern
Added these to the mitigations section below now.
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 multiple windows at exactly the same time could correlate user
identities and compromise privacy
** Could be used by a workplace to monitor activity by monitoring system idle
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 fuzzed so as to reduce correlation
* Provide only page idle not system idle, where privacy is a concern
== Trusted (authenticated by publisher) ==
Use cases for authenticated code: As per unauthenticated
Authorization model: Implicit
Potential mitigations: Implicit
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: As per unauthenticated
Authorization model: Implicit
Potential mitigations: Implicit
On 5/31/12 11:31 PM, Justin Lebar wrote:
As such I think that the permission model remains implicit for all apps, with
the appropriate controls for different app types.
What does "appropriate controls for different app types" mean?
On Thu, May 31, 2012 at 6:29 AM, [email protected]
<[email protected]> wrote:
"Final" proposal - please reply by the end of Friday with any concerns/changes.
When trying to combine the comments above, with the comments in the bug (715041) it
occurred to me that the privacy risk is more significant on the desktop than on the
phone, and therefore it will be the implementation of the API rather than the permissions
model which mitigates this risks. Likewise, the "de-anonymisation" threat is
solved by implementation (fuzzing the exact idle time)
As such I think that the permission model remains implicit for all apps, with
the appropriate controls for different app types.
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 multiple windows at exactly the same time could correlate user
identities and compromise privacy
** Could be used by a workplace to monitor activity by monitoring system idle
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: Implicit
Potential mitigations: Implicit
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: As per unauthenticated
Authorization model: Implicit
Potential mitigations: Implicit
On Tuesday, 1 May 2012 17:51:52 UTC+10, Jonas Sicking wrote:
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
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
