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

Re: HTML extension for system idle detection.

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 17 Sep 2009 23:41:39 -0700
Message-ID: <5dd9e5c50909172341t669901fene2c017ab6b4af3c0@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Arve Bersvendsen <arveb@opera.com>, David Bennett <ddt@google.com>, public-webapps@w3.org
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.
>

All of these seem like preferences that should be in the web apps...like
they are in the desktop apps.

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

Behavior analysis is somewhat concerning, but your example of why this would
be bad seems a bit farfetched.


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


I guess I could be convinced that this would be protected like geolocation
or just be disabled via preferences.  But I still wouldn't classify any of
these as serious concerns.  And it sounds like the UI for whether or not to
give web applications access should be left up to the UAs.

J
Received on Friday, 18 September 2009 06:42:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT