< ( What's this? A user doing something I don't agree with? I think I shall ban them, and silence them forever! )( Ha ha, that's what you think! I have sent my private key to four other servers, so I will not be silenced! ) >< ( Also I'll reveal their private key so anyone can make them post loads of gore porn. )( ....shit ) >
and extremely adept at how Hubzilla and its security works...
I am not sure how Hubzilla handles it now, but there is a way to "Drop" one of your clones in Settings > Manage Channel Locations.
Or do you permanently have a key forever?
Or, you could just reissue the keys, and the bad clone doesn't have a valid key anymore.
Any server. Any product. Any operating system. Any protocol.
Wrong. See revocation or blockchain fork for instance.
Unless you are breaking the law or violating the terms of service, you have little to fear from a reputable web hosting company.
The reality in the fediverse it has a different nature. There are not many hosting companies but a lot of private people which run a Server and offer services and most often there is no contract and no terms of services.
"The hub itself might not have a terms of service, but their web host does, in that case."
hmm.. so you mean if I leak a private key as an Admin of a hub i run on a shared host - the terms of service of the web host come into play ?
can you show me that parts of the "terms of service" which could settle this ?
Illegal ActivityCustomer may only use DreamHost Web Hosting's Server for lawful purpose. ... Also, using DreamHost's servers or network to conspire to commit or support the commission of illegal activities is forbidden as well.
Spoofing/ImpersonationUsage of the DreamHost network to impersonate another person or entity, be it through Email, Internet Forums, or any other means, is strictly prohibited. This includes spoofing email or network packet headers whether or not it is done for malicious purposes.
HackingThe usage of DreamHost's computer systems or network to access any system, service, or network without the owner's consent is expressly forbidden.
A violation of any of these will get your account terminated.
Ok - first your identity gets ruined - than you have to prove to the webhoster that the admin of a web space did seriously harm to you - if you are successful with your claim the admin has to move the stuff to an other webhoster but your identity is still ruined
It appears dropping a clone doesn't work if the clone is still live.
right the clones still exist... maybe it takes some time till dropping takes place
than you have to prove to the webhoster that the admin of a web space did seriously harm to you
this prove will not be that easy if you have cloned your channel to more than just one hub.
This comparison is useless: those are centralised systems...You should compare for example with elasticsearch cluster (does a corrupted slave could affect master? No), and other decentralised systems.
To create an identity there should be also an extra privat key needed which is just stored locally on your PC. Every time you want to create a new clone this key would be needed as well. This would insure that nobody but just your can create and clone your identity
The administrator of a system, by their very nature, has access to the system... including the data you put on that system about your identity.
You are quite confused....The admin of a slave server has only access to the slave data. If he is not admin to master server, he can't corrupt the data on the master server. Stop reducing the problem to only testcase you understand, and accept that more advanced solutions exists...
Just because I said a rogue admin can corrupt data does not mean I think nothing can be done about it. There are techniques that you can use to reverse the damage and save the identity. But during the attack itself, because all copies of a channel are instantly mirrored, the bad data will propagate.
Maybe this should have been explained somewhere... that you should only clone your identity on hubs you trust. Because by cloning your identity, you are basically adding another administrator that has access to your identity.
you should only clone your identity on hubs you trust
Another interesting solution is adding a Web Authentication API ( #^https://webauthn.guide/ ) to Hubzilla, and requiring device authentication before allowing a clone (if enabled by the user).
Maybe I'm wrong, but I remember that @Mike Macgirvin point of view is that no binding to hardware should be built into the Hubzilla framework.