Emergency stop for apps

[izqui]

Option 1

Allow app developers to selfdestruct an app contract (the deployed library that proxies rely on). This would force all organizations using the app to upgrade (kernel.setAppCode(...)) to a new version (with the vulnerability fixed) to keep on using it.

Reference @3esmit 3esmit/Hive-Democracy@2d5641b

Problem: organizations might remove the ability to update apps in order to guarantee immutability. In that case a destructed app could be fatal, because selfdestructing a contract is irreversible.

Something to keep in mind is that an app developer can unilaterally implement this option in their app.

Option 2

Implement a list at the network level of contracts that have been emergency stopped. In order to add a contract to the list, a significant amount of tokens are staked to immediately pause the contract for the entire network. A period would follow in which more stakeholders would decide whether it was a real threat (and reward the submitter) or if it was just a spam attack (slashing the deposit and removing the contract from the stopped contracts list).

Problem: would require to extend the Kernel so it could fail before returning an stopped app address.

[onbjerg]

I like option 2 a lot better.

[izqui]

I like option 2 better too. If the incentives are set up correctly it could work as a live bug bounty program.

[lkngtn]

I think option 2 is very promising, though I think that this must be an opt-in service not a requirement for using aragon core. It can be on by default if we are providing templates, but it should be trivial to remove if organizations prefer to assess and manage application security themselves.

Perhaps something like this would work:

• Deployed Kernel subscribes to the frozen applications list
• If an application is frozen in an org, a user with appropriate permissions can selectively override this behavior for a specific application. (e.g. temporarily unfreeze to retrieve funds, then disable again / make a decision that they have evaluated the risk but want to use that particular application anyways)
• User can disable kernel subscription entirely, in which case they still might monitor the list off-chain and take action to stop an app if they think its necessary. (e.g. there is a centralized service, perhaps run by the user themselves that monitors the list as well as their org and sends a text/email alert)

[3esmit]

I detailed the option 1 here: status-im/swarms#25

[onbjerg]

@lkngtn The subscription to the list (at least as I understood it when we talked about it) would be a part of the network, so it is already opt-in. I do agree that organisations should have the option to override the list, though.