> 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
