Re: [Webpush] User Agents should return a list of supported encryption content types

Martin Thomson <> Thu, 20 April 2017 00:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03DC512EAD4 for <>; Wed, 19 Apr 2017 17:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iEKx2lrfdv1W for <>; Wed, 19 Apr 2017 17:14:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7A0212EAC8 for <>; Wed, 19 Apr 2017 17:14:30 -0700 (PDT)
Received: by with SMTP id c80so20507334lfh.3 for <>; Wed, 19 Apr 2017 17:14:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dmx+25jfzztJ/0QnPwUPKuVq2k6bIPSB3Hb3Wkf5Lc0=; b=Sw7odCrpdsNe3VOzvSEz3B6XLp1KjyEXxOnc0YOKsR/A1hfXql7GHRbRTfjw013Asp CooGiLdf68ReOgau8ZTtohBuz5vlqYkPJCSnAfu8XppYwYgcmK0acrcwm1Jwuvcy3YI8 F6xnOrm3pgTkMATZUeSLrxJqUXNq9PkKjycEg+mbFe6DDkaRB1BQs6EQaGfcgY3Nu8NT Uy46l+T3q2WCDHM6heATlM7qym3tXfPA+ehrsi6pwngNJNUz5K/TpyaZcihOdPwqTySz JT/R8zbAgsUdEKC2cegOIAZSbJcYj4MKRozhCH/pEp/x/PXv4l9I3hBNn6W0mZIxglHn w4Ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dmx+25jfzztJ/0QnPwUPKuVq2k6bIPSB3Hb3Wkf5Lc0=; b=ukm0pxifhJqqnRdJReTEFizOutEcaV8k1t/kW2Q2H7opbXzlqEJSrEZYoDbRLd0xKQ qgUXnGMdodA82Cr/veOX9ZObDKZFU2K4m3bRJpST0yMJjyA60fzBImO6E++cJyShwZHa fZbAnhOdpeOELozVnVDeB6DYQSf23QolqyvXTLj10eT6bkqhfeDBWPh0x13BqxiqNDUW WHwpXS577/fwrJNR8im0VY7hmJHdzgH6WnF8u0ariW0OPtnF6kyMCuzT1FJU0gG4UENq ObUvBZyuf+igguHhHyU+56rClH4thAVFtuXTPa2phg329mesmnmztOLkPg+Jn8LbNCKH OljQ==
X-Gm-Message-State: AN3rC/5IO/X14kqDZWcfh6Zor7wwyV5BnIGGgDBYeUF1Y5eH8jz3agv9 z0fjzlnZS9E5bjLZ2oUJ2ifTiM1kk+m7PGY=
X-Received: by with SMTP id d27mr1663642lfb.76.1492647269071; Wed, 19 Apr 2017 17:14:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Apr 2017 17:14:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Martin Thomson <>
Date: Thu, 20 Apr 2017 10:14:28 +1000
Message-ID: <>
To: JR Conlin <>
Cc: "" <>, Kit Cambridge <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Subject: Re: [Webpush] User Agents should return a list of supported encryption content types
X-Mailman-Version: 2.1.22
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: Thu, 20 Apr 2017 00:14:33 -0000

I think that JR's proposed solution works best (no need for
intermediation of the information via the push service, immediate
availability of the information, etc...).

As a procedural matter, this is the wrong place to discuss the API.
I'd recommend opening an issue (or a pull request, but that's only for
the brave) against the API:

(As an aside, this isn't a per-subscription property, so I'd probably
angle for a FrozenArray<DOMString> property on PushManager.  That way,
an application can know whether or not to even bother creating a
subscription. There's also a separate question about whether we also
use this to signal support for empty messages, which have no content

On 20 April 2017 at 08:44, JR Conlin <> wrote:
> And I've just realized that I have mislabled it as "contenttypes" instead of
> "contentencodings".
> On Wed, Apr 19, 2017 at 2:55 PM, JR Conlin <> wrote:
>> On Wed, Apr 19, 2017 at 2:41 PM, Kit Cambridge <> wrote:
>>>> 2) it's non-authoritative. The push server either is told or must guess
>>>> the state of an individual client. This means that it must track known UAs
>>>> (since a message can be stored for later retrieval by the UA). Having the
>>>> "source of truth" specify what's allowed and what's not at the time of
>>>> subscription, ensures that the most accurate data is provided.
>>> I don't follow, apologies. For Autopush, we already keep client info in
>>> the router table: its UAID, last connect time, and whether it uses Web Push,
>>> Simple Push, FCM, or APNs. We need to look this up regardless of whether we
>>> store or immediately deliver the message. It's not clear to me why we'd need
>>> to guess, or who the third party is. I think I'm missing something, though.
>>> Could you please elaborate?
>> Certainly. It's true that for our server, we do track the state of a
>> previously connected UA for up to 30 days. (If a UA has not connected in 30
>> days, we consider that UA to be "unavailable" and reject messages.) The
>> problem is that the client would still need to inform the push server which
>> content types it supported, much the same as it would need to tell the
>> subscription provider.
>> The crux of this is that the Push Service is the "third party". It doesn't
>> care what the encryption format is, since it just passes the data on. The
>> two parties of interest in this case are the User Agent (which is
>> responsible for decoding the final message) and the Subscription Provider
>> (which is responsible for encoding the message). The Push Service may do
>> some minimal, superficial checks of the message it's carrying, in order to
>> reduce the traffic costs to the UA, but it cannot do a full check since that
>> would presumably require deciphering the message.
>> That's why I feel it's best to keep the pertinent information in the
>> exchange between the UA and the subscriber directly, much like how the
>> public key comes from the UA and not the Push Server.
> _______________________________________________
> Webpush mailing list