[webkit-dev] Request for a position on the Idle Detection API

[Reilly Grant]

On Wed, Oct 28, 2020 at 9:20 PM Ryosuke Niwa <rniwa at webkit.org> wrote:
>
> On Wed, Oct 28, 2020 at 4:56 PM Reilly Grant <reillyg at google.com> wrote:
>>
>> I would like to request an official position from the WebKit team on the emerging Idle Detection API specification. I am aware that this API was included in a list of APIs 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...

Thank you for expanding on your concerns. I agree that malicious sites
may attempt to hide their activity from the user by waiting until they
appear to not be paying attention. There are plenty of mechanisms
currently available for this, for example, a site can already tell
that it has been placed in the background and can observe that the
user has not interacted with it in a long time, which likely means
that the user is no longer at their computer. It is true that this
capability would allow a site to be more precise about targeting a
time when the user is not present. I think the mitigation in that
case, especially for activity such as cryptocurrency mining, is the
work that is being done elsewhere to define the semantics for
throttling the work that sites are allowed to do in the background.

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

It is the site's job to present a compelling case for why the user
should grant it a permission.

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

Developers we have talked to (see the WICG discourse thread for
supportive comments from Slack and Google Chat) have identified that
receiving notifications on all their devices simultaneously is in fact
a frequent user complaint. In the introduction section of the
specification I explain the user scenario in more detail. Being able
to hide or dismiss old notifications is helpful but does not address
the core issue, which is that user's want to receive notifications on
only the device they are currently using. The current tools for this
are lacking because they cannot distinguish between the user leaving
their computer and simply switching to another application.