W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: HTML extension for system idle detection.

From: David Bennett <ddt@google.com>
Date: Sat, 19 Sep 2009 12:42:11 -0700
Message-ID: <bfeaf0180909191242j60deb2eu94cc48d740506cbf@mail.gmail.com>
To: Michael Nordman <michaeln@google.com>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Jeremy Orlow <jorlow@chromium.org>, Arve Bersvendsen <arveb@opera.com>, public-webapps@w3.org
This sounds reasonable.  Returning unauthorized and 0 when the value is
unauthorized sounds good to me.

Should the methods perhaps be called getSystemIdleState() and


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/
Received on Saturday, 19 September 2009 19:42:52 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC