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

Martin Thomson <martin.thomson@gmail.com> Thu, 20 April 2017 00:14 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 03DC512EAD4 for <webpush@ietfa.amsl.com>; Wed, 19 Apr 2017 17:14:33 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 iEKx2lrfdv1W for <webpush@ietfa.amsl.com>; Wed, 19 Apr 2017 17:14:31 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 C7A0212EAC8 for <webpush@ietf.org>; Wed, 19 Apr 2017 17:14:30 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id c80so20507334lfh.3 for <webpush@ietf.org>; Wed, 19 Apr 2017 17:14:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.25.79.27 with SMTP id d27mr1663642lfb.76.1492647269071; Wed, 19 Apr 2017 17:14:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.83.5 with HTTP; Wed, 19 Apr 2017 17:14:28 -0700 (PDT)
In-Reply-To: <CA+XEteMC1S7dzv2MryigpOU6umJKL5C=dTCiR_bJOOS6PpjqOQ@mail.gmail.com>
References: <CA+XEtePZfEMv2AOCsF4O0NxTedMm3cK07UxZy2bwrEQk+ME98Q@mail.gmail.com> <CAEeQnY+8DWASaPMC=mkMv-HJ6Xbw4xUXY+=50kqijfDPg+-dpA@mail.gmail.com> <CA+XEteNjNtkj=8LYZ89mJzmXDuu2LJtV7W3M5zNgJfOM7n6v9g@mail.gmail.com> <CAEeQnY+cE-H5XOCnQL=oebF0umNQFX5OPAQ+RB-L9aoBfwdp5Q@mail.gmail.com> <CA+XEteNJp6WJSrS-jC2sOBcJEXOG_TVD3eY0Zxj2w7_fepbRug@mail.gmail.com> <CA+XEteMC1S7dzv2MryigpOU6umJKL5C=dTCiR_bJOOS6PpjqOQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 20 Apr 2017 10:14:28 +1000
Message-ID: <CABkgnnXJ7SyxP34R9fS0ge3GW3RvZb76pgp82ULao3G9zgUPGQ@mail.gmail.com>
To: JR Conlin <jrconlin@mozilla.com>
Cc: "webpush@ietf.org" <webpush@ietf.org>, Kit Cambridge <kit@mozilla.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/qKO4c7AymJ9kfZTN3SFOpVQI4wg>
Subject: Re: [Webpush] User Agents should return a list of supported encryption content types
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.22
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: 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: https://github.com/w3c/push-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
coding.)

On 20 April 2017 at 08:44, JR Conlin <jconlin@mozilla.com> 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 <jconlin@mozilla.com> wrote:
>>
>>
>> On Wed, Apr 19, 2017 at 2:41 PM, Kit Cambridge <kit@mozilla.com> 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
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>