From nobody Mon Aug 15 09:51:34 2016 Return-Path: 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 D7D8B12D63B for ; Mon, 15 Aug 2016 09:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobify.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 Fm_5EzuOdpA1 for ; Mon, 15 Aug 2016 09:51:31 -0700 (PDT) Received: from smtp.mobify.com (smtp.mobify.com [162.222.122.205]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7AFD12D67F for ; Mon, 15 Aug 2016 09:50:13 -0700 (PDT) Received: from mail-it0-f69.google.com (mail-it0-f69.google.com [209.85.214.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.mobify.com (Postfix) with ESMTPS id 3E27D30065F for ; Mon, 15 Aug 2016 09:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mobify.com; s=smtp; t=1471279813; bh=6gb+eZ2y5u8/DE28xbAWPIo6L0GuV/lzhbBtd/tRdfo=; h=From:Date:Subject:To; b=HepR6xMF1YgXMtbRc5rGUFDzJ2lZNnXUevozE9w9yyL+xFxs85jlZ4SqwuvU0fGfZ otBMOO/a6lEh71EhYo9Iub7AeM63wyNNt15tWC5VzDk9AWdZXJCJvoCCcUeCfD2wQv oG99ByPQObrLFUMcZyfDFgzCLR8p2v8C8EmjBJYg= Received: by mail-it0-f69.google.com with SMTP id j124so182536488ith.1 for ; Mon, 15 Aug 2016 09:50:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ggqy9f9L6vxM3b4GpeCeQdDijhomxYYWxJIJxD8k9t0=; b=LuDseghg2L6hGgHcoob2Pj/BJWhnEhecZkU+NZaLNKR8QXlBEyVV/FDotSG4zHw35i Nu3skhkNSr0J3t6zRfW91FsfKfYsS2z2kYpDGWCzywhLot+dD9beJf9kHfL4Rfm+nwKA XZiAt336sxyhW/5PqAqGki9WlXEvNDiYpzoFgPfESL55MCQTHxp+OHPi3QW/P40UXDKX VkYnijAZN2LmJ9dXEx4jRX74WJsJoj1ptfkrCIBwjcxLHaWzeoB27ruqnxpVjTdEZPqx fVJ1zCFO+MG2hZUkPBGAx33lzrbxifHXJv+5DY3p4RTHMRYHu8D5muCPPVG/jUHmwmG+ 2fuA== X-Gm-Message-State: AEkooutEt9IxV4M3g+DO2v3nU2Y9QvJiq19b6OoxKx5TV8TN7VnJn0ga5qMBZVfmxm7yNMlbF55QnBaFai7TDpPt8lY+dMYlMBiLKsm6oculN6tmSARPkf1Mu9dkJFCoNQEOjvjPkN2vJXLLIxSsIMRV X-Received: by 10.36.76.16 with SMTP id a16mr15140546itb.77.1471279812503; Mon, 15 Aug 2016 09:50:12 -0700 (PDT) X-Received: by 10.36.76.16 with SMTP id a16mr15140522itb.77.1471279812313; Mon, 15 Aug 2016 09:50:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.166.134 with HTTP; Mon, 15 Aug 2016 09:50:11 -0700 (PDT) From: Ben Last Date: Mon, 15 Aug 2016 09:50:11 -0700 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a11447dc89430ea053a1f064a Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:51:33 -0000 --001a11447dc89430ea053a1f064a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=94 Ben Last, Senior Full Stack Engineer [image: Mobify] Mobile Customer Engagement mobify.com | M 1.604.358.0155 | @benlast Mobify is ranked as a leader in mobile customer engagement. View the Report= ! --001a11447dc89430ea053a1f064a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all=

Apologies if I violate IETF eti= quette here; I have some comments on=C2=A0https:/= /tools.ietf.org/html/draft-ietf-webpush-protocol-08#section-7.3

  1. The push subscription endpoint to which a POST was made is invalid - i= t does not refer to a known subscription
  2. The push subscription endpoint to which a POST was made is=C2=A0no = longer=C2=A0valid - it refers to a subscription that has been removed b= ecause the end-user removed notification permission
  3. The push subscription endpoint to which a POST was made is= =C2=A0no longer=C2=A0valid, but the subscription should be recreated= (i.e., it has expired)

=

Regards
Ben

=E2= =80=94

Ben Last, Senior Full Stack = Engineer

3D"Mobify"

Mobile Customer Engagement

mobify.com=C2=A0| M 1.604.358.0155=C2=A0| @benlast

Mobify is ranked as a leader in mobile customer engagement. View the Report!



--001a11447dc89430ea053a1f064a-- From nobody Mon Aug 15 18:45:40 2016 Return-Path: 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 685EE12D647 for ; Mon, 15 Aug 2016 18:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 XX4MBAbmpXsN for ; Mon, 15 Aug 2016 18:45:38 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 3F03012D18A for ; Mon, 15 Aug 2016 18:45:38 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id v123so58501756qkh.2 for ; Mon, 15 Aug 2016 18:45:38 -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=nIAJADGRHSXhQCN6eO9SCDwB97QY9DGNN7O0hcmQRSE=; b=xI7KJ4oXkEkEKNJPh7HG18UVFMGa6EsnMctHZjtGPi069zoh+YQmpeyc96emTDAHQn Ve9B6aZ9PiMsXAOmuPfgTP2XXPuzvVhp/Cc3niJxlIlWiHjvg5cS23Ci7YQqe7v8kE+9 mfgzgGD5VZ3wSDn8WBkuNgdlMDJM4QJb2aisTL9A19x6Cp9Z+HvWcCDUumWG2w2OEX8J AZN/gsD4Jv5685rQfVZce8vDX6DeF9XQhnid/FDKV9/+0c+j1EB2Ol6zMLS30KY+Px5p NQHF1738BU4FfsCB3ykj1hIyMbG9yL6fVm2kcCIhjMfdETwjR0Pt2+fX0HQbXy/d6Cjb K/WQ== 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=nIAJADGRHSXhQCN6eO9SCDwB97QY9DGNN7O0hcmQRSE=; b=bq0MA5bOdlnXM3QNMgjcCH2DSdhUU9StTukkAD3WoRx/55n2pJ0JQnP2CqKbVaagOD hV55vsDs3Tz4AR+D4Yrp6ni8V1gCGkwrBFO6985eqltlwblMNH0KC2hVocaTUCB8wfDp YaFJaGDjanUXVD8plLfnWF7agn4i2NLQcNA34w9UXBzDpD/6vUewY8LBJEmcMFcA4shy veSVLfHHC9WQ6SWKWzpzwhBmyPCTQQbN/sLpiCZPYPCIx3tXv4zRa6R5LKsagiRSniSg GhFLJMoZhNyQgON4FK/LCsx9hwPS9dhfDaR6tcj1+Dc7MVZ4masdlj9b0I5iiWMnOacS jB8w== X-Gm-Message-State: AEkoouvkomBCKG+vP+XUzd7wrb01lZVxqAFnsR9Rj1Zg01tFr43Bomgw89ky+Vwj8ZaggYR5freYiZ4ROEUZwg== X-Received: by 10.55.11.7 with SMTP id 7mr38444283qkl.169.1471311937469; Mon, 15 Aug 2016 18:45:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 15 Aug 2016 18:45:37 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 16 Aug 2016 11:45:37 +1000 Message-ID: To: Ben Last Content-Type: multipart/alternative; boundary=001a114c8a646301ba053a26814f Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 01:45:39 -0000 --001a114c8a646301ba053a26814f Content-Type: text/plain; charset=UTF-8 On 16 August 2016 at 02:50, Ben Last 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? --001a114c8a646301ba053a26814f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 16 August 2016 at 02:50, Ben Last <benlast@mobify.com> w= rote:
It's important for us to be abl= e to distinguish because in case 1 we should remove the subscription, in ca= se 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 di= stinguish between 2 and 3?=C2=A0 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?
--001a114c8a646301ba053a26814f-- From nobody Tue Aug 16 09:21:13 2016 Return-Path: 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 76BDA12D8CB for ; Tue, 16 Aug 2016 09:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobify.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 vqWugLgaC4KL for ; Tue, 16 Aug 2016 09:21:09 -0700 (PDT) Received: from smtp.mobify.com (smtp.mobify.com [162.222.122.205]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33B512D8C6 for ; Tue, 16 Aug 2016 09:21:09 -0700 (PDT) Received: from mail-it0-f69.google.com (mail-it0-f69.google.com [209.85.214.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.mobify.com (Postfix) with ESMTPS id 5BBEC30005D for ; Tue, 16 Aug 2016 09:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mobify.com; s=smtp; t=1471364469; bh=bQ6cZjy5FAmEeEcQ0zx5QcJEzWrs7HurMUJ/qMn408g=; h=In-Reply-To:References:From:Date:Subject:To; b=CE8Bwi9nFUJtejU43IBPlU/02PYZCqQjfFOJYC6fFs01jY+33NYxE2aXnTZZChzZj 68cpKMTOLZkO1WElOmxpbenqTM8Aaul+f+Fv3kojr5utoQMgGQoBe0oJo7PaEKG4EK Dq5eFpUsox+nLrK4RVpBYDfXm3/FYKxm8+Bh2kVU= Received: by mail-it0-f69.google.com with SMTP id n128so119514552ith.3 for ; Tue, 16 Aug 2016 09:21:09 -0700 (PDT) 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; bh=+tg4pwuJh5/Mb82Fha0lNnj1nPQ+RW6lz7YQEV1XWZg=; b=LLwZjANmnBXOyvxfUgKie+jZ/bOpR+ZG3TnDWENvShrDZqT5eEPoZBSagAv2X9pxtb /5WcrYPb+C09ybiCRvTpP9xkVBVWH5EJ9jYNMhTwDN7XuzR0dgv/ukRyuvlsvX/O+C7r oHzzYLh/5KHkilPwI5tyqucEKSGfIiRMrnr2af75X3PjPV9QTHDnfLFGXorhjjtyIaJ1 wZyWHa9f933PlQUsIxO6CPQsiRA1MzcRqmbnZ4u1FzKV4KHnV8L4Pg5/qXXZVj49hc5I aOpB5gOq/AxLxbSipt8Phk5GeszMo5F+ThBd3/s6rNzyGFKOC75X2Jdo7ozQUhJ9y16n 9+Sw== X-Gm-Message-State: AEkooutcPFGRs13AaSCbcTB5bkfkP4wtek0tNO+R8ZhXrkCVcaMIukvmJJpZ+t1OgDyhk5GeSKJbxKOHSUlD1W+FWNrAq27gZu7w8ARNA3u0l9NEAcLDoz0VrTmEi/U2hT5rF0Hi12L28cCSRcYrBTeg X-Received: by 10.107.133.93 with SMTP id h90mr41292313iod.16.1471364468753; Tue, 16 Aug 2016 09:21:08 -0700 (PDT) X-Received: by 10.107.133.93 with SMTP id h90mr41292283iod.16.1471364468509; Tue, 16 Aug 2016 09:21:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.166.134 with HTTP; Tue, 16 Aug 2016 09:21:08 -0700 (PDT) In-Reply-To: References: From: Ben Last Date: Tue, 16 Aug 2016 09:21:08 -0700 Message-ID: To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a113f0c147b1701053a32bc43 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 16:21:11 -0000 --001a113f0c147b1701053a32bc43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=94 Ben Last, Senior Full Stack Engineer [image: Mobify] Mobile Customer Engagement mobify.com | M 1.604.358.0155 | @benlast Mobify is ranked as a leader in mobile customer engagement. View the Report= ! On 15 August 2016 at 18:45, Martin Thomson wrote= : > > On 16 August 2016 at 02:50, Ben Last 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? Fo= r > 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 databas= e? > --001a113f0c147b1701053a32bc43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin

As you point out, distinguish= ing 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 ca= n'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).

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

b

<= div class=3D"gmail_extra">

=E2=80= =94

Ben Last, Senior Full Stack = Engineer

3D"Mobify"

Mobile Customer Engagement

mo= bify.com=C2=A0| M 1.604.358.0155=C2=A0| @benlast

Mobify i= s ranked as a leader in mobile customer engagement. View the Report!<= /p>




On 15 August 2016 at 18:45, Martin Thomson <= span dir=3D"ltr"><martin.thomson@gmail.com> wrote:
=
On 16 August 2016 at 02:50, Ben Last <benl= ast@mobify.com> wrote:
It&#= 39;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 w= ebsite code does not invite the user to resubscribe) and in case 3 we shoul= d mark the subscription so that a service worker or website code resubscrib= es.

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

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

--001a113f0c147b1701053a32bc43-- From nobody Tue Aug 16 17:57:17 2016 Return-Path: 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 ; 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 ; 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 ; Tue, 16 Aug 2016 17:57:14 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id v123so87899911qkh.2 for ; 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: References: From: Martin Thomson Date: Wed, 17 Aug 2016 10:57:13 +1000 Message-ID: To: Ben Last Content-Type: multipart/alternative; boundary=94eb2c081fde247d9e053a39f2f9 Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 00:57:16 -0000 --94eb2c081fde247d9e053a39f2f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 w= e > 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 > > > > =E2=80=94 > > Ben Last, Senior Full Stack Engineer > > [image: Mobify] > > Mobile Customer Engagement > > mobify.com > | > M 1.604.358.0155 | @benlast > > Mobify is ranked as a leader in mobile customer engagement. View the > Report! > > > > > On 15 August 2016 at 18:45, Martin Thomson > wrote: > >> >> On 16 August 2016 at 02:50, Ben Last 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 > > --94eb2c081fde247d9e053a39f2f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What I was trying to get at was this: The best policy here= is to remove a subscription that gets a 404.=C2=A0 In all cases.

Tr= ying again isn't going to get you better results the next time.=C2=A0 W= hen - if - you get a chance to run code in the browser again, you have a ch= ance at remediation.

On 17 August 2016 at 02:21, Ben Last <benlast@mobify.com= > wrote:
Hi Ma= rtin

As you point out, distinguishing between 2 & 3 = requires running code on the browser. But if the end-user does not return t= o the website, we can't run code and therefore can't make that dist= inction. 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 f= ire (since no service workers support periodic sync, and background sync do= esn't allow for repeated events).

As for why w= e might have an invalid subscription: data may be corrupted, we may be subj= ect to attacks that send us random subscription data, and we do see subscri= ptions sent from compromised versions of Chromium that may or may not be ac= tually valid. Also, it's probably good design to allow for this case.

b



=E2=80= =94

Ben Last, Senior Full Stack = Engineer

3D"Mobify"

Mobile Customer Engagement

mo= bify.com=C2=A0| M 1.604.358.0155=C2=A0| @benlast

Mobify i= s ranked as a leader in mobile customer engagement. View the Report!<= /p>




On 15 August 2= 016 at 18:45, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 August 2016 at 02:5= 0, 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 webs= ite code resubscribes.

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

A= s for 1, why would you ever have an invalid subscription in your database?<= br>


_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush<= br>

--94eb2c081fde247d9e053a39f2f9-- From nobody Sun Aug 28 15:02:03 2016 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F5C12B00A; Sun, 28 Aug 2016 15:02:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147242172232.24392.12161716485164712262.idtracker@ietfa.amsl.com> Date: Sun, 28 Aug 2016 15:02:02 -0700 Archived-At: Cc: shida@ntt-at.com, webpush-chairs@ietf.org, alissa@cooperw.in, webpush@ietf.org Subject: [Webpush] webpush - New Meeting Session Request for IETF 97 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 22:02:02 -0000 A new meeting session request has just been submitted by Shida Schubert, a Chair of the webpush working group. --------------------------------------------------------- Working Group Name: Web-Based Push Notifications Area Name: Applications and Real-Time Area Session Requester: Shida Schubert Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: httpbis mmusic rtcweb tram tls Second Priority: stir modern Special Requests: ---------------------------------------------------------