[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Request for a position on the Idle Detection API
From: Ryosuke Niwa <rniwa () webkit ! org>
Date: 2020-10-29 4:19:57
Message-ID: CABNRm621M47xHyanb4Z6zkYKwgTKm=aCLYP=i8=qq-8MTBg3EA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Oct 28, 2020 at 4:56 PM Reilly Grant <reillyg@google.com> wrote:
> I would like to request an official position from the WebKit team on the
> emerging Idle Detection API <http://wicg.github.io/idle-detection> specification.
> I am aware that this API was included in a list of APIs
> <https://webkit.org/tracking-prevention/> which you have decided not to
> implement due to fingerprinting concerns. I assume that this objection was
> based on the original explainer provided for this API.
>
Our position has not changed. Our concerns are not limited to
fingerprinting. There is an obvious privacy concern that this API lets a
website observe whether a person is near the device or not. This could be
used, for example, to start mining bitcoins when the user is not around or
start deploying security exploits, etc...
> Since that list was posted the API has been extended to include a
> permission that sites must acquire before being granted access to user
> presence signals. I would like to start a conversation to understand the
> fingerprinting risks you foresee from this API.
>
This kind of action-at-a-distance permission prompt is problematic because
it's unclear to the user why such a permission should be granted and for
what purpose.
Additionally, the use cases listed at
https://github.com/WICG/idle-detection/blob/master/README.md are rather
weak.
Chat application: presenting a user's status to other users and delivering
> notifications to the device where the user is active.
Why does delivering a notification to all devices considered bad? That's
what happens to most notifications I receive and modern operating systems
have ways to hide & dismiss old notifications anyway. It's also unclear how
users are supposed to know of this use case when assessing whether to allow
a permission for this API or not.
Showing timely notifications - e.g. deferring displaying feedback until the
> user returns to an active state.
Again, it's unclear why this is desirable. If I'm not at a computer, it's
okay for the notification to still arrive. I'd see it when I come back to
my computer.
Updating an outdated service worker when there's no unsaved state by
> triggering reloading of the tab.
This doesn't seem like something you'd need idle detection API to do. It's
sufficient to realize that you haven't recently received user inputs on
your website. I have plenty of tabs & windows that I don't touch for hours
if not days. Any websites loaded in such browsing contexts should consider
doing that kind of updates / synchronization. If the argument is that the
user may go back to such tabs / windows if they're currently present, then
this user idle detection API won't help either because the user may come
back to it at any moment.
- R. Niwa
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr">On Wed, Oct 28, 2020 at 4:56 PM Reilly Grant <<a \
href="mailto:reillyg@google.com">reillyg@google.com</a>> wrote:<br></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div>I would like to request an official position from the WebKit team on \
the emerging <a href="http://wicg.github.io/idle-detection" target="_blank">Idle \
Detection API</a> specification. I am aware that this API was included in <a \
href="https://webkit.org/tracking-prevention/" target="_blank">a list of APIs</a> \
which you have decided not to implement due to fingerprinting concerns. I assume \
that this objection was based on the original explainer provided for this \
API.</div></div></blockquote><div><br></div><div>Our position has not changed. Our \
concerns are not limited to fingerprinting. There is an obvious privacy concern \
that this API lets a website observe whether a person is near the device or not. This \
could be used, for example, to start mining bitcoins when the user is not around or \
start deploying security exploits, etc...</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div> Since that list was posted the API has been extended to include a \
permission that sites must acquire before being granted access to user presence \
signals. I would like to start a conversation to understand the fingerprinting risks \
you foresee from this API.<br></div></div></blockquote><div><br></div><div>This kind \
of action-at-a-distance permission prompt is problematic because it's unclear to \
the user why such a permission should be granted and for what \
purpose.</div><div><br></div><div>Additionally, the use cases listed at <a \
href="https://github.com/WICG/idle-detection/blob/master/README.md">https://github.com/WICG/idle-detection/blob/master/README.md</a> \
are rather weak.</div><div><br></div><div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Chat \
application: presenting a user's status to other users and delivering \
notifications to the device where the user is \
active.</blockquote><div><br></div><div>Why does delivering a notification to all \
devices considered bad? That's what happens to most notifications I receive and \
modern operating systems have ways to hide & dismiss old notifications anyway. \
It's also unclear how users are supposed to know of this use case when assessing \
whether to allow a permission for this API or not.</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Showing \
timely notifications - e.g. deferring displaying feedback until the user returns to \
an active state.</blockquote><div> </div><div>Again, it's unclear why this is \
desirable. If I'm not at a computer, it's okay for the notification to still \
arrive. I'd see it when I come back to my \
computer.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Updating \
an outdated service worker when there's no unsaved state by triggering reloading \
of the tab.</blockquote></div><div><br></div><div>This doesn't seem like \
something you'd need idle detection API to do. It's sufficient to realize \
that you haven't recently received user inputs on your website. I have plenty of \
tabs & windows that I don't touch for hours if not days. Any websites loaded \
in such browsing contexts should consider doing that kind of updates / \
synchronization. If the argument is that the user may go back to such tabs / windows \
if they're currently present, then this user idle detection API won't help \
either because the user may come back to it at any moment.</div><div><br></div><div>- \
R. Niwa</div><div><br></div></div></div></div></div></div></div></div>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic