"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-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
