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 On Tue, Nov 29, 2022 at 7:46 PM Michaela Merz <[email protected]> wrote: > 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. > > On Tuesday, November 29, 2022 at 10:58:21 AM UTC-7 [email protected] > wrote: > >> 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. >> On Thursday, November 17, 2022 at 2:01:52 PM UTC+1 [email protected] >> wrote: >> >>> Great, thanks, glad to hear it Peter! >>> >>> Rick >>> >>> On Thu, Nov 17, 2022 at 4:49 AM Peter Beverloo <[email protected]> >>> wrote: >>> >>>> +Rayan Kanso and @Peter Conn >>>> >>>> We've been working with Gabriel & team on the proposal and are >>>> supportive of prototyping this functionality :) >>>> >>>> Thanks, >>>> Peter >>>> >>>> >>>> On Wed, Nov 16, 2022 at 8:20 PM Rick Byers <[email protected]> wrote: >>>> >>>>> 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 >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:content/browser/notifications/OWNERS?q=file:notifications%20OWNERS&ss=chromium> >>>>> like that's probably mainly +Peter Beverloo? Any concerns Peter? >>>>> >>>>> Thanks, >>>>> Rick >>>>> >>>>> On Tue, Nov 15, 2022 at 8:12 PM 'Gabriel Brito' via blink-dev < >>>>> [email protected]> wrote: >>>>> >>>>>> Contact emails >>>>>> >>>>>> [email protected], [email protected] >>>>>> >>>>>> 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 >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3ENotifications> >>>>>> >>>>>> 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 >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ? >>>>>> >>>>>> 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 >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> 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 >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BY5PR00MB0824B2CEE0F7F1A4D4C65244D5079%40BY5PR00MB0824.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8463jwUv7GmYBH-kGLX2LDi0cSRx3gcXgqVBC6kGCUgA%40mail.gmail.com.
