Notification Inline Replies

[anitawoodruff]

Hello TAG!

I'm requesting a TAG review of:

• Name: Notification Inline Replies
• Specification URL: Add support for inline replies whatwg/notifications#132
• Explainer: https://github.com/anitawoodruff/inline-notification-replies
• Tests: Add tests for notification inline reply idl properties web-platform-tests/wpt#11122
• Primary contacts: @anitawoodruff, @beverloo

Further details:

• Relevant time constraints or deadlines: We'll be sending out an Intent to Ship for Chrome shortly so a quick response would be appreciated. (Apologies for filing this relatively late.)

We'd prefer the TAG provide feedback as:

• [ x ] leave review feedback as a comment in this issue and @-notify anitawoodruff, beverloo

[torgo]

How can this be used for evil and how can the API design mitigate these risks? I firmly believe that notifications are an extremely useful web feature and this proposed extension looks to make them even more useful. However, notifications have also been getting a very bad reputation recently due to their overuse and abuse. For example, requesting permission to send push notifications on first page load is arguably an antipattern.

Allowing notifications to put interactive UI into users' notification "drawers" has the potential to exacerbate this problem as people misuse this feature to grab attention or to deliberately mislead people in phishing type attacks.

What in the API design or other normative requirements can help to mitigate against these potential issues?

[lknik]

Hi,

Thanks for reaching out so quickly. Let me provide an initial security and privacy assessment.

I see a number of possible misuses on the horizon.

Security.
This addition changes the Notification model to enable bi-directorial communication. It is not a problem in itself, but the possible risks may include the tricking of users into doing some unwanted things. So the "best" idea for a misuse may be in phishing. In other words:

• will the users know what is the nature of the notification?
• how will the users see the difference between replying to an app notification and possibly to a remote server?
• how happy will be web browsers/OSs with users being able to interact with a website-controlled UI like that, that is nonetheless being displayed as a standard message?

Privacy
Tracking is the simplest concern, as users will have it more "simple" to interact, and so at least data such as IP changes (when roaming) may pop in

Also, what with existing permissions to display notification: are they retained when this feature arrives?

So we've got an interesting case in terms of security, privacy, and UI.

Ps. An upside of this additional UI change is that it may enable a truly affirmative consent for private data processing! That's the situation when the user would need to type some confirmations literary (notification with text "do you agree to ...", answer: user-typed). I'm actually wondering whether browser permissions should not consider going into this particular direction... ;)

[hadleybeeman]

It would be great to see these issues flagged up in the spec/explainer — saying "if you do this badly, this is what can happen." We don't want a spec to determine the UI, since that's the domain of the user agents — but it would be good for the spec authors (who've thought about this feature more than anyone else) to flag up potentials that UAs should be aware of.

I'm also aware that we have been talking about permission delegation (TAG issue) in light of an upcoming workshop.

I'm struggling to think of a use case when you'd want permission for notifications (let alone inline replies to notifications) to be inherited from a parent document.... Is anyone working on this?

[torgo]

Hi @anitawoodruff, @beverloo - thanks for this initial request - what you've got above is the output from some initial discussions we had, including on today's call. Any initial feedback on these topics?

[torgo]

BTW I see you're both listed as in London. @hadleybeeman and are are both here in London as well. If it would benefit us to meet up f2f some time to discuss this further that's certainly a possibility.

[anitawoodruff]

Hi TAG. Thanks for your feedback.

In response to the points on phishing and attribution, I have added a Potential For Abuse section to the explainer addressing the phishing concern and a note to the spec PR regarding attribution.

In response to your other concerns:

• Misuse to grab attention

  • Often native platforms implement inline reply UI as regular buttons that only expand into input boxes on click (eg Android, Chrome OS), so these are no worse than regular notifications
  • This capability is expected to primarily be used by messaging applications, which tend to get the highest click-through-rates on their notifications already, so this is unlikely to exacerbate the worst cases of notification annoyance.

• Tracking (since the ability to reply more easily may make it likelier for users to interact with them on the go)

  • Service workers may already perform fetch requests on receipt of a push message prior to showing a notification, so this is unlikely to lead to greater tracking.

• Interaction with current permission model

  • We propose this doesn't require a new permission; it should be covered by the existing notification permission to keep things simple. Permission delegation seems orthogonal to this change.

Unfortunately I will be OOO for the next 2 weeks but I expect @beverloo would be happy to meet up F2F for further discussion.