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

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

The issue names no source files, tests, or entry points. Start by reviewing ZeroNet's publishing, versioning, and publisher-key behavior, then define whether a newer content-removed version should centrally delete or censor an existing Zite and what protections are required.

Escrito por el modelo de indexación a partir del texto del issue.