Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
WebAPI Security Discussion: Idle API
22 views
Skip to first unread message
Lucas Adamski
Apr 16, 2012, 2:12:35 AM4/16/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-b2g mailing list, dev-se...@lists.mozilla.org
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:
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:
Ian Melven
Apr 16, 2012, 8:15:19 PM4/16/12
to dev-w...@lists.mozilla.org
Hi,
on the feature page it mentions "We might also want to display UI which allows the user to choose
if he/she wants to expose idle/active status to page. This is something we still need to figure out."
this is a feature i personally always disable in IM clients ie i always turn off 'allow users
to see how long i've been idle' for various reasons.
i suppose this is something app authors for something like an IM app can implement using the API as described,
but i wouldn't want random unauthenticated pages to be able to detect when i'm idle, even with a
'fuzz factor'. this doesn't feel big enough to warrant an actual permission to me personally,
so i guess this could be considered a vote for not exposing this API to regular content or having
some way for to opt out of it (maybe a global preference ?) - the latter (opt out) is probably better
since I assume that as usual i'm in a small minority of users that would use it.
thanks,
ian
dev-b2g mailing list
dev...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
Lucas Adamski
Apr 26, 2012, 10:53:52 AM4/26/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list
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.
Lucas.
Bonnie Surender
Apr 26, 2012, 1:43:13 PM4/26/12
to Lucas Adamski, dev-w...@lists.mozilla.org
Hi,
The idle API security comments below look fine.
Thanks.
Bonnie Surender
Software Engineer,
Web API,
Mozilla Corporation.
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
The idle API security comments below look fine.
Thanks.
Bonnie Surender
Software Engineer,
Web API,
Mozilla Corporation.
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
Jonas Sicking
May 1, 2012, 3:51:52 AM5/1/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list
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
> Inherent threats: Privacy implication - signalling mulitple windows at exactly the same time could correlate user identities and compromise privacy
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
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
> Potential mitigations: Exact time user goes idle can be fuzzy so as to reduce correlation
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:
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
pther...@mozilla.com
May 31, 2012, 6:29:50 AM5/31/12
to mozilla.d...@googlegroups.com, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list
"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
Potential mitigations: Implicit
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: As per unauthenticated
Authorization model: Implicit
Potential mitigations: Implicit
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:
**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
Use cases for authenticated code: As per unauthenticated
Potential mitigations: Implicit
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: As per unauthenticated
Potential mitigations: Implicit
pther...@mozilla.com
May 31, 2012, 6:29:50 AM5/31/12
to mozilla-d...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list
"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
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
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
Use cases for authenticated code: As per unauthenticated
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:
Potential mitigations: Implicit
On Tuesday, 1 May 2012 17:51:52 UTC+10, Jonas Sicking wrote:
Justin Lebar
May 31, 2012, 9:31:13 AM5/31/12
to pther...@mozilla.com, dev-w...@lists.mozilla.org
> 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?
> the appropriate controls for different app types.
On Thu, May 31, 2012 at 6:29 AM, pther...@mozilla.com
<pther...@mozilla.com> 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
> 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
> Use cases for authenticated code: As per unauthenticated
> Potential mitigations: Implicit
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: As per unauthenticated
> == 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:
> Potential mitigations: Implicit
>
>
>
> On Tuesday, 1 May 2012 17:51:52 UTC+10, Jonas Sicking wrote:
Paul Theriault
May 31, 2012, 6:36:31 PM5/31/12
to Justin Lebar, dev-w...@lists.mozilla.org
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
* 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
>> Potential mitigations: Implicit
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
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
Potential mitigations: Implicit
== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: As per unauthenticated
Authorization model: Implicit
Potential mitigations: 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, pther...@mozilla.com
> <pther...@mozilla.com> 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
>>
>> 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, pther...@mozilla.com
> <pther...@mozilla.com> 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
>> 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
>> Use cases for authenticated code: As per unauthenticated
>> Potential mitigations: Implicit
>>
>> == Certified (vouched for by trusted 3rd party) ==
>> Use cases for certified code: As per unauthenticated
>> == 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:
>> Potential mitigations: Implicit
>>
>>
>>
>> On Tuesday, 1 May 2012 17:51:52 UTC+10, Jonas Sicking wrote:
0 new messages