Closed subversivo58 closed 3 years ago
tomayac
commented
4 years ago Potentially related: https://github.com/WICG/idle-detection/issues/21.
@subversivo58 Background: The old chrome.idle API had a specific "idle" permission. The Web Extension system that opens this API to browser extensions on Firefox (apart from Chromium-derived browsers) also has an idle permission.
reillyeon
commented
4 years ago The choice of the notification permission was motivated by primary use case for this API being preventing duplicate notifications across a user's devices. This requires a site to be able to observe these signals about user presence. The primary risk of this API as I see it is that it exposes a global signal which could be used as a cross-origin identifier. Limiting the availability of this signal to active top-level frames with notification permission severely limits the number of sites which could perform this attack.
You say that you have granted a large set of websites notification permission but are these websites frequently all loaded in their own tabs at the same time? This is the scenario required for the attack I am concerned about mitigating.
Do you invision another type of attack which a site could perform using this capability?
Sora2455
commented
4 years ago The choice of the notification permission was motivated by primary use case for this API being preventing duplicate notifications across a user's device. ...isn't that what the tag option of a notification is for? So that if you have a second notification of the same type as the first, they aren't both shown together?
In my case, my use case is knowing when the user has gone idle so I can show a "Auto-logout in 15 mins" modal without needing to attach global event handlers for 12 different events and muck around with timers.
Limiting the availability of this signal to active top-level frames with notification permission severely limits the number of sites which could perform this attack.
Hasn't limiting the coarseness of the API to one minute also killed that attack?
reillyeon
commented
4 years ago The choice of the notification permission was motivated by primary use case for this API being preventing duplicate notifications across a user's device.
...isn't that what the tag option of a notification is for? So that if you have a second notification of the same type as the first, they aren't both shown together?
That was a typo on my part. I've updated my post above to change "device" to "devices". This is about knowing whether to, for example, send a notification to a user's desktop or mobile device.
Limiting the availability of this signal to active top-level frames with notification permission severely limits the number of sites which could perform this attack.
Hasn't limiting the coarseness of the API to one minute also killed that attack?
The threshold limitations prevent detecting fine-grained actions, such as the time between key presses. The event is still fired nearly instantaneously when the idle state changes. To do otherwise would swiftly reduce the usefulness when attempting to deliver notifications accurately. We studied the option of delaying the event and were also unconvinced that it was an effective mitigation.
subversivo58
commented
4 years ago Hi @tomayac, when a user installs an extension, they theoretically know what it’s for and what it’s going to do.
I am not against the API, I see many use cases that it would be really appreciated
@reillyeon, I do not have the capacity or technical knowledge to give an opinion on atack vectors or inherent risks, but I am concerned with the warning to the user (and I do not find this in the public explainer) in the following scenario.
If this API were implemented today in browsers:
In addition to these I also see scenarios where it would not be appreciated like this.
I do not see a scenario in the explainer where the user has that information or choice. Apparently revoking Notifications would be the user's only choice
I don't know how things work under the hood, but I can't imagine the browser reporting two different purposes for the same flag and if it shows what the "regressive impact" would be for those who never agreed to this but had already agreed to Notifications?
I hope I'm not being confused, thank you
noamr
commented
4 years ago Many people have lots of tabs open - some of them with notification permissions that they've forgotten about granting. Because people click "Yes" on things and notifications are maybe annoying but harmless. A user may have dozens of tabs open for days. If two of them have a notification permission they can use idle-detection together with other metrics for interesting fingerprinting. Or am I just being paranoid?
reillyeon
commented
4 years ago In the pull request above I've explored some of the alternatives considered, including a separate "idle-detection" permission. Comments are welcome.
reillyeon
commented
3 years ago The new draft specification defines a new "idle-detection" permission which I believe resolves the questions raised by this issue.
Hi
I have a large list of notification permissions granted to websites and PWA's that I normally receive reports from.
I wonder how this API will work for these established cases. It was not for this purpose (whether or not I am interacting on my computer) that I granted permissions.
How will users be informed by the UI of the permissions api about the possibility of this "monitoring" (if any intention for display this info)?
The current Notification API request model is "intuitive" to the user. The user grants permission in the expectation of receiving notifications only.
From the user's point of view how would he be informed that the application could know or determine whether or not he is interacting on his device even away from the application/website?
I understand the legitimate use cases, but shouldn't the user know and be able to choose to grant this information (the state)?
I don't have much to say about the plugins mentioned in the inspiration examples, but when a user installs a plugin he is informed about what that plugin does and it can be said that he is already aware of it.
I am more concerned with the call that this proposal uses, an already established banner (Notifications) that users are already used to doing something different from this purpose.