Subject: [Webpush] Push Message TTL

From: Benjamin Bangert <[email-masked]>
Date: Wed, 22 Jul 2015 09:58:13 -0700

(Starting new threads for any further comments)

https://unicorn-wg.github.io/webpush-protocol/#ttl makes some odd
requirements on the Push Service.

"Once the Time-To-Live (TTL) period elapses, the push service MUST remove
the push message and cease any attempt to deliver it to the user agent. A
push service might retain values for a short duration after the TTL period
to account for time accounting errors in processing. For instance,
distributing a push message within a server cluster might accrue errors due
to clock variation, or processing and transit delays"

I don't understand the requirement on the Push Service to remove expired
messages so aggressively. Of course its not a big deal when a UA connects,
to drop expired messages on checking storage instead of delivering them,
but why is it not ok for a Push Service to only conduct periodic cleanups
weekly (as it chooses fit) to delete expired messages?

Cheers,
Ben

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jul 2015 19:06:07 +0200

On 22 July 2015 at 18:58, Benjamin Bangert <[email-masked]> wrote:
> messages so aggressively.

I wanted to avoid situations where messages that are strictly
time-bounded (a call notification is a good example) are delivered and
acted upon.  If an application says TTL: 10, then I would like some
certainty that the push service respects that and doesn't deliver the
message an hour later.

If you don't have a requirement to drop the message, then applications
will have to add their own TTL handling (something they might want to
do for separate, security reasons, but something that they probably
wont).  If the application doesn't check for validity, they could do
bad things on old information, like trigger a call alert.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jul 2015 19:08:39 +0200

And... Ben just corrected me offline.  There is a mode where the push
service only does TTL-based cleanup periodically, or when clients
connect.  That suggests that we might want to relax the requirement to
delete the data.  However, there might be some privacy implications to
retaining the information, so some sort of time bound might be needed.

I'll open an issue on the spec.

---

From: Costin Manolache <[email-masked]>
Date: Wed, 22 Jul 2015 15:39:40 -0700

GCM is doing lazy cleanup - and checks before delivering any message.
The cost to delete each expired message at the time it expired would be
quite big -
the spec should certainly require that expired messages are not delivered,
but
not how it is implemented. Best time bound would be 'maximum TTL' - it's
cheapest in some databases.

Costin

On Wed, Jul 22, 2015 at 10:08 AM, Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: nero <[email-masked]>
Date: Wed, 22 Jul 2015 15:53:25 -0700

+1 to Costin. There could be batch jobs running to clean up the expired
tokens, but you would still have retention longer than TTL for a bunch of
messages. The expectation of TTL should not be an expectation of privacy,
but an expectation of delivery.

The push system might retain messages in the cloud for longer that TTL, but
there is a guarantee that the end device will not receive messages with an
expired TTL.

Further, there could be different implementations, where the expired
messages would get delivered to the end device and the expectation would be
that those would not get routed to the application.

We did not choose the latter in the GCM implementation since it is worse in
terms of battery life for portable devices and network traffic.

  f

On Wed, Jul 22, 2015 at 3:39 PM, Costin Manolache <[email-masked]> wrote:

> On Wed, Jul 22, 2015 at 10:08 AM, Martin Thomson <[email-masked]
> > wrote:
>

-- 

Francesco Nerieri | Eng. Manager - Mobile | [email-masked] | 650.283.8890
*Quod semper currit sempiterno tempore*

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Jul 2015 13:10:15 +0200

On 23 July 2015 at 00:39, Costin Manolache <[email-masked]> wrote:
> the spec should certainly require that expired messages are not delivered

Yes, I think that this is an important invariant.

I've opened the issue, and I think that we're all in agreement
regarding cleanup.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Jul 2015 13:11:56 +0200

> that those would not get routed to the application.

I'm aware that some implementations do this.  There were a number of
cusswords exchanged when this "feature" was discovered.  I think that
we can and should mandate non-delivery, with only a small amount of
tolerance for clock drift/propagation delay.

---

From: nero <[email-masked]>
Date: Thu, 23 Jul 2015 05:23:40 -0700

Sgtm

---

From: Darshak Thakore <[email-masked]>
Date: Thu, 23 Jul 2015 12:35:03 +0000

+1

On 7/23/15, 6:23 AM, "Webpush on behalf of nero" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Sgtm

On Jul 23, 2015 1:11 PM, "Martin Thomson" <[email-masked]<mailto:[email-masked]>> wrote: