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.

[lknik]

Thank you for this. Though not sure how "notifications are https-only" may address this particular abuse case. Obtaining a certificate is not particularly difficult these days.

Note on the PR, why not change "strongly encouraged" to "required", possibly a MUST in security considerations?

[bratell-at-opera]

https helps to ensure that the one trying to show a notification is the same entity as the one that got permission to show notifications.

[lknik]

Right, and understood. Is it related to the issue of phishing though?

[anitawoodruff]

Thanks for the feedback.

Good point about https - I have now restructured that section to make it clear how https strengthens the 'clear attribution' mitigation.

I have also changed the note to say attribution is 'required' rather than 'strongly encouraged'.

[hadleybeeman]

Thanks, Anita! Looks like you're making significant progress.

One note though: it seems that there are two opportunities for spoofing and phishing in this. One, as you've covered thoroughly, is the source of the notification. It is definitely important that the user can see where the notification is coming from.

Equally worrisome though is the destination of the text the user is entering in the inline reply. We wouldn't want users to send sensitive information to the wrong or misleading destination URL. What are your thoughts on how best to deal with that possibility?

[hadleybeeman]

Also, we weren't sure if you've filled out a Security and Privacy Questionnaire?

[anitawoodruff]

Hi Hadley, I have now filled out the questionnaire at https://github.com/anitawoodruff/inline-notification-replies/blob/master/SecurityAndPrivacyQuestionnaire.md

With respect to the concern about where the text the user enters may end up, it is true that we have no control over what the origin's service worker chooses to do with the text once it is received, since service workers can perform fetch requests. This enables use-cases such as a delivery company passing on order details to a restaurant.

[hadleybeeman]

Thanks, Anita! We discussed this again in our TAG meeting today.
It looks like that "where is this text going?" problem still provides a potential vector for phishing. Could you add some kind of non-normative note to the spec so that UAs will know to watch out for that?
Otherwise I think we're all set here.

[anitawoodruff]

Done, thanks!