Book of Shame and Opportunity, Prague edition (part 1/2)
This mini-book is a result of extensive conversations in the Principles Seminar.
Each item here is a a bug and an opportunity in Status. It represents how we are
falling short of one, or several, principles. Each item has been put under a
principles header, but that doesn’t mean it belongs to that principle alone.
Most items here violate several principles.
Anyone can vote on these problems in terms of how important they think they are.
At the end, we’ll have a list of problems and opportunities that we as an
organization and community agreed on. This can then inform goal setting and
planning, and generally get us on the same page as to where we need to improve.
We’ll do SNT voting during the Offsite. Please read/skim through this list so
you have have some idea of what each item refers to. This maximizes the impact
your vote has and will have a direct impact on what Status achieve over the
coming months, and longer.
As an example, in Basel we voted on importance of ~30 items and ended up
prioritizing top 10. This substantially impacted what we focused on for our
OKRs, and we made solid progress on most of these items.
How to contribute
- Read through this list to becoming better informed.
- Give feedback and ask questions to improve the list as a whole.
- During the offsite, vote on the things that are important to you.
- Help improve presentation of these (ex: WoS graphic illustration)
Examples of useful feedback:
- questions of clarification
- refactor title, principles violation or body text to be more concise,
inclusive or correct - (additional items completely missed)
Preferably please edit in the HackMD directly: Book of Shame and opportunity, Prague edition - CodiMD
On the text
There’s a lot of material here, and I’ve done my best to capture it accurately,
without getting too lost in the weeds. Thank you everyone who contributed to
expanding our brainstorming notes.
There’s likely to be a lot of duplication, errors, things that could be
categorised a better way, stuff that was misrepresented or lost.
I’ve tried to make it evenly distributed, so each item is roughly scannable on
its own. Don’t pay too much attention to what principle header a specific item
falls under (but please modify the violation list if it is missing something).
I’ve also used a self-imposed constraint of 100 items and <10 per header, to
make it more palatable for voting.
Outline
Outline of just titles, please see below for more details on each.
I. Liberty
- LIB-1. Don’t know if we actually maximize freedoms.
- LIB-2. Complexity of crypto limits economic freedom.
- LIB-3. Lack of plausible deniability of using Status.
- LIB-4. Core contributor salary model not freedom maximizing
- LIB-5. Lack of different cultural perspectives in shaping our tools
- LIB-6. Risk being a non-partisan platform
- LIB-7. Allowing oppressive regimes to use Status.
II. Censorship-resistance
- CEN-1. Cluster Single Point of Failure
- CEN-2. Reliance on 3rd Party Distribution Channels
- CEN-3. Assumes Ethereum network is operational.
- CEN-4. Requires Internet to operate.
- CEN-5. Lack of understanding of Whisper and its limits.
- CEN-6. Non-standard ports makes ISP blocking trivial
- CEN-7. NAT traversal isn’t implemented for Desktop to be bootnodes.
- CEN-8. Reliance on GitHub as a single point of failure (JS packages)
III. Security
- SEC-1. Not enough time allocated to validating risk mitigation
- SEC-2. We don’t have a risk profile across the company.
- SEC-3. We don’t have any incident response procedures.
- SEC-4. Lacking explicit security guarantees and threat models.
- SEC-5. Exposed to Web2.0 leftover security gaps.
- SEC-6. We don’t have reproducible builds or signed releases.
- SEC-7. Big attack surface through dependencies
- SEC-8. Single password for signing and logging in
- SEC-9. Simple to impersonate someone
IV. Privacy
- PRI-1. Can’t be anonymous in public with contacts
- PRI-2. Failing to balance transparency and privacy
- PRI-3. Relying on 3rd party service in our source code.
- PRI-4. Reliance on single key means trivial linkability
- PRI-5. We don’t support private transactions.
- PRI-6. Core contributors can’t choose to be anonymous.
- PRI-7. Lack of destructible messages
- PRI-8. Perfect forward secrecy [work in progress]
V. Transparency
- TRA-1. Lack of insight and control into what is collected, communicated and leaked
- TRA-2. Transparancy in Technical Flaws
- TRA-3. Marketing: Community not involved enough in decision making.
- TRA-4. Lack of easily discoverable decision record artifacts.
- TRA-5. Lack of public financial information.
- TRA-6. Lack of defining transparency in terms of how it helps achieve our goals.
- TRA-7. Not clear how to get involved as a potential contributor.
VI. Openness
- OPE-1. Reliance on closed and permissioned systems.
- OPE-2. Closed financial info and lack of roadmap.
- OPE-3. No consensus on how to balance security and openness.
- OPE-4. License situation across the board is unclear.
- OPE-5. Status Network is a non-rival good, not a public good.
- OPE-6. Lack of open protocol.
- OPE-7. App not available publicly in the App Store.
VII. Decentralization
- DEC-1. Centralized decision making re hiring/salary/headcount.
- DEC-2. OSS project but only core contributors contributing.
- DEC-3. We are a hybrid organization with downsides of both.
- DEC-4. Requires JSON-RPC server to work (SPOF) [in progress]
- DEC-5. Zero people running Status nodes.
- DEC-6. We run specialized nodes (mailserver).
- DEC-7. Reliance on small number of fiat bank accounts.
- DEC-8. Organization design is somewhat centralized.
- DEC-9. We don’t have a strong open source community (dependence on CCs).
VIII. Inclusivity
- INC-1. Status doesn’t run well on old cheap devices/OS.
- INC-2. Difficult to contribute to Status.
- INC-3. Lack of educational content with community-driven input.
- INC-4. Lack of non-english resources.
- INC-5. Lack of proper contributor and user metrics.
- INC-6. App barely useful enough for even us to rely on it.
- INC-7. Hard to get SNT and ETH in the first place.
- INC-8. Dogmatic design system.
- INC-9. Users leaking seedphrase
Continuance
- CON-1. Lack of work on protocol and app done by non core contributors.
- CON-2. Currently there is no incentive to run Status network nodes.
- CON-3. Most contributions to Status protocol and app from core contributors
- CON-4. Hardcoded public chat and Dapp list
- CON-5. Status project require funding from the Status company.
- CON-6. Status is a centralized company.
- CON-7. No incentive to run Whisper or Status nodes.
- CON-8. Vast majority of our work is never incentivized in open form.
- CON-9. Reliance on a single legal entity.
Resourcefulness
- RES-1. We are a hybrid organization with downsides of both.
- RES-2. Not doing MVPs in a way that serves our OKRs.
- RES-3. Lack governance tools to make financial decisions.
- RES-4. Lack of analysis in core economic questions.
- RES-5. Can’t be resourceful without knowing what building.
- RES-6. We don’t understand what resources we have.
- RES-7. We lack a financial mindfulness mindset.
- RES-8. We don’t security audit on-boarded core contributors.
- RES-9. Even as CC not clear where to make impact and find recent state of effort.
I. Liberty
We believe in the sovereignty of individuals. As a platform that stands for
the cause of personal liberty, we aim to maximize social, political, and
economic freedoms. This includes being coercion-resistant.
LIB-1. Don’t know if we actually maximize freedoms.
Principles violation
liberty
Details
Don’t have mechanisms to carry it out, how do we even know if we maximize these
freedoms? Mention coercion resistance but don’t know if we tested this. A lot to
do to validate these things, to make sure living not just saying it.
LIB-2. Complexity of crypto limits economic freedom.
Principles violation
liberty, inclusivity
Details
Economic freedom: crypto technically complex, more difficult to use crypto, not
providing that economic freedom to people.
It has to be much simpler.
LIB-3. Lack of plausible deniability of using Status.
Principles violation
liberty, security
Details
Plausible deniability we should have, in general. Only free to use Status in
some places if we have this.
LIB-4. Core contributor salary model not freedom maximizing
Principles violation
liberty
Details
Economic liberty may not be there with employee model, with DAO more flexible
contribution, right now monthly retainer, can go further.
LIB-5. Lack of different cultural perspectives in shaping our tools
Principles violation
liberty
Details
Ensure tools appropriate for skill set and culture to build and say what they
want.
Ensuring people have right tools for skill set and culture to build and say what
they want. Important to honor where people are at culturally at in world, what
conditions, resources etc have. Give good understanding for scaling so everyone
can really use them.
We haven’t taken into account different cultural perspectives in shaping these
tools. E.g how often test in Iraq/Gaza/Mogdasihu/etc.
LIB-6. Risk being a non-partisan platform
Principles violation
liberty, openness
Details
Largely hypothetical one as presented, but presents itself in a few ways.
Studio: people should be able to choose various frameworks, embark etc,
non-partisan platform, give people as much liberty as possible. Aspirational not
to get on wall of shame
Example from ENS: Allowing non stateofus.eth to give user’s choice.
Related: open protcol
LIB-7. Allowing oppressive regimes to use Status.
Principles violation
liberty
Details
Violation would be to let oppressive regime to use Status to compromise liberty
for other people.
Interesting one, because something similar came up in Basel raw data as well
(Terrorists can use Status) and was downvoted by the vast majority people.
Leaving it in as it is instructive - there are many wrong solutions to this
problem.
Related: See “malicious custom builds” item.
II. Censorship-resistance
We enable free flow of information. No content is under surveillance. We abide
by the cryptoeconomic design principle of censorship resistance. Even
stronger, Status is an agnostic platform for information.
CEN-1. Cluster Single Point of Failure
Principles violation
decentralization, privacy, censorship-resistance, openness, inclusivity
Details
Reliance on cluster.
Clients require a cluster of servers to work, including for offline messaging
and initial connectivity, instead of nodes ran by anyone in the network. Can be
censored by governments or ISPs.
Status nodes with offline inboxing, etc, should be able to run by anyone.
Evidence of success would be us shutting cluster down and things still work
smoothly. We may still choose to operate it for robustness/general network
health issues, but it shouldn’t be a SPOF.
Related: Spamming the network, item 4 in Basel WoS.
Being partially tracked here:
Related: Cluster Single Point of Failure, item 49in Basel WoS.
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.
Being tracked here: Cluster Single Point of Failure · Issue #5592 · status-im/status-mobile · GitHub
Additionally: Lack of path for getting rid of cluster, not clearly outlined.
Having a clear implementation path will make it easier for others to join and
give confidence to wind down the cluster when the time comes.
Success looks like? Clear implementation path articulated
CEN-2. Reliance on 3rd Party Distribution Channels
Principles violation
decentralization, privacy, censorship-resistance, security
Details
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
Users require to use propertary software to install Status.
Related: Provide alternatives to installation (p2p file sharing?) and/or
participation (status web?)
CEN-3. Assumes Ethereum network is operational.
Principles violation
decentralization, censorship-resistance
Details
Status relies on Ethereum network being up and running. If something goes wrong
with it, this means Status communication and transactions are impacted. Compare
with e.g. SSB design, or direct in-person trade.
CEN-4. Requires Internet to operate.
Principles violation
decentralization, censorship-resistance, openness
Details
Status requires an internet connection, which is available only in developed
countries. Usually requires a cost to internet, which might not be affordable to
everyone. ISPs are a centralization, therefore is a vector of censorship using
block all firewall policy.
This one was identified in Basel already as item 29.
In hostile urban environments, like internet shutdowns, having adhoc wifi would
allow local meshnets to appear in protests.
CEN-5. Lack of understanding of Whisper and its limits.
Principles violation
censorship-resistance, inclusivity, decentralization, security, privacy
Details
Whisper is at the core of how Status currently works, and we don’t understand
the limits of it. Example:
- Does it scale to 1M users? 2) What is the cost to DDoS the network? 3) What
darkness guarantees does it actually provide?
Related: Whisper vulnerable to DDoS [in progress] This one was identified in
Basel already as item 6. It’s in progress with rate limiting etc, but we still
havent’t repented yet. Additionally, we don’t have an understanding of cost of
attack (see Breaking Whisper).
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.
Being tracked here: Cluster DDoS protection · Issue #5589 · status-im/status-mobile · GitHub
CEN-6. Non-standard ports makes ISP blocking trivial
Principles violation
censorship-resistance
Details
Technical detail make ISP blocking easier.
Solution: use random ports, let user choose port
CEN-7. NAT traversal isn’t implemented for Desktop to be bootnodes.
Principles violation
decentralization, censorship-resistance
Details
Many end users are behind gateways, thus requiring NAT traversal to work
effectively as a bootnode.
CEN-8. Reliance on GitHub as a single point of failure (JS packages)
Principles violation
decentralization, censorship-resistance
Details
Github is a single point of failure. This includes things like JS packages.
Solution: Use multiple sourcecode hosting, host in IPFS.
You made it 25% through the text, nice one 
Here’s a cookie!
III. Security
We don’t compromise on security when building features. We use
state-of-the-art technologies, and research new security methods and
technologies to make strong security guarantees.
SEC-1. Not enough time allocated to validating risk mitigations.
Principles violation
security, continuance
Details
We are not spending enough time thinking about the risks of new features, PRs,
our products, etc. When we do implement a fix something, it is not being
validated enough to ensure the fix worked appropriately.
Success: Regular STRIDE sessions, security champions in every team, educational
material on how to think adversarially, PR checklists, post mortems
SEC-2. We don’t have a risk profile across the company.
Principles violation
security, transparency, continuance, resourcefulness
Details
We should understand and evaluate all risks across the company, and have a
strong idea of what needs to be done to bolster them if they can be. This is a
continued list that always gets better (hopefully) as we address items and
increase practices and procedures.
Success: Understandable state of risks across the company
SEC-3. We don’t have any incident response procedures.
Principles violation
security, transparency, continuance, resourcefulness
Details
If something goes wrong, there is no place to go to figure out how to mitigate
it. This is mitigated by having known places to go in case anything happens, as
well as formally outlines policies for variously known potential issues.
Success: having an incident response team and easily findable procedures.
This includes security incidents, but also availabilty etc issues. They may or
may not be dealt with separately.
SEC-4. Lacking explicit security guarantees and threat models.
Principles violation
security, transparency, privacy
Details
We aren’t explicit about our guarantees around darkness (push notifications,
web2 services, mail services, lack of formal whisper math, etc) and other
security guarantes. We also lack explicit threat models.
Success: Formal specifications on our protocols and services we use, studies
about what strong guarantees we have need to be had if they don’t already exist,
explicitly listed threat models.
Also see Whisper understanding limits item for related, but slightly different,
problem.
This one was partially identified in Basel already as item 20. Requires more
Whisper protocol research / applied research.
Also, for example of guarantee being broken: Devp2p encryption broken. This one
was identified in Basel already as item 23. 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.
SEC-5. Exposed to Web2.0 leftover security gaps.
Principles violation
security
Details
Hijacking or spoofing of the DNS: This one was identified in Basel already as
item 15.
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.
Calls to HTTP(S) Services: This one was identified in Basel already as item 12.
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
SSL certificate pinning:
Principles
security
Details
Lack of clear understanding and rationale of dependencies, leading to a big and
haphazard attack surface area. See
Sensitive data is shown in TF logs · Issue #5567 · status-im/status-mobile · GitHub for example.
SEC-6. We don’t have reproducible builds or signed releases.
Principles violation
security, transparency, decentralization
Details
When you build Status from the source, it should give the same binary wherever
you do it. This means that if you hash it, it produces the same hash. This
allows people to build it themselves, and guarantee that the binary we are
building is built from the source (so we aren’t adding or changing anything) as
well as allow people to make sure they are building it themselves correctly, and
not rely on our official sources to get Status.
This means we are vulnerable to this type of attack:
< arg$outer.$$outer$2.address$1 = a.toChecksumString__T();
---
> arg$outer.$$outer$2.address$1 = "0xC33B16198DD9FB3bB342d8119694f94aDfcdca23";
That leads to direct loss of fund. (https://www.reddit.com/r/ledgerwallet/comments/9482b4/issue_in_ledger_wallet_ethereum_chrome_app/e3jlb5d/ 3)
Solving this item would be a pre-requisite, but possibly not enough (require
actual inspection of sensitive parts of the code).
This one was identified in Basel already.
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.
Being worked on here: End-to-end Deterministic Builds · Issue #5587 · status-im/status-mobile · GitHub
(better home probably exists)
We also want multiparty signature.
As a subset: sign releases.
If we want people to have guarantees around Status, they should have a way of
knowing they’re getting a good version of the software, and that they are
downloading the correct one with a known Status public key. This can also be
used to bolster confidence until we get reproducible builds.
Success: signing releases (see veracrypt download page for example)
Also: risk of Malicious custom builds: This one was identified in Basel already.
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.
This also relates to oppressive regimes and agents.
SEC-7. Big attack surface through dependencies
Principles
security, resourcefulness
Details
Lack of general inventory and review of dependencies.
Lack of clear understanding and rationale of dependencies, leading to a big and
haphazard attack surface area. See
Sensitive data is shown in TF logs · Issue #5567 · status-im/status-mobile · GitHub for example.
This one was partly identified in Basel already as item 20.
Javascript Dependencies. We have alot of JS dependencies and have no assurances
of manipulation in them, huge attack surface.
This also simplifies reproducible builds effort.
SEC-8. Single password for signing and logging in
Principles violation
security
Details
This one was identified in Basel already as item 24.
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.
SEC-9. Simple to impersonate someone
Principles violation
security, inclusivity
Details
This one was identified in Basel already.
I can set my display name as “Julien” and use his profile photo, then pretend to
be him.
IV. Privacy
Privacy is the power to selectively reveal oneself to the world. For us, it’s
essential to protect privacy in both communications and transactions, as well
as being a pseudo-anonymous platform. Additionally, we strive to provide the
right of total anonymity.
PRI-1. Can’t be anonymous in public with contacts
Principles violation
transparency, privacy, security
Details
When you add contacts, it shows the anonymous name next to the chosen name,
which then renders the anonymous name useless if someone wants to be
pseudonymous / anonymous.
Unclear to what extent this is a problem. Separated pseudonymous names from
public profile account? #moot
PRI-2. Failing to balance transparency and privacy
Principles violation
privacy, transparency, inclusivity, openness
Details
Due to lack of policy and tools.
Need policy and tools for balancing balancing transparency and privacy in a few
areas:
- Incubate: respect projects desire for privacy of fundraising, etc.
Additionally for Incubate is a lack of roadmap for how to to involve community.
Not yet clear how Incubate can implement full transparency to the community,
especially given it could conflict with the privacy of other groups (that apply
to Incubate). Need a roadmap.
- Hiring privacy for individuals with public channels.
Allow for individual solutions where teams can be private, at least at
application stage.
- Finance: Individual core contributor and salary
Transition period to DAO unclear with respect to salary transparency. Making
salaries transparent is a delicate issue. Don’t see a roadmap to how we get to
the DAO public. There are privacy concerns about the level of transpatency a DAO
requires.
Success? A clear vision/roadmap for transitioning to DAO, including details on
how we’ll handle privacy of individuals.
-
Lack of ability to balance privacy vs tailored experence in marketing.
Successful marketing depends on tools like segmentation/remarketing/tracking
etc, which seemingly makes it difficult to respect people’s privacy. We lack a
policy or framework for how to deal with this. -
Open information sharing leading to core contributor information leaking. We
haven’t confirmed that all contributors want to be listed publicly on
Introduction - Status Contributors Guide
This also extends to things like sharing principles signatures publicly. It
relates to previous items regarding what information is marked as for public or
not.
PRI-3. Relying on 3rd party service in our source code.
Principles violation
privacy, security
Details
Status should minimize its reliance on any form of 3rd party service.
PRI-4. Reliance on single key means trivial linkability
Principles violation
privacy, inclusivity
Details
Identity and funds tightly coupled with a single public key.
Possiblity to know how much funds contact have. If you add someone as a contact,
you can see get access to their wallet address and see how much funds they have.
Related: don’t allow for multiple wallet addresses.
Address re-use is a big problem from a privacy POV due to linkability. This is
also a problem if you want to segregate your funds, like personal vs business.
Related: Same key used across all DApps. This one was identified in Basel
already as item 18.
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.
PRI-5. We don’t support private transactions.
Principles violation
privacy
Details
Anyone can see anyone’s private transactions, unlike something like cash. This
means one “money” can have different value depending on who touched it, as well
as lead to dire consequences for exposed individuals using money for sensitive
things. With ZK-SN/(T)ARK this can be remedied. Also see ZCash and Monero.
This one was identified in Basel already.
All transactions are visible on the Ethereum public blockchain. Although
anonymized, they provide insight into origin, destination and amount of funds.
PRI-6. Core contributors can’t choose to be anonymous.
Principles violation
privacy, inclusivity
Details
Due to how participation and compensation currently works (contracts/Google
accounts), it is hard for core contributors to be anonymous. We should allow for
a Satoshi to be a core contributor.
PRI-7. Lack of destructible messages
Principles violation
privacy, inclusivity
Details
See Signal for example.
This one was partly identified in Basel already as item 28.
Chats are unable to be cleared or exported. Actually now they partly can be.
PRI-8. Perfect forward secrecy [work in progress]
Principles violation
security, privacy
Details
This one was identified in Basel already. Substantial progress has been made.
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: Perfect Forward Secrecy (PFS) · Issue #5586 · status-im/status-mobile · GitHub
(better home probably exists)
(See Part 2 here Status.app for continuation 
)