Subject: [Webpush] Polling to adopt VAPID draft

From: Shida Schubert <[email-masked]>
Date: Mon, 4 Apr 2016 19:18:25 -0300

All;

As I mentioned at the meeting today, I am polling the list for adopting VAPID draft as a WG item for a milestone “voluntary application identification mechanism for web push draft to IESG as Proposed Standard”. 

https://tools.ietf.org/id/draft-thomson-webpush-vapid-02.txt <https://tools.ietf.org/id/draft-thomson-webpush-vapid-02.txt>

If you have concern or objections with this, please express your opinion(s) by responding to this e-mail. 

If you like the draft, see value and you like to see it adopted, please express that as well by responding to this e-mail.
*Even if you have expressed your interest previously in the room or on the list, please express your support again. 

If you are confused with this e-mail, please let me know :)  

Thanks! 
Shida as co-chair

---

From: jr conlin <[email-masked]>
Date: Mon, 4 Apr 2016 19:14:48 -0700

As a service provider, I express my strong support for the VAPID 
specification.

On 04/04/2016 03:18 PM, Shida Schubert wrote:
>
> All;
>
> As I mentioned at the meeting today, I am polling the list for 
> adopting VAPID draft as a WG item for a milestone “voluntary 
> application identification mechanism for web push draft to IESG as 
> Proposed Standard”.
>
> https://tools.ietf.org/id/draft-thomson-webpush-vapid-02.txt
>
> If you like the draft, see value and you like to see it adopted, 
> please express that as well by responding to this e-mail.
> *Even if you have expressed your interest previously in the room or on 
> the list, please express your support again.
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush

---

From: Darshak Thakore <[email-masked]>
Date: Tue, 5 Apr 2016 02:47:18 +0000

Hi all,
After reviewing the draft, I agree that it provides a useful option to the core webpush protocol that allows the push service to operate with better “intelligence” and scale by using information volunteered by the application servers. I am in favor of adopting this as a WG item.

I do have a few questions/clarifications that I’ll send in a separate thread.

Regards,
Darshak

On 4/4/16, 4:18 PM, "Webpush on behalf of Shida Schubert" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

All;

Thanks!
Shida as co-chair

---

From: Richard Maher <[email-masked]>
Date: Tue, 5 Apr 2016 20:42:34 +0800

Hi jr,

As a "service provider" what are YOU going to provide?

So subscription.getKey() is now a mandatory method?

Does Mozilla need to implement "xxx_sender_id" in the manifest?

Why is there no talk of TOPIC subscriptions? A server subscribing a client
to a TOPIC is surely bullshit?

Can't these standards proposals ever talk about implementations? Who wins?
Google, Mozilla, Someone else?

Cheers Richard Maher (I liked Dallas)

---------- Forwarded message ----------
From: jr conlin <[email-masked]>
Date: Tue, Apr 5, 2016 at 10:14 AM
Subject: Re: [Webpush] Polling to adopt VAPID draft
To: [email-masked]

All;

As I mentioned at the meeting today, I am polling the list for adopting
VAPID draft as a WG item for a milestone “voluntary application
identification mechanism for web push draft to IESG as Proposed Standard”.

If you have concern or objections with this, please express your opinion(s)
by responding to this e-mail.

If you like the draft, see value and you like to see it adopted, please
express that as well by responding to this e-mail.
*Even if you have expressed your interest previously in the room or on the
list, please express your support again.

Thanks!
Shida as co-chair

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

---

From: Kit Cambridge <[email-masked]>
Date: Tue, 5 Apr 2016 06:44:41 -0700

Hey Richard,

(Responses inline).

> As a "service provider" what are YOU going to provide?

Our main concern is being able to contact senders. For example, if their server is misconfigured, or if we see unusually high traffic from a particular sender. Without any contact info, we could only resort to throttling or blacklisting. But this is voluntary, of course: as a sender, you're not required to use VAPID if you don't want to.

We'll also use this to provide a "developer dashboard," similar to GCM's stats. If you opt in, you'll be able to see how many messages were delivered, whether the recipient was online or offline, and whether there were delivery errors: bad crypto and uncaught exceptions in service workers, for example.

> So subscription.getKey() is now a mandatory method?

`subscription.getKey()` is only for encrypting push messages. Encryption has always been mandatory in Web Push, unless you'd like to send a data-free "ping" and have your app fetch the data it needs from your server.

VAPID is totally voluntary. The sender generates an ECDSA key pair and uses the private key to sign JWT tokens.

> Does Mozilla need to implement "xxx_sender_id" in the manifest?

