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 dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
