Re: [Webpush] Some comments on webpush server responses

Martin Thomson <martin.thomson@gmail.com> Wed, 17 August 2016 00:57 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3FB12D13D for <webpush@ietfa.amsl.com>; Tue, 16 Aug 2016 17:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQamPmu0wsBN for <webpush@ietfa.amsl.com>; Tue, 16 Aug 2016 17:57:14 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8F712D0CD for <webpush@ietf.org>; Tue, 16 Aug 2016 17:57:14 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id v123so87899911qkh.2 for <webpush@ietf.org>; Tue, 16 Aug 2016 17:57:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UcSEyT7FFl1L+4gl8DCn7FAypZ41glx7zjqi2c0hmOQ=; b=uEBd3Ml85S9CGihCmxnkrmk0WjctIyX4JYL64U6UZPsaZIt10Xxw+4KkuCr5+NKbNH dGJZTQ0Nrbj6Vye+7NIEx2ej/QPy36Kmxsnsnzbph2nBWzWXwSiTDxfWuUYoyLN9tBqt knvTFsYxUN6Xutd6glKRxLJb2z6suMgjR0GyAU25xcgK84iMmb9tIZAFldD2C81qoVXw v+GR0VDCq+qrvWbFCOBeTlX0trvve3O3Zm05+5oI6VHdFKtO4b9ppISs82sm2add3/wC kshjPYpKwaxM6N+FKTOn7UEZZn1MSySojshAr/jhbZSa1Iv4yxGueuhR1nxfZJDiJqXB i7sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UcSEyT7FFl1L+4gl8DCn7FAypZ41glx7zjqi2c0hmOQ=; b=giKqBWlgioe21hREv5G+pLlH8sjkTukhWnAuT+4soGcNbHv+oFum86/O9voR5dw2Kp 3yib7FJUj5Jm2URIY0We4BqVfZnrBk8Y40fHYwmlDh2+kNZ6fXGlPCnNPip1Pa1qEcK3 3tVZno+YII218Q5kWztMYXyeDiesr8bm0dF3AT+ewFQ6bqk0R5u0PCW5V/mVs7gWFBX1 M51LreuPNpXYIjZQmvVU4bzXSFnI7sis4cl+mEd9oodVFUjMB7sJKpZ2x8bhhjRXoXoC y1YjHgQjfqR1sz8ERLzcQRBfocyeV3uDI4AXy4IV6TAlfElrgSsexVKnwQBld1ycrl/v NIDA==
X-Gm-Message-State: AEkoouv57KL/Mk8ufpRtugNcz2tsRPqlh2wNBsKdhV4RbUQIMmnzXt8ymbB30TDWxlxNr2mq1lxgc/VKaXDkOg==
X-Received: by 10.55.141.199 with SMTP id p190mr41233555qkd.185.1471395433575; Tue, 16 Aug 2016 17:57:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.146 with HTTP; Tue, 16 Aug 2016 17:57:13 -0700 (PDT)
In-Reply-To: <CAM5PDDw6vpXmV41EwN=1Gnc-cVui2QaeThZEJjyUu_g5GabLWQ@mail.gmail.com>
References: <CAM5PDDwdPnM1U-dx6Caqf-Uv3yfTu+QxkKWkA90eCO+Mu_=sgQ@mail.gmail.com> <CABkgnnV5xu1ChQ70X9sxbjiGi45WjsB5sfVYyKN1ucAAzYiQSw@mail.gmail.com> <CAM5PDDw6vpXmV41EwN=1Gnc-cVui2QaeThZEJjyUu_g5GabLWQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 17 Aug 2016 10:57:13 +1000
Message-ID: <CABkgnnVLgK0VujPtdL7mnanp8uhax1POH4-LeyvnTPFTa5G=nQ@mail.gmail.com>
To: Ben Last <benlast@mobify.com>
Content-Type: multipart/alternative; boundary=94eb2c081fde247d9e053a39f2f9
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/A116nJE3KHmc5zO2D04BOLWFaCg>
Cc: "webpush@ietf.org" <webpush@ietf.org>
Subject: Re: [Webpush] Some comments on webpush server responses
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2016 00:57:16 -0000

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 <benlast@mobify.com> 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
> may not be actually valid. Also, it's probably good design to allow for
> this case.
>
> b
>
>
>
> —
>
> Ben Last, Senior Full Stack Engineer
>
> [image: Mobify]
>
> 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>
>
>
>
> On 15 August 2016 at 18:45, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>>
>> On 16 August 2016 at 02:50, Ben Last <benlast@mobify.com> 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
>>> should mark the subscription so that a service worker or website code
>>> resubscribes.
>>
>>
>> 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?
>>
>
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>
>