Request for a position on the Idle Detection API
Greetings WebKit engineers, 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. 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. [image: Google Logo] Reilly Grant Software Engineer reillyg@google.com Google Chrome
Can you describe what a permission prompt would look like that allows the user to make an informed decision about whether they should allow or deny the permission? Simon
On Oct 28, 2020, at 4:56 PM, Reilly Grant <reillyg@google.com> wrote:
Greetings WebKit engineers,
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. 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.
Reilly Grant Software Engineer reillyg@google.com <mailto:reillyg@google.com> Google Chrome _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Wed, Oct 28, 2020 at 7:32 PM Simon Fraser <simon.fraser@apple.com> wrote:
Can you describe what a permission prompt would look like that allows the user to make an informed decision about whether they should allow or deny the permission?
There are example screenshots of the permissions UI I've implemented in Chromium in the explainer: https://github.com/wicg/idle-detection#security-and-privacy
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
On Wed, Oct 28, 2020 at 9:20 PM Ryosuke Niwa <rniwa@webkit.org> wrote:
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 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.
On Thu, Oct 29, 2020 at 12:54 PM Reilly Grant <reillyg@google.com> wrote:
On Wed, Oct 28, 2020 at 9:20 PM Ryosuke Niwa <rniwa@webkit.org> wrote:
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 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.
If that were the case, then it seems like we don't need this API in the first place.
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.
Throttling isn't enough to mitigate all security attacks. Some attacks might be more of visual cue like going to full screen, 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.
It is the site's job to present a compelling case for why the user should grant it a permission.
That doesn't make any sense. We can't let the user make a judgement on whether something is a good idea or not based on a text which is supplied by malicious content.
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.
That doesn't seem like a strong enough use case for this API. For starters, there is no guarantee that the user won't immediately come back to the device. Also, who is such a service supposed to know what other device user might be using at any given point? We're definitely not going to let a website know all the devices a given user might be using at any given point. That's a very serious breach of the said user's privacy. It seems to me that such a suppression / distribution mechanism is best left for the underlying operating systems / web browsers to handle. I'm going to stop responding to this thread at this point because none of the use cases presented either here or elsewhere are compelling, and none of the privacy or security mitigations you've presented here and I found elsewhere are adequate. However, not responding to this thread or future thread about this topic does not mean we'd reconsider our position. Unless a significant new development is being made in either one of the issues we've raised, our position will remain to object to the addition of this API unless otherwise stated regardless of whether we continue to say so in public or not. - R. Niwa
participants (3)
-
Reilly Grant
-
Ryosuke Niwa
-
Simon Fraser