status-im / specs

Specifications for Status clients.
https://specs.status.im/
MIT License
14 stars 14 forks source link

Push notification server specs #139

Closed cammellos closed 4 years ago

cammellos commented 4 years ago

Specs for the push notification server. Since this is a quite a large document, I would do review in rounds,

First, please provide feedback on the actual protocol, methods etc

After the first phase we can move onto formatting/sections etc and take it from there.

3esmit commented 4 years ago

I think that is possible to implement push notifications without compromising privacy. It's not necessary to inform user public_key to the server, client can inform anything it wants and contacts can use an additional message just for notifications for that particular user, assuming that the sender knows the notification topic.


Current proposal. public key as notification topics:

Advantages: Simple Disadvantages: not private, vulnerable to notification flood


Proposal 1, ephemeral notification topics (contacts only):

Advantages: Safe against flooding, very private Disadvantages: Complex, less scalable,


Proposal 2, public fixed notification topics:

Advantages: Simple, somewhat private Disadvantages: Vulnerable to notification flood


Proposal 3, derived notifications topics:

Advantages: Simple, somewhat private Disadvantages: less scalable

oskarth commented 4 years ago

@decanus I think OP explicitly asked for non formatting PR comments at this stage. Do you have any feedback on the actual meat of the spec?

oskarth commented 4 years ago

@status-im/security-internal probably need to have a look at this, added @rajeevgopalakrishna as that's the only username I know except for Corey :P

cammellos commented 4 years ago

@3esmit We are not implementing notifications only for contacts, if that was the case it would be much simpler. https://discuss.status.im/t/decentralized-push-notifications-for-ios/1718/3?u=cammellos So 1 & 3 don't fit the requirements.

Proposal 2 is already incorporated. If you don't care about spam, you can advertise the token on your contact code topic (derived from your public key), and user can use the token to send you push notifications, without disclosing the identity. If that's the case, you can just use an ephemeral key to register with the push notification server, so you won't disclose your identity.

cammellos commented 4 years ago

@oskarth replied with some clarifications and addressed the feedback, thanks

decanus commented 4 years ago

I think it probably makes sense to add what metadata is leaked etc to a Security Considerations section, you have this answered elsewhere but I think it probably belongs here. wdyt @oskarth

cammellos commented 4 years ago

@decanus ready to be reviewed again

cammellos commented 4 years ago

@decanus addressed feedback, thanks

oskarth commented 4 years ago

Can we please do follow up discussions in separate issues? A bit difficult to follow discussion once a PR has been merged already.

cammellos commented 4 years ago

I have opened a PR already , we can continue there https://github.com/status-im/specs/pull/143