Customization Extension for Calling Scenarios

[gabrielsanbrito]

Hi! We have this proposal for developers working in calling applications to provide more customization capabilities to the notifications. Can you please take a look at our explainer with our proposal to achieve this? What do you think of it?

Thanks!

[gabrielsanbrito]

Hi @beverloo, we have published this explainer on extending the Notifications API to allow more customization. What do you think of it? Your feedback is very much appreciated! Could also point other people that would be interested in looking into it? Thanks!

[beverloo]

Hi Gabriel, thank you for writing the explainer!

A couple of thoughts from our end (cc @PEConn and @rayankans):

• We're generally supportive of supporting more advanced and specific capabilities for notifications. On most platforms users already are accustomed to notifications being used for the "ringing" functionality, emphasised further by the increase in use of collaboration apps.
• Calling notifications introduce changes in regards to notification appearance, behaviour and priority. As such, from a feature point of view it seems appropriate for this to get a separate permission. It's not clear though how exactly the permission would work: would getting permission for "high priority notifications" implicitly grant permission for regular ones too? What stops developers from just always asking for the more powerful one, or worse, both? (cc @engedy who might have additional thoughts)
  • Relatedly, this might be a candidate to restrict to installed web apps?

Based on the proposed API:

• Differences w/ regular notifications are significant, so the opt-in should not be implicit: developers requesting a ringtone or changing an action button style shouldn't impose further behavioural or priority changes. One idea would be to add a Notification.type ("default" | "calling") or similar. Others have considered using notifications for e.g. widgets, which could fit into this as well. Another alternative would be to have different methods on the API.
• Sounds are tricky. In general, if we need this, I'm more supportive of using an enumerated list of values, from which the user's system-level configuration could be derived, as URLs aren't feasible on many platforms. Taking a step back, if there were a Notification.type property then we may not need the sound property at all, allowing us to push back that discussion once again.
• Naming nit, perhaps "acknowledge" / "dismiss" might be more canonical than "success" / "critical".

[gabrielsanbrito]

Hi, Peter! We have taken into account your feedback and updated the explainer. Could you please take a look at when it is convenient for you?

Regarding the considerations made in your last comment, this is a brief summary of the changes introduced in the current explainer version:

• We added a Notification.scenario ("default" | "incoming-call") and removed the sound property. Moreover, we also removed the NotificationActionStyle enum and the style property and defined a sort of template for incoming-call notifications:
  • There will always be a default dismiss action button, even when the Notification.actions array is empty, which can be preferentially red.
  • All the buttons in the Notification.actions array should have preferentially green color.
• Permissions-wise, we proposed restricting the full capabilities of incoming-call notifications to installed web apps only. Non-installed apps should still be able create the call notifications, but they would not have a ringtone, color treatment, nor increased priority. The only difference would be the presence of the default dismiss button.

We appreciate your feedback :)

[PEConn]

Hey, thanks for the updates.

@rayankans and I had a look over the new version. It addresses our comments and we think it's in a good shape.

(FYI, the "Use Examples" section still uses the sound property that you've removed from the proposal - I think you just missed updating that.)

[gabrielsanbrito]

@PEConn thanks for having a look. I removed the remaining usages of the sound property. Thanks for pointing that out!

[tungnh28]

Some of my thoughts @gabrielsanbrito :

• I am entirely sure grouping permission is an appropriate way. The proposed notification seems to be high priority and the notification permission is likely low priority permission. Better to decouple them?
• Are we underestimating the new tendency of attack, abused notification such as an image notification fraud call?

Most reviewers in our last discussion are concerned about the new vector of abuse, which might push us back from our effort cleaning abused notifications. The mitigation is likely to be immature, it’s also still unclear at this moment whether the UI is distinguished enough so users will not mis-click in the new tendency of abuse. We might need more time and detailed assessment of the privacy/security/abuse vectors and appropriate mitigations.