HelloZeroNet / HelloZeroNet/ZeroNet

Central Deletion of Zites by Publishing a new Version of the Zite that has its Content Removed

オープン
#1,288 コメント 1 件 リアクション 1 件 担当者 0 名 GitHub で見る
主要言語
JavaScript
スター
18.8k
フォーク
2.3k
PR マージ指標
30日以内にマージされた PR はありません

説明

My current bug report is not so much of a bug report, but
rather a halve-question and it's inspired from a discussion at

http://127.0.0.1:43110/Talk.ZeroNetwork.bit/?Topic:1518467842_1BGWexcsjvPpnPZVmmioZvwBBQ3WoZsWuQ/What+happens+if+the+owner+of+a+Zite+deletes+its+contents

I just came to an idea that given that the ZeroNet does not act like
a version control system(or does it? I do not know yet), one way to
centrally delete/censor a zite is to raid/rob/steal the secret key of the
zite publisher's ID and then publish a newer version of the zite
that has the censorable content removed/edited/modified.

With Windows users and automated mass malware("viruses", "antivirus software", etc.)
there is probably even no need to raid the author's servers. Even if
the server resides at some place other than the location of the author's
workstation, the censors can first break/hack into the author's workstation
and then jump to the ZeroNet server from there by using the very same
connection/tunnel/keys that the zite author itself uses. With the threat
that the author of the censorable zite has implemented emergency
key destruction, a physical raid to get access to the author's workstation
would risk triggering the emergency key destruction, but a secret
penetration hack might avoid triggering the key destruction.

https://www.youtube.com/watch?v=Fi6016ne1YM

http://127.0.0.1:43110/15qHfGtzeqZb2PJiwhtYyV3sARx8zzddMG/website_bonnet/various_files/299_GAMMA-201110-FinFisher_Product_Portfolio-en.pdf

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

この issue では、ソースファイル、テスト、エントリーポイントが指定されていません。まず ZeroNet の公開、バージョニング、publisher-key の動作を確認し、そのうえで、コンテンツが削除された新しいバージョンによって既存の Zite を中央で削除または検閲すべきか、またどのような保護が必要かを定義してください。

索引モデルが issue の本文から書いたものです。

評価

領域
distributed-systems, security
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
15/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。