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

[Martin Thomson <[e-mail]>]

On 1 June 2016 at 05:40, Peter Beverloo <[e-mail]> wrote:
> 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?

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

>     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.

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.

>     - 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."

[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."

>     - 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."

[e022200]

>     - 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.)

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.")

>     - 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."

[90307f9]

>     - 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?

[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]

>     - 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?

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

> 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?

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.