Intent to Prototype: Incoming Call Notifications

[Gabriel Brito]

Contact emails

gabrie...@microsoft.com, ste...@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Notifications/notifications_actions_customization.md

Summary

Extend the Notifications API to allow installed PWA's to send incoming call notifications - i.e., notifications with call-styled buttons and a ringtone. This extension will help VoIP web apps to create more engaging experiences by making it easier for users to easily recognize a calling notification and answer it. Besides that, this feature will help bridge the gap between native and web implementations of apps that have them both.

 

Blink component

UI>Notifications

Motivation

Incoming calls are events that require an immediate response. However, VoIP web applications that need to notify the user about an incoming call via the Notifications API, can only issue a regular notification that will show up in the action/notification center without any clear differentiation. Other options include each application implementing its own in-app notification system, which will only issue notifications inside the app window. This extension to the Notifications API standard for incoming call scenarios will allow web applications to send notifications with colored action buttons and a ringtone, which should have increased priority if allowed by the platform.

Risks

 

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

The Notification API is not supported in WebView. Therefore, there are no WebView risks.

Is this feature fully tested by web-platform-tests?

No

 

Requires code in //chrome?

True

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1383570

Estimated milestones

M111

 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5110990717321216

This intent message was generated by Chrome Platform Status.

 

[Rick Byers]

Sounds cool to me from a web API perspective!

You'll of course need approval from relevant code OWNERS to land patches in this space, looks like that's probably mainly +Peter Beverloo? Any concerns Peter?

Thanks,

   Rick 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BY5PR00MB0824B2CEE0F7F1A4D4C65244D5079%40BY5PR00MB0824.namprd00.prod.outlook.com.

[Peter Beverloo]

+Rayan Kanso and @Peter Conn 

We've been working with Gabriel & team on the proposal and are supportive of prototyping this functionality :)

Thanks,

Peter

[Mike West]

The explainer mentions some security/privacy concerns, but I think it underestimates the risk. Notifications are widely abused today, and various teams are involved in cleaning up various bits of the ecosystem. This seems like it could be a step back if we're not careful about the way we build it, so I'd encourage you to work with folks in this space to mitigate abuse. Perhaps this is a good conversation to have at the upcoming Permissions Workshop (https://www.w3.org/Privacy/permissions-ws-2022/schedule)?

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALt3x6nBiCQM5Xk8K4PWhXRf0an7WbGRaZgAm-_eqQ-RdFv4Hw%40mail.gmail.com.

[Rick Byers]

Great, thanks, glad to hear it Peter!

Rick

[Thomas Nguyen]

I've put some comments on the github link and I agree with Mike (and other sec reviewers) that we might need a more detailed assessment of the API. The UI and mitigation are still in immature state and it's still unclear for us whether they are strong enough to prevent us from the vector of abuse.

[Michaela Merz]

I strongly support this API. There's always the potential for misuse, all the user has to do is to uninstall the app. I understand the principle philosophy to protect the user against malicious intends, but this should never lead to overly restrictive functionality. WebApps  .. as they are today .. have a limited scope of usability. Anything that requires timely interaction is not really useful because push is unreliable, the timed notification API (reminders, appointments ..) has been cancelled and without the Incoming Call Notifications, we have no way to signal a webRTC calls. I am looking forward to this API and with it hopefully a way how to make "simple" push more useful and reliable.

M.

[Rick Byers]

This might be a case where we can agree on common APIs and web-platform-exposed behavior but have different browser-specific policies for managing abuse risk. Generally we don't try to standardize or otherwise get agreement on all aspects of browser abuse mitigation policies, recognizing that the right trade offs will differ between browsers and user populations and that it's an area of active constructive browser competition. I assume at least some of Chrome's quieter permission prompt work is Google Chrome-specific since it relies on some amount of crowdsourced data, right Mike?

Gabriel, are you able to share a little about your goals here? Eg. is getting this into Edge while minimizing code divergence in your internal branch your primary goal? How important is it to you that other browsers like Chrome get a similar UI treatment? If Chrome is more concerned than Edge is about potential abuse then we might be able to unblock things by starting with a more conservative UI treatment in Chrome (no ringtone, UI with just basic buttons) to make it a less interesting vector for abuse. Then Chrome could independently evaluate the priority of investing to have confidence in the safety of a more powerful UX for our users.

Thanks,

   Rick

[Michaela Merz]

Thanks for your answer Rick. However - I do have some remarks. An incoming call notification should reliably and across all platforms signal a .. well, incoming call. What good is a notification if it works on some platforms and doesn't work for others. Take webPush for example: It is pretty much useless because while we know server side whether or not we are able to send it, we have absolutely no idea if and when the user gets it. This is bad enough, especially for time critical information like stock infos or weather alerts. An incoming call notification is even more important because it has to be delivered  within the very short time frame a caller is willing to wait.

If we know we can't deliver a call notification we can tell the caller. But if the callee has a browser that supports the call notification, we should be sure that the notification is actually being shown.

I am also a little bit puzzled as to the abuse concern. All serious notifications should only be available on installed webApps. If a webapp abuses the privilege, the user is able to de-install at any time. In all actuality - there is no abuse concern IMHO. That's why I am pleading with you to not only provide a reliable call notification in combination with an updated webPush and that both are able to push through doze (on mobile devices and on installed webapps only).

Thanks. Michaela