Re: HTML extension for system idle detection.

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/
>
>