# Wall of shame

This document outlines the security and privacy flaws within Status that we've identified and prioritised so far. The goal is to make our users aware of the flaws, and for the community to rally behind resolving these issues one by one.

## List (in order of perceived severity & risk)

**1. Seedphrase stored in database**
An attacker who gets access to our database and our encryption key can decrypt all passphrases for each user, that has not backed up their passphrase yet (in which case the passphrase is no longer stored in our database). The database itself is encrypted but ideally, passwords and seedphrases are something that we should never store on a disk. Other sensitive data, like chat history, should be encrypted and accessible only by the user's password.

**2. Weak certificate checks**
Browser only validates whether SSL certificates are valid or not. Phishing sites can have valid certificates. By comparison, Google Safe Browsing checks suspicious terms from a site against Google servers.

**3. Requires JSON-RPC server to work (SPOF)**
JSON-RPC is the only means by which a user can connect to Ethereum using Status. It's a trusted intermediary, not decentralized. Light client/ULC is required for decentralization.

**4. Spamming the Network**
Our cluster is easy to take down and it's also a single point of failure; service stops if it's attacked.

**5. Replace usage of MixPanel**
MixPanel is against our ethos and holds data about product usage. We can't protect that data. MixPanel has leaked passwords in the past.

Being tracked [here](https://github.com/status-im/status-react/issues/5169)

****6. Easy to DDoS with whisper packages****
Whisper uses PoW as an anti-spam mechanism, but we have had to reduce this for mobile usage, combined with a SNT staking mechanism we can disourage spam further and compensate nodes for having to deal with it.

****7. Perfect forward secrecy****
Forward secrecy = changing keys with every message. In this case, even if a key is compromised, only a small amount of a user's data can be exposed.

Being worked on [here](https://discuss.status.im/t/forward-secrecy/150)

****8. End-to-end Deterministic Builds****
We have no idea if our build and release pipeline is compromised and the binary in distribution channels is legit. Having multiple parties and then sign reduces our attack surface of hacks/bugs in software to at least the version control and source code is a huge win.

Also having this means we will have deterministic builds, which will dramatically reduce the high barrier of entry for developers to setup their environments. Ideally we should get to 1 command builds.

****9. Cluster Single Point of Failure****
Cluster is 'Centralized' thinking and we should be setting our systems up so they are decentralized. Let's not get into a position where we are like Infura (who spends $500k - 1M a month to serve requests) it's unnessary and antithetical to what we're trying to achieve.

****10. Transparancy in Technical Flaws****
Sometimes we convey that our tech is more decentralized or secure than it really is. Lack of technical proofing of communications leads to this problem. *(hence this document!)*

****11. Leak metadata in logs and sometimes data****
Exposing user data in the logs is equivalent to making it available to anyone with some amount of technical ability.

****12. Calls to HTTP(S) Services****
HTTPS GET/POST methods to 3rd parties are insecure. The data submitted to the server can be manipulated, they can be faked, etc. We rely on service to provide some data (e.g. Etherscan), this may be unavoidable at the moment. It'd be better to use something lik Oraclize.it. But we don't give the user an option to enable/disable these features. They should be opt-in

****13. Spam in Chat****
People post irrelevant or malicious messages in public chats, degrading the quality of the experience.

****14. Simple inpersonations****
I can set my display name as "Julien" and use his profile photo, then pretend to be him.

****15. - Hijacking or spoofing of the DNS****
We could use something like DNSCrypt. Granted this is really only an issue when connecting to legacy Web 2.0 infrastructure.

Web 3.0 and ENS mitigates alot of this by design.

****16. - inject web3 w/o asking for permissions****
To enable DApps to make transactions on the network, we inject a standard web3 object into the DOM of any site. This object shows not only that the user is on Ethereum, but can leak more sensitive data related to wallet and transactions as well. EIP 1102 presents a new standard to correct this.

****17. Malicious custom builds****
A user trying to install Status on their machine could be tricked into installing a malicious program instead. Binary hashes and signatures for Status version on chain, a tool could then do a chain lookup for hashes we have signed and compare the hash of the binary the user has.

****18. Same key used across all DApps****
We give DApps users' public addresses. We should 1) not give this data by default, and/or 2) generate a brand new account on the spot until the user gives permission to share their real data.

****19. Reliance on Slack****
Slack is centralized. We're sending them all our chat history.

****20. No guarantees around dark routing****
Requires more Whisper protocol research / applied research

****21. Moderation in Chat****
Spam and offensive content happens, and we have no measures in place to protect public chats from being totally corrupted.

Being worked on [here](https://discuss.status.im/t/visibilty-stake-for-public-chat-room-governance/133/12)

****20. Javascript Dependancies****
We have alot of JS dependencies and have no assurances of manipulation in them, huge attack surface.

****21. Reliance on 3rd Party Distribution Channels****
Basically a Distribution Channel coercision attack, they are inherently permissioned. We don't have much recourse if we want to be available for iOS, maybe some 3rd party could build for Cydia (but not us).

For Android we can be on as many app stores as possible including Apptoide and FDroid

****22. Users leaking seedphrase****
Use error. IF users back up their private phrases, they will screenshot, email, write on paper and throw away, etc. Current UX allows for screenshotting, lazy users (including myself) will do so. This problem compounds with time as the user does not care about the value of their wallet at the beginning when it has nothing in it, but with continued use assets will accumulate and the threat gets larger.

****23. Devp2p encryption broken****
It will be fixed by moving to libp2p in the future, not immediately a problem if we have PFS. To clarify, this is also an issue in Geth which Status is based on.

****24. Single password for signing and logging in****
There is only one password that is used across a users entire Status account. Similarly, the password field is not pasteable so password managers cannot be used. We implictly encourage use of short passwords. Maybe fingerprint auth is more convenient and useful.

****25. Use of github req code signing vs self-host****
We rely on Github to host our code repositories

****26. Transactions are public****
All transactions are visible on the Ethereum public blockchain. Although anonymized, they provide insight into origin, destination and amount of funds.

****27. Single legal entity****
We rely on legal entities in government jurisdictions to function as an organisation. This can be mitigated when we ascened to a DAO

****28. Clearing and exporting chat****
Chats are unable to be cleared or exported. This also relates to destructable messages

****29. Requires internet to operate****
In hostile urban environments, like internet shutdowns, having adhoc wifi would allow local meshnets to appear in protests.