Re: HTML extension for system idle detection.

Morning,
This sounds reasonable.  Returning unauthorized and 0 when the value is
unauthorized sounds good to me.

Should the methods perhaps be called getSystemIdleState() and
getSystemIdleTimeInSeconds()?

Thanks,
David.

On Thu, Sep 17, 2009 at 11:48 PM, Michael Nordman <michaeln@google.com>wrote:

> This particular proposal is clearly a good feature and Bjoern's is a good
> articulation of privacy concerns.
>
> Something lacking in the web platform in general (to my knowledge, albeit
> limited) is a permissioning scheme whereby sites or applications can
> establish rights. Is there any work being done on that dimension that has
> any traction? Provided mechanisms for sites/applications to request
> (declaratively or programatically), and for users to acquiesce (and to later
> reject), a great many APIs could be introduced to the web platform. The
> specter of 'privacy' or 'security' concerns could be more easily addressed
> with such mechanisms.
>
> The proposed idle state monitoring interfaces could be opaquely presented
> to an unauthorized site as...
>  systemIdleState() == UNAUTHORIZED
>  systemIdleTimeInSeconds() == 0
> ... and no events ever fire
>
> nit: systemIdleState() and systemIdleTimeInSeconds() feel more like a
> read-only attributes than functions
>
> On Thu, Sep 17, 2009 at 6:34 PM, Bjoern Hoehrmann <derhoermi@gmx.net>wrote:
>
>> * Jeremy Orlow wrote:
>> >As far as I know, there really aren't any.  This was discussed on WhatWG
>> >(before being directed here) and IIRC there were no serious security or
>> >privacy concerns.  The minimum resolution of the event makes attacks
>> based
>> >on keystroke timing impossible.  Some people suggested that web apps
>> could
>> >do something "bad" while the user is away, but I don't think anyone could
>> >come up with a good example of something "bad".  Can you think of any
>> >specific concerns?
>>
>> If you consider a client-server instant messaging service, it is easy to
>> give three examples for why you would not want the server and peers be
>> informed whether you're currently interacting with the device the client
>> is running on out of "privacy" considerations.
>>
>> If the peer's client indicates that you are using the system, then it is
>> common for peers to assume you are actually present and not merely cause
>> some activity every now and then (e.g., change the volume setting while
>> watching a movie, check on some activity while cleaning the house) and
>> to become upset if you do not respond. Similarily, you may be available
>> but do not cause system activity (e.g., watch a movie, but the client is
>> configured to interrupt the playback on receiving a message) and peers
>> are likely to incorrectly assume you are absent and not contact you.
>>
>> You may also be present for all intents and purposes, but do not wish to
>> give some of your peers the impression you are (e.g., you may not wish
>> to attend to them that instant). Similar are finer grained notifications
>> of user activity like typing notifications. If the client transmits them
>> you may start typing in some message, reconsider, and then might have to
>> answer the peer's question what you wanted to say but did not.
>>
>> Prolonged storage of this information also allows for analysis of beha-
>> vioral patterns; for example, if the user is rarely inactive for certain
>> periods of time, that is likely to be seen as an indication of a medical
>> condition such as a sleep disorder.
>>
>> I believe there are plenty of users of instant messaging systems who
>> have turned off, or would turn off if they were aware of the option and
>> possible consequences, these kind of notifications for these and other
>> reasons, or adjust their behavior to avoid the possible consequences.
>> --
>> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
>> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
>> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>>
>>
>