Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

push messages - do they need to be encrypted? #110

Closed
brong opened this issue Jul 17, 2017 · 0 comments
Closed

push messages - do they need to be encrypted? #110

brong opened this issue Jul 17, 2017 · 0 comments

Comments

@brong
Copy link
Member

brong commented Jul 17, 2017

This is one of the cans of worms. If we're pushing through a third party which can theoretically see the content of the message, do we need to encrypt our payloads?

Pro of encrypting:

  • better security for payload, interception can't see which datatype is being changed or "rate of change of state string" if it's a counter - this is a metadata leak
  • more likely to be accepted by IETF security people

Con:

  • adds complexity of spec
  • adds complexity of implementation
  • takes more CPU on receiving device (potentially enough that you hit background processing limits?)
neilj added a commit that referenced this issue Sep 11, 2017
And add optional support for encryption, resolves #110
neilj added a commit that referenced this issue Oct 2, 2017
* Add optional support for encryption, resolves #110
* Document that clients should use the ping event to help detect when buffering
  proxies are interfering. Resolves #108.

The semantic changes can be summarised as:

Web Hooks
* (get|set)PushCallback have been renamed (get|set)PushSubscription, aligning
  with the terminology in RFC8030 and take a PushSubscription object as an
  argument/response rather than just a URL.
* The PushSubscription can have an expires time and encryption keys.
* Push callbacks no longer have `X-JMAP-EventType`/`X-JMAP-User` headers, as
  they are not needed.
* Push callbacks MUST have a `TTL` header, and MAY have `Urgency` and/or
  `Topic` headers, as specified in section 5 of [@!RFC8030].

EventSource
* Clients can now choose the ping time by adding a query parameter to the event
  source URL.
* Clients can now add a query parameter which causes the server to close the
  HTTP response after pushing a state change (long-polling mode).
@neilj neilj closed this as completed in 337fcdf Oct 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant