This is our wall of shame. The things we know we shouldn't be doing, but for whatever reason we are. The list came from a small group of us who met up in Basel, musing about what security should look like at Status, and what principles we all stand behind.

That's their origin, but that's not their end. They've been at the back of our mind for quite some time now, but usually implicit in a tiny number of brains as opposed to explicit for an open set of brains. This is our way of being transparent about our faults, so we can all help solve this together. It's even part of our Core OKRs to address the top 10 of these in the next few months. Wish us luck. Even better, come help address these with code, ideas and discussions. We pay bounties and don't bite :)

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

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

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

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.

Status Technikon