status-im
/
status-go
mirror of https://github.com/status-im/status-go.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Updated Whisper Push Notifications (markdown)

Victor Farazdagi 2017-04-12 19:03:08 +03:00
parent 1b1fc61d7a
commit ab26e700d3
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Whisper-Push-Notifications.md

@ -378,14 +378,16 @@ If you run that page in gist, you should see sth like this:
# Important Questions (with answers!)
### Question: If Discovery Protocol's SymKey is publicly known, what will happen if some attacker just forks `status-go` repo, and responds to discovery request?
### If Discovery Protocol's SymKey is publicly known, what will happen if some attacker just forks `status-go` repo, and responds to discovery request?
It is crucial to understand what might be exposed:
- clients' public keys
- clients' device IDs
- some extra info which you pass in notifications
So, public keys exposure shouldn't be a huge problem. When it comes to device IDs, can attacker use them to send unwanted/spam notifications? Well, since those device IDs were generated for a given FCM app, they are useless to attacker unless authorization key to that app is known (and it isn't). Finally, to make sure we do not over-expose ourselves, make sure that you do not include too much of internal information in notifications - then even if attacker can get those, not much will be gained (although, we must warn users that by enabling notifications they potentially enable 3rd party to track the fact of communication - **not the content of it of course**)
So, public keys exposure shouldn't be a huge problem. When it comes to device IDs, can attacker use them to send unwanted/spam notifications? Well, since those device IDs were generated for a given FCM app, they are useless to attacker unless authorization key to that app is known (and it isn't). Finally, to make sure we do not over-expose ourselves, make sure that you do not include too much of internal information in notifications - then even if attacker can get those, not much will be gained (although, we must warn users that by enabling notifications they potentially enable 3rd party to track the fact of communication - **not the content of it of course**).
Now, on incentives: we must make sure that economic rewards are such that it is more interesting for 3rd party to provide proper service than to involve in malicious acts.