New, more resilient warrant canary

[leafcutterant]

The current warrant canary on Ethereum.org is a simple one, sitting at the bottom of the main page, simply stating what canaries usually state.

While I appreciate that the EF has a canary at all, I'm confident in my opinion that this canary is very lacking compared to how influential an organization it serves.

For this reason, I propose upgrading the canary mechanism to a new, more resilient one. This could manifest in several features, some of which could be implemented independently from other ones. These include:

• Adding regularity to the canary. Define the frequency with which the canary is expected to be updated in healthy circumstances, and explicitly state when the present statement will expire. You could also define an error range into which delays are to be expected to fall.

• Adding/linking to PGP signatures of the canary statement. Signers should have their keys uploaded at least to Keybase.io (Keybase hash their database into the Bitcoin blockchain), and confirm the validity of their key through as many social media accounts as possible. Due to the characteristics of Ethereum's organizational structure, it's not clear to me who should be included among the signers. @vbuterin and Aya comes to my mind first as critical signers, but I think all devs would be welcome, even if not all of those who are interested would be able to sign it all the time (=non-critical signers).

• Include the then-present Ethereum block height and block hash in the canary statement. Proof that the statement didn't exist before x.

• Include the whole statement (with signatures) as transaction data in an Ethereum transaction. Proof that the statement did exist before x+ε. Plus it won't be dependent on server hosting/ICANN/et al. ε obviously won't be non-zero because there would have to be at least one block difference, and parties signing will take a while. There could be an ε defined after which there won't be more waiting for non-critical signers to contribute. The transaction would be sent from an address to itself maintained for this purpose only. The custody of its private key would be shared between critical signers.

• A warrant canary dapp on Ethereum. All of the above sounds like stone age tech compared to the crypto wizardry seen today, so it could be supplanted with a smart-contract based on-chain mechanism. (This is of course work to develop.) Signature submission would be made much easier. I'd still keep PGP signatures as core elements of the canary mechanism, with submission from a known and verified address only being a potential extra.

[evertonfraga]

There's an EIP for that, created by @ligi https://eips.ethereum.org/EIPS/eip-801

[leafcutterant]

Awesome, I was unaware of ligi's work!

EIP-801, once worked out, could be the way to do it in the dapp way.

In the meantime, the rest are the best ideas I've got.

[ligi]

Thanks for bringing this up @leafcutterant and the ping @evertonfraga! Not sure if we should go for a 'workaround' here - unfortunately workarounds tend to stay - would love to see this directly done as a dApp. This could also be great dogfooding. Really like to see use-cases of Ethereum like this apart from money. I was talking to @Souptacular once - and he was open to using 801 on the website.

[leafcutterant]

unfortunately workarounds tend to stay

That's a very good point. Two solutions would also split attention and slow things down.

I'm torn because on one hand, I think we are in critical times and find that the security the current canary can provide is simply insufficient for EF & co., while on the other, the dapp approach is really the way to go. So I would really like to see just some low-tech improvement to the current canary that requires minimum energy (e.g. one PGP signature, 3 months frequency) — but other other than that, I'm all for EIP-801.