I don't think so. The other part of VAPID is creating a "restricted subscription," which binds a subscription endpoint to your key. That way, if the endpoint is leaked, you’ll still need the key pair to send messages to it. You can see how the DOM API will work here: https://github.com/w3c/push-api/pull/187

Again, that's voluntary; you don't need to restrict subscriptions to use VAPID. You can still include a JWT token and only have your server identify. Or, you can not identify at all.

> Why is there no talk of TOPIC subscriptions? A server subscribing a client to a TOPIC is surely bullshit?

I don't follow this point. What do you mean by "a server subscribing a client to a TOPIC”?

Web Push uses "topic" to refer to collapsing multiple messages, like GCM's `collapse_key`...but there's no way for a server to make a client subscribe. Could you please elaborate?

> Can't these standards proposals ever talk about implementations? Who wins? Google, Mozilla, Someone else?

How do you mean? Would you like these proposals to include examples, or links to implementations?

Cheers,
- kit

> As a service provider, I express my strong support for the VAPID specification. 
>

---

From: Costin Manolache <[email-masked]>
Date: Tue, 5 Apr 2016 14:53:57 -0700

+1

---

From: Richard Maher <[email-masked]>
Date: Wed, 6 Apr 2016 08:33:05 +0800

Hi Kit,

> I don't follow this point. What do you mean by "a server subscribing a
client to a TOPIC”?

I may have misunderstood the documentation but WRT
https://developers.google.com/cloud-messaging/topic-messaging#managing_topic_subscriptions_from_the_server
and
https://developers.google.com/instance-id/reference/server#create_a_relation_mapping_for_an_app_instance
, in the absence of any client topic-subscription mechanism what else can
we do?

> How do you mean? Would you like these proposals to include examples, or
links to implementations?

Either/or would be good

Thanks for the reply and sorry to others for going off-TOPIC :-)

Cheers Richard

On Tue, Apr 5, 2016 at 9:44 PM, Kit Cambridge <[email-masked]>
wrote:

> Our main concern is being able to contact senders. For example, if their
> server is misconfigured, or if we see unusually high traffic from a
> particular sender. Without any contact info, we could only resort to
> throttling or blacklisting. But this is voluntary, of course: as a sender,
> you're not required to use VAPID if you don't want to.
>
> We'll also use this to provide a "developer dashboard," similar to GCM's
> stats. If you opt in, you'll be able to see how many messages were
> delivered, whether the recipient was online or offline, and whether there
> were delivery errors: bad crypto and uncaught exceptions in service
> workers, for example.
>
> `subscription.getKey()` is only for encrypting push messages. Encryption
> has always been mandatory in Web Push, unless you'd like to send a
> data-free "ping" and have your app fetch the data it needs from your server.
>
> I don't think so. The other part of VAPID is creating a "restricted
> subscription," which binds a subscription endpoint to your key. That way,
> if the endpoint is leaked, you’ll still need the key pair to send messages
> to it. You can see how the DOM API will work here:
> https://github.com/w3c/push-api/pull/187
>
> Again, that's voluntary; you don't need to restrict subscriptions to use
> VAPID. You can still include a JWT token and only have your server
> identify. Or, you can not identify at all.
>
> Web Push uses "topic" to refer to collapsing multiple messages, like GCM's
> `collapse_key`...but there's no way for a server to make a client
> subscribe. Could you please elaborate?
>

---

From: Benjamin Bangert <[email-masked]>
Date: Tue, 5 Apr 2016 19:06:19 -0700

On Tue, Apr 5, 2016 at 5:33 PM, Richard Maher <[email-masked]> wrote:
> , in the absence of any client topic-subscription mechanism what else can we
> do?

That is documentation for Google Cloud Messaging, not WebPush. Under
WebPush, topic collapsing is purely an appserver option when sending a
message such that if a message of the same topic was already stored,
the new message will replace it.

As far as I know, there are no implementations of Webpush topics yet,
the spec describes it here:
https://tools.ietf.org/html/draft-ietf-webpush-protocol-04#section-6.4

We're probably a few weeks or month or so out from implementing this
for Firefox.

Cheers,
Ben

---

From: Richard Maher <[email-masked]>
Date: Wed, 6 Apr 2016 10:45:33 +0800

Hi Benjamin,

> https://tools.ietf.org/html/draft-ietf-webpush-protocol-04#section-6.4

Now I'm completely lost and more than a tad disappointed.

> That is documentation for Google Cloud Messaging,

I know. I, perhaps wrongly, assumed the consumers of GCM (et al) would take
full advantage of the infrastructure. "Collapsing" is a very useful
optimization option but surely not the raison d'etre of topics?

I want to subscribe to /SEVERE/PERTH topics for push messages my weather
app. The fact that old messages are collapsed is wonderful but if you're
also going to bombard me with /MILD/TIMBUKTU messages (and so on) then I'm
not too happy.

I want to subscribe to the BHP stock ticker broadcasts and then maybe add
FMG but I don't want the ASX 200.

Have I really imagined that GCM cann do that?

Cheers Richard

---

From: Benjamin Bangert <[email-masked]>
Date: Tue, 5 Apr 2016 19:54:47 -0700

> Now I'm completely lost and more than a tad disappointed.

This mailing list is to discuss the IETF WebPush protocol, while some
push implementations have inspired additions, they are separate from
the spec that browsers are working to implement.

> optimization option but surely not the raison d'etre of topics?

For WebPush, thats the primary intention.

> Have I really imagined that GCM cann do that?

GCM can, WebPush cannot. What you're referring to has been proposed as
the WebPush aggregation spec, which can be found here:
https://github.com/martinthomson/webpush-aggregate

Cheers,
Ben

---

From: Richard Maher <[email-masked]>
Date: Wed, 6 Apr 2016 11:20:47 +0800

Here we go again :-(

> This mailing list is to discuss the IETF WebPush protocol

Yes, a living and evolving document. Let's not seek to censor the
discussion or spit the dummy.

> while some
> push implementations have inspired additions,
> they are separate from the spec that browsers
> are working to implement.

An interesting opinion. IMHO, that demarcation is so narrow and restrictive
that's it's no wonder that real world technology in the wild has rendered
these standards redundant.

Once again, Web-Apps are deliberately being denied the life-giving
functionality of native Apps by design.

Is this more about Mozilla's free messaging service not be resourced
sufficiently in order to match GCM functionality?

I can see the Google involvement but I suggest we need more. AWS around?

> For WebPush, thats the primary intention.

Who voted for that???

Look FWIW I'll vote no to this standard as a moratorium on bureaucracy is
required until the terms of reference has been revisited. Bit more RAD,
Agile, Iterative, Buzz-word methodology needed here? Surely only those on
the receiving end of Panama could vote for such a WebPush killer :-(

> What you're referring to has been proposed as

No it is not and please do not put words in my mouth. I want the
broadcasting capability that GCM is offering today and I think I can
already achieve it at the App server but the subscription mapping should to
be done at the client. Just give us another PushManager,subscribe(option).

Cheers Richard

---

From: Shida Schubert <[email-masked]>
Date: Thu, 7 Apr 2016 12:26:16 -0300

I am seeing that there are enough support/interests for this draft, so I am going to ask the authors to submit it as a WG draft. 

Thanks! 
Shida as co-chair

> On Apr 6, 2016, at 12:20 AM, Richard Maher <[email-masked]> wrote:
> 
> Here we go again :-(
> 
> Yes, a living and evolving document. Let's not seek to censor the discussion or spit the dummy.
> 
> > while some
> An interesting opinion. IMHO, that demarcation is so narrow and restrictive that's it's no wonder that real world technology in the wild has rendered these standards redundant.
> 
> Once again, Web-Apps are deliberately being denied the life-giving functionality of native Apps by design.
> 
> Is this more about Mozilla's free messaging service not be resourced sufficiently in order to match GCM functionality?
> 
> Look FWIW I'll vote no to this standard as a moratorium on bureaucracy is required until the terms of reference has been revisited. Bit more RAD, Agile, Iterative, Buzz-word methodology needed here? Surely only those on the receiving end of Panama could vote for such a WebPush killer :-(
> 
> > https://github.com/martinthomson/webpush-aggregate <https://github.com/martinthomson/webpush-aggregate>
> 
> No it is not and please do not put words in my mouth. I want the broadcasting capability that GCM is offering today and I think I can already achieve it at the App server but the subscription mapping should to be done at the client. Just give us another PushManager,subscribe(option).
> 
> Cheers Richard
> 
> On Wed, Apr 6, 2016 at 10:54 AM, Benjamin Bangert <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, Apr 5, 2016 at 7:45 PM, Richard Maher <[email-masked] <mailto:[email-masked]>> wrote:
> > Hi Benjamin,
> >
> >> https://tools.ietf.org/html/draft-ietf-webpush-protocol-04#section-6.4 <https://tools.ietf.org/html/draft-ietf-webpush-protocol-04#section-6.4>
> >
> https://github.com/martinthomson/webpush-aggregate <https://github.com/martinthomson/webpush-aggregate>
> 
> Cheers,
> Ben
>