Subject: [Webpush] Some comments on webpush server responses

From: Ben Last <[email-masked]>
Date: Mon, 15 Aug 2016 09:50:11 -0700

Hi all

Apologies if I violate IETF etiquette here; I have some comments on
https://tools.ietf.org/html/draft-ietf-webpush-protocol-08#section-7.3

In our push service, we're often coming across the problem of
distinguishing *why* we get a 404 (or 410 for Mozilla's autopush) reponse
when sending to an existing push subscription. We know of the following
reasons why a push server might respond with a 404/410 (there may of course
be others):

   1. The push subscription endpoint to which a POST was made is invalid -
   it does not refer to a known subscription
   2. The push subscription endpoint to which a POST was made is *no
longer* valid
   - it refers to a subscription that has been removed because the end-user
   removed notification permission
   3. The push subscription endpoint to which a POST was made is *no
longer* valid,
   but the subscription should be recreated (i.e., it has expired)

Section 7.3 appears to refer to the last of these, but an application
server has no information that allows it to distinguish between the cases.

It's important for us to be able to distinguish because in case 1 we should
remove the subscription, in case 2 we should mark it as blocked (so that
website code does not invite the user to resubscribe) and in case 3 we
should mark the subscription so that a service worker or website code
resubscribes.

Regards
Ben

—

Ben Last, Senior Full Stack Engineer

Mobile Customer Engagement

mobify.com
<http://www.mobify.com/?utm_source=Email&utm_medium=Email&utm_campaign=email-signature>
|
M 1.604.358.0155 | @benlast <https://twitter.com/@benlast>

Mobify is ranked as a leader in mobile customer engagement. View the Report!
<http://resources.mobify.com/forrester-wave-report-2016.html?utm_source=Email&utm_medium=Email&utm_campaign=email-signature>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Aug 2016 11:45:37 +1000

On 16 August 2016 at 02:50, Ben Last <[email-masked]> wrote:

> It's important for us to be able to distinguish because in case 1 we
> should remove the subscription, in case 2 we should mark it as blocked (so
> that website code does not invite the user to resubscribe) and in case 3 we

Doesn't the permissions API allow you to distinguish between 2 and 3?  For
both those cases, you need to run code in the browser before the
distinction is relevant.

As for 1, why would you ever have an invalid subscription in your database?

---

From: Ben Last <[email-masked]>
Date: Tue, 16 Aug 2016 09:21:08 -0700

Hi Martin

As you point out, distinguishing between 2 & 3 requires running code on the
browser. But if the end-user does not return to the website, we can't run
code and therefore can't make that distinction. We may send many messages
between visits. We can't run code in the service worker because there's no
event that can be relied on to fire (since no service workers support
periodic sync, and background sync doesn't allow for repeated events).

As for why we might have an invalid subscription: data may be corrupted, we
may be subject to attacks that send us random subscription data, and we do
see subscriptions sent from compromised versions of Chromium that may or
may not be actually valid. Also, it's probably good design to allow for
this case.

b

—

mobify.com

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Aug 2016 10:57:13 +1000

What I was trying to get at was this: The best policy here is to remove a
subscription that gets a 404.  In all cases.

Trying again isn't going to get you better results the next time.  When -
if - you get a chance to run code in the browser again, you have a chance
at remediation.

On 17 August 2016 at 02:21, Ben Last <[email-masked]> wrote:

> Hi Martin
>
> As you point out, distinguishing between 2 & 3 requires running code on
> the browser. But if the end-user does not return to the website, we can't
> run code and therefore can't make that distinction. We may send many
> messages between visits. We can't run code in the service worker because
> there's no event that can be relied on to fire (since no service workers
> support periodic sync, and background sync doesn't allow for repeated
> events).
>
> As for why we might have an invalid subscription: data may be corrupted,
> we may be subject to attacks that send us random subscription data, and we
> do see subscriptions sent from compromised versions of Chromium that may or
> <http://www.mobify.com/?utm_source=Email&utm_medium=Email&utm_campaign=email-signature> |
>> Doesn't the permissions API allow you to distinguish between 2 and 3?
>> For both those cases, you need to run code in the browser before the
>> distinction is relevant.
>>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>
>