Subject: [Webpush] Non-blocking comments on -05

From: Peter Beverloo <[email-masked]>
Date: Tue, 31 May 2016 20:40:27 +0100

Hi Martin, Brian, Elio,

As an implementer I can only express my gratitude for the fantastic
creating and editing of the standard you have done - thank you *so* much!

I have a few last-minute comments, none of which have to be blocking for
the WGLC. I'll acknowledge agreement in Shida's thread momentarily.

    1) Page 11, "A push message with zero TTL...push messages."

This section is very loose in defining whether or not delivery receipts
should be send for messages with TTL 0. In effect, behaviour of the Web
Push services out there today may strong-arm future services by
establishing developer expectations.

Have we considered not sending receipts for messages with TTL=0 at all?

    2) Page 21, "this can be signaled by returning a 400-series status
       code, such as 410 (Gone)."

This is the only ambiguous status code reference in the standard. What is
the reason for not settling on 404 or 410?

The example of 410 for expiring subscriptions here is different from the
404 mentioned in 7.1 (Page 20), it would be good to make that consistent.

I also have a few editorial comments:

    - Page 3, "Requesting the delivery of events is particularly important
      for the W3C Push API."

It is not explained why it is particularly important. Is this assumed
knowledge of the reader? I would suggest the following addition:

"...for the W3C Push API as the developer may have to request push message
delivery from any number of push services."

    - Page 4, definition of "application server"

Nothing precludes an application from not needing a server side at all. I
don't think we should change the term, but perhaps we can consider
slightly rephrasing the definition as:

"The component of an application that *usually* runs on a server and
requests the delivery of a push message."

    - Page 7, "Confidentiality protection and application server
      authentication MUST be used to ensure that this URI is not disclosed
      to unauthorized recipients (Section 8.3)."

Is it appropriate for the standard to dictate a MUST here when the
distribution method is defined to be application-specific? (I do agree
with the premise.)

    - Page 7, "[subscription sets] can represent a significant efficiency
      improvement for a push service."

There are significant improvements for many types of user agents as well,
so I would suggest rephrasing as "... improvements for push services and
user agents."

    - Page 8, "The push message is included in the body of the request."

While covered by Section 8.1 in the Operational Considerations, given the
strong focus on security and privacy considerations throughout the rest
of the standard I think it would be appropriate to mention the strong
preference for encryption here?

    - Page 11, page 13: s/acknowledgement receipts/delivery receipts/.

    - Page 12, 13: Both "update" and "replace" are used to describe the
      same operation. I don't think that consistently using "replace"
      would change the meaning of this section- could we?

One final thing that I'm on the fence about is that the push service MUST
NOT forward the Urgency value to the user agent. I can see uses, but also
concerns in the scenario of a compromised or malicious push service. Is
this the reason behind the strong language?

Thanks,
Peter

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Jun 2016 12:49:04 +1000

> Have we considered not sending receipts for messages with TTL=0 at all?

I'd be OK with that.  It certainly reduces the cost of TTL=0, which I
think is useful.

PR: https://github.com/webpush-wg/webpush-protocol/pull/91

> 404 mentioned in 7.1 (Page 20), it would be good to make that consistent.

Yes, let's just settle on a single value.

PR: https://github.com/webpush-wg/webpush-protocol/pull/92

> I also have a few editorial comments:

PR: https://github.com/webpush-wg/webpush-protocol/pull/90

Commits in brackets below.

> delivery from any number of push services."

[0bf550e]
"A standardized method of event delivery is particularly important for
the W3C Push API, where application servers might need to use multiple
push services."

> requests the delivery of a push message."

[e022200]

> distribution method is defined to be application-specific? (I do agree

There are no implications for interoperability, but there are for
security.  We do that sort of dodgy MUST-ing all the time when it
comes to securing protocols.  Even when it has interoperability
penalties.  (See RFC 7568, which says "SSLv3 MUST NOT be used.")

> so I would suggest rephrasing as "... improvements for push services and

[90307f9]

> preference for encryption here?

[ee8ca46]
"The ciphertext of the push message is included in the body of the request."

Yes, there are cases where this won't be true because confidentiality
and integrity are provided by other means, but those people can just
say that they are using the double-rot13 cipher.

>     - Page 11, page 13: s/acknowledgement receipts/delivery receipts/.

[51ae2d0]

>       would change the meaning of this section- could we?

[884fc85]
That's a fairly big change.

> this the reason behind the strong language?

The general rule that I've followed here is that anything that could
be from an application server needs to be authenticated when it is
sent to the user agent.  Anything else is clearly from the push
service and can be discarded.

Maybe that's excessive paranoia and I've been spending too much time
with cryptographers lately.  If the information is important it can't
be included in the payload.

---

From: Brian Raymor <[email-masked]>
Date: Wed, 1 Jun 2016 03:42:44 +0000

> Have we considered not sending receipts for messages with TTL=0 at all?

There was some early discussion in https://github.com/webpush-wg/webpush-protocol/issues/24.

There were no major objections at the time. It just felt odd to have a special case for TTL=0 in comparison to TTL=1.