WisTex Network - WisTex Network

Thu, 26 May 2022 05:05:29 -0400

RockyIII wrote the following post Thu, 26 May 2022 05:05:23 -0400

Can a hub admin ruin an identity ??

nomadic identity depend on hubs which are depending on admins.

< ( 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 ) >

https://mstdn.io/@cy/108364336181616784

Can an admin ruin a channel identity by not just ban a channel from a hub but by also publishing the privat Key of an identity - which he finds easily in the DB with two clicks ?

show all 46 comments

Hans van Zijst

Thu, 26 May 2022 05:12:27 -0400

Interesting question :thinking:

Scott M. Stolz

Thu, 26 May 2022 14:48:45 -0400

They'd have to be particularly malicious and extremely adept at how Hubzilla and its security works... but it is not impossible if they do it fast enough.

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.

I am not sure what that does behind the scenes though.

RockyIII

Fri, 27 May 2022 04:31:03 -0400

@Scott M. Stolz @Hans van Zijst

and extremely adept at how Hubzilla and its security works...

Not 100% sure, but I´m afraid it is more easy than we all wish and hope...

If you export the identity of a channel as a json file you will see that besides the private key all (?) of the included essential infos are public anyway .

So if the privat Key of a channel got public also, every body could build such kind of json file for that channel Identity and install a new Clone for that channel on any hub. If you have excess to a clone you can ruin the identity of a channel by a lot of ways.

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.

Clones can be "Droped" but the public and private keys stay always the same - they ARE the identity - right?

Looking from that prospective the ZOT nomadic identity is not really something you want to use if and want to build on a stable identity and can´t trust the hub admins. It is still a great way to back up your channels but you better have control over the hubs you sync your channels to.

So after all: If you want a stable identity you have to be the admin of the hub where your channel is hosted - ZOT nomadic identity does not help here.

Please tell and explain me that I´m all wrong. THANKS

Scott M. Stolz

Fri, 27 May 2022 07:22:39 -0400 last edited: Fri, 27 May 2022 07:39:54 -0400

It depends on how it works on the backend. When you drop a clone, does it reissue the keys? Or do you permanently have a key forever? And if you have the same keys, do all clones have the same session ID?

For example, you have a primary channel and you have clones. Each has a key and a session ID. If you log into your primary channel and drop a clone, it reissues the session ID and propagates that to the active clones, but not to the dropped clone. If the session IDs don't match between the clone and the primary, then it is not considered a valid clone (unless you reactivate it).

You can also use a similar technique to remotely log out of a hub. You change the session variable, and the other hubs will automatically log you off since the session ID does not match the primary hub anymore.

Or, you could just reissue the keys, and the bad clone doesn't have a valid key anymore.

I am not sure how Zot handles it, but there are techniques to remotely disable a clone, and techniques to remotely log out of a hub.

RockyIII

Fri, 27 May 2022 09:01:21 -0400

@Scott M. Stolz

Or do you permanently have a key forever?

Yes - I thinks so

Or, you could just reissue the keys, and the bad clone doesn't have a valid key anymore.

No I don´t thinks so - that is not the way it works

Scott M. Stolz

Fri, 27 May 2022 10:23:07 -0400

Why couldn't you change your key? Your ID is username@example.com. The key is not your ID. The key just authenticates that it's you. Couldn't you just publish a new public key at example.com and create a new private key? You'd need error handling for anyone with the old public key, but that can be done.

And if it's not possible to change keys, then using session IDs should work.

RockyIII

Fri, 27 May 2022 10:44:05 -0400

@Scott M. Stolz other can answer this better for sure,

Your ID can change but not your keys - this are your identifier in the network, and make sure that you will get found and identified by other channels - if your key changes your have a new identity

Scott M. Stolz

Fri, 27 May 2022 11:42:18 -0400 last edited: Fri, 27 May 2022 11:43:01 -0400

@RockyIII There are different ways of doing it. I am not sure how Zot implemented it.

But, I also want to mention that any admin who attempted to ruin an identity in the manner you describe would probably go to jail in most countries. After all, you know (or should know) who is running that hub. Either a company name or an individual. At the very least, the domain name should have valid contact information. Law enforcement could see who's credit card they used for the hosting and domain. They could be tracked down. And what you described would be a clear violation of cyber security laws in most countries. Or you could contact their web host and see how their web host likes that they violated their terms of service. Get their account shut down at the very least. In some countries you could sue for civil damages as well.

It would be like someone writing a forged check to their landlord. Their landlord knows who they are and where they live. Not very smart, and there would be consequences.

RockyIII

Fri, 27 May 2022 12:27:25 -0400 last edited: Fri, 27 May 2022 12:34:16 -0400

@Scott M. Stolz i think the subject here it is more about a principle understanding of how we can use ZOT nomadic identity safety.

Is it an identity which belongs to you my design , and are you the only person how can control it?
My Keys for Email encryption are mine but the Keys of a ZOT account are always stored on someone else's Computer (if i´m not the hub admin) - and every time i clone my channel some other admin will have to be trusted.

I thought always with ZOT nomadic identity it is not possible to ban a channel form the Network for good but it seams now it is possible to ruin a channel for good.
It is like this: You can´t destroy a house of a person but you have the keys to the front door - and so you have the ability to go into the house every time you like and do messy things. - Is this a criminal act ? - maybe - or even for sure - but things should be set up better by design - or at least we should know how do deal and handle with ZOT nomadic identity - so we can minimize the risks.

You know i love all the ZOT Apps - `I have spend a lot of time the last years here and working with them - so i want to know what i have actually in my hands.

But i will stop now writing about all this before I did not tested thinks a bit better.
Scott I will pm you - and ask you to help me by this test.

Nolan

Fri, 27 May 2022 12:33:27 -0400

But what if the hub got cracked, and someone got admin acces? A secure protocole should resist to the compromise of one node.

Scott M. Stolz

Sat, 28 May 2022 05:32:38 -0400 last edited: Sat, 28 May 2022 05:42:08 -0400

As someone who comes from the web hosting industry, the only way your website is going to be totally private is on-premise hosting: your machine, your software, your data, your location. That's why major corporations spend billions to self-host proprietary data.

Your web host usually has admin access to your server, especially if you have shared hosting or managed hosting, jailed or not. There are ways to make it harder, like running a VPS or dedicated server, and encrypting all of your data, but the data center still has physical access to your machine.

It comes down to trust. Who do you trust with your data and identity?

Only clone your channels on hubs you trust.
Only use web hosts that your trust, or host it yourself on-premises.

On a personal note, I know someone who got fired because a malicious coworker with admin access to the chat server framed him and made it look like he said something he didn't say. And then that malicious coworker took his job and took credit for his work.

How is that relevant? He basically did the same thing you are describing, except the malicious coworker did it on the company chat server.

Remember that old joke about the system administrator's password being "god." They have god-mode access to your server. Anyone with admin access can screw you over. You have to have someone you trust. if you don't trust anyone, then self-host and be the admin.

emaxmax

Sat, 28 May 2022 09:05:03 -0400

@mike

Any server. Any product. Any operating system. Any protocol.

Wrong. See revocation or blockchain fork for instance.

Scott M. Stolz

Sat, 28 May 2022 11:07:53 -0400

@emaxmax

Wrong. See revocation or blockchain fork for instance.

Revocation is something you could do after the damage is done and you want to reverse it. It does not prevent the damage from being done in the first place. And forks don't prevent the original compromise either.

Changing your keypair temporarily forks your identity, which is similar to the blockchain fork you talked about, except at an identity level.

And since Hubzilla (and other sister platforms) try to delete all remote instances of your posts should you delete them, that is similar to the revocation you are talking about.

So what @mike says is still true. Someone who has your key or password can compromise your account.

Marshall Sutherland

Sat, 28 May 2022 11:47:36 -0400

And people think I am nutty for still running my own servers out of my house...

Hans

Sat, 28 May 2022 17:56:23 -0400

Well, if I would run a business I would never run it on home servers to be honest. I was part of our hosting team for a long time and I do see the benefits of using a remote hosting party. People tend to simply not look at customer data by default since it can kill your job. If there is a request (yes, even from law enforcement) then I would simply ask those in higher ranks to give me a written permission for releasing it or even looking at it. It is the customer data, not the hosting companies data.

To be honest I would be more afraid of having a web-server access data where user nobody is able to run the same queries as the user admin since there is are no data privacy rules that will prevent a visitor to get the same data as the admin besides some code. And yes, that is true for Hubzilla too. There is one database user.

Marshall Sutherland

Sat, 28 May 2022 19:06:27 -0400

Everything I run at home is personal. I don't have the sort of redundancy needed for business-critical infrastructure. I've got the UPS capacity to keep my network and server up for 4+ hours in case of power outage, but I've got no Internet redundancy.

Scott M. Stolz

Sun, 29 May 2022 00:02:33 -0400

Having worked in the web hosting space, I can tell you that even though your data is available to staff with certain clearance levels, a breach by an employee is rare, although possible. Especially since web hosts typically log and monitor everything, especially employee access. If an employee logs into systems not related to their job, they get fired.

You are more likely to be breached by an external hacker than a web hosting company employee.

Although system admins have told me about crazy stuff they encountered on customer's servers. So your server files are accessible by admins if they need to log in to fix something. Unless it's illegal or breaks the terms of service, what you have on your server is kept in confidence though.

Unless you are breaking the law or violating the terms of service, you have little to fear from a reputable web hosting company.

RockyIII

Sun, 29 May 2022 03:37:32 -0400 last edited: Sun, 29 May 2022 08:03:49 -0400

@Scott M. Stolz

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 has a different nature. There are not many hosting companys but a lot of privat people which run a Server and offer services and most offten there is no contract and no terms of services.

Scott M. Stolz

Sun, 29 May 2022 07:58:31 -0400

@RockyIII

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.

Are they self-hosting it in their house with no redundancy? That explains why access to some hubs is spotty and slow.

Then it comes down to trust. Personally, I would not clone my account on a server that was run by an individual at their home. Too much of a security risk. Self-hosting is secure for the admin, but not necessarily for the users. And it is only secure for the admin if they know how to properly secure it.

Although, it should be noted that Hubzilla is designed so that it can run on shared hosting or a VPS. And some conversations I have seen have lead me to believe that at least some people put their hub on shared hosting or a VPS provided by a web host. The hub itself might not have a terms of service, but their web host does, in that case.

RockyIII

Sun, 29 May 2022 12:37:12 -0400

@Scott M. Stolz
yaa ..most hubs run on shared host or a VPSs

"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 privat key as an Admin of a hub i run on a shared host - the terms of service of the web host come into play ?

Scott M. Stolz

Sun, 29 May 2022 12:53:18 -0400

@RockyIII

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 ?

Most certainly. If the web host finds about it, that hosting account would be terminated, with no refund, and the user banned.

RockyIII

Sun, 29 May 2022 14:29:19 -0400

@Scott M. Stolz can you show me that parts of the "terms of service" which could settle this ?

Scott M. Stolz

Sun, 29 May 2022 22:36:38 -0400 last edited: Sun, 29 May 2022 22:57:18 -0400

@RockyIII

can you show me that parts of the "terms of service" which could settle this ?

Since several people mentioned DreamHost, I pulled up their Terms of Service, which references their Acceptable Use Policy:

#^https://www.dreamhost.com/legal/acceptable-use-policy/

Illegal Activity
Customer 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.

In most countries, compromising someone's account would be illegal. In the U.S., the offenses would probably be related to Accessing a Computer and Obtaining Information, Intentionally Damaging by Knowing Transmission, and Trafficking in Passwords, among others.

#^https://www.findlaw.com/criminal/criminal-charges/hacking-laws-and-punishments.html

So that would violate this provision.

Spoofing/Impersonation
Usage 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.

Taking someone's private key and posting as them violates this provision.

Hacking
The usage of DreamHost's computer systems or network to access any system, service, or network without the owner's consent is expressly forbidden.

Taking someone's private key and distributing it would fall under this provision, since the private key was accessed and used without consent.

And the DreamHosts Terms of Service is actually pretty weak. I have seen other companies with broader restrictions.

A violation of any of these will get your account terminated.

RockyIII

Mon, 30 May 2022 12:18:10 -0400

@Scott M. Stolz

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

BUT a frog is possible

Scott and I just did a little test - we would like to try to fork a ruined identity now

How do i do this @mike ? THANKS for Help.

Scott M. Stolz

Mon, 30 May 2022 16:53:17 -0400

I tried dropping the bad clones. One I was able to drop, but that did not delete the clone. The other one, I received a "location not found" when I tried to drop it. It appears dropping a clone doesn't work if the clone is still live.

@RockyIII said:

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 just goes to prove the point: never clone your account/channel on a hub you don't trust. Use remote authentication instead, since that does not give them access to your private key.

Scott M. Stolz

Mon, 30 May 2022 17:00:37 -0400

Does the "Remove Channel" button remove the channel everywhere, or just on that hub?

RockyIII

Tue, 31 May 2022 03:44:36 -0400

to let every buddy know what we are testing: Scott set up a couple of channels on my hub and i was easily able to create clones of this channels on an other hub and post into the timeline of scotts channels with scotts channel identitys.

It appears dropping a clone doesn't work if the clone is still live.

Hmm... right the clones still exist... maybe it takes some time till dropping takes place

How to fork an identity? Do i have to exchange the privat and public keys it the exported json file and that´s it?

Scott M. Stolz

Tue, 31 May 2022 04:10:06 -0400

@RockyIII

right the clones still exist... maybe it takes some time till dropping takes place

I think the "drop" function is only meant to erase inactive clones, so you don't send data to that hub anymore. Once the clone is active again, it reappears on the list.

RockyIII

Tue, 31 May 2022 04:33:40 -0400

@Scott M. Stolz remember now that it was always advised to first delete a clone on the hub where the clone exists by a login to that account and after that delete the clone entry from the primacy hub account ...

So it seams you can´t delete a clone if you don´t have the pw to the account which created it.

RockyIII

Tue, 31 May 2022 04:50:26 -0400

@Scott M. Stolz

A violation of any of these will get your account terminated.

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.

Scott M. Stolz

Tue, 31 May 2022 05:14:18 -0400

@RockyIII

this prove will not be that easy if you have cloned your channel to more than just one hub.

Web hosts log everything possible, and often have backups of your server, so they could look at the time stamps and IP addresses and see who accessed what when. If backups are available, we have before and after snapshots to compare. And we do have security experts on staff.

It obviously is up to the admin in the abuse department on whether they will research it, but I can tell you, accusations of someone compromising an account would be taken seriously at the web hosting companies I worked at. Simply put, we do not want that kind of customer on our servers. If they are willing to hack their own users, they are willing to hack our system too. Our abuse department would kick them out and keep their money. No refunds for violating the TOS.

But it obviously depends on the host. Companies I worked for or with had very vigilant abuse departments.

hEARt PhoniX

Tue, 31 May 2022 05:49:41 -0400

You can still download your channel data, remove everything online and restart later.

Scott M. Stolz

Tue, 31 May 2022 06:35:59 -0400

Let's compare this with any other platform:

Mastodon instance - admin has access to your identity.
Forum Website - admin has access to your identity.
Reddit - admin has access to your identity.
Facebook - admin has access to your identity.
Hubzilla - admin only has access to your identity if you create an account there or clone your channel. If you use remote authentication, they have no access to your identity.

It sounds to me that Hubzilla is actually more secure, as long as you are smart about where you clone your channels.

Malendur

Wed, 01 Jun 2022 06:42:01 -0400

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.

Scott M. Stolz

Wed, 01 Jun 2022 07:01:09 -0400 last edited: Wed, 01 Jun 2022 07:06:41 -0400

@Malendur

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.

Decentralized systems:

Mastadon - federated - admin has access to your identity
Friendica - federated - admin has access to your identity
PeerTube - federated - admin has access to your identity
Zap - federated - admin has access to your identity
Email - decentralized - admin has access to your identity

Clusters

Elasticsearch - clusters - an admin can delete or corrupt everything because they are the admin.

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.

Scott M. Stolz

Wed, 01 Jun 2022 07:24:06 -0400 last edited: Wed, 01 Jun 2022 07:26:54 -0400

The fact that a rogue administrator can spoof or take over your account is true regardless of what system you use: centralized, decentralized, or federated.

The only difference here is that with nomadic identity, you can put your identity on more than one server by cloning it.

Just like you shouldn't give your credit card details to a shady website, you should not be cloning your identity on hubs you do not trust.

That's why there is remote authentication... so you don't have to clone your account on other servers.

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.

RockyIII

Wed, 01 Jun 2022 08:06:16 -0400

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

Scott M. Stolz

Wed, 01 Jun 2022 08:28:04 -0400 last edited: Wed, 01 Jun 2022 09:17:48 -0400

@RockyIII

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

You can add that extra step to the software, but someone who has access to the server can bypass that step by copying the record containing your identity.

I have been trying to think of ways to make it more secure, but the challenge is that any technique I have come up with so far can either be used against the legitimate user or can be bypassed by someone who has access to the database and files on the server.

It is actually easier for me to secure access for a remotely authenticated user. For example, for a remotely authenticated user, I can create a form that allows a user to specify authorized clones. If they log in with remote authentication, my system can check whether they are logging in from an authorized clone. Other than that, for cloned accounts, I have no way of telling which one is legitimate.

Malendur

Thu, 02 Jun 2022 03:41:30 -0400

@Scott M. Stolz

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...

Scott M. Stolz

Thu, 02 Jun 2022 08:15:05 -0400 last edited: Thu, 02 Jun 2022 09:20:31 -0400

@Malendur

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...

Here is the challenge:

Both servers are mirrored instantly, in both directions, so both accounts are always up-to-date.
The clone has to be able to operate even if the primary is down.
If the primary stops working, they have to be able to switch the clone to primary so they can continue using their identity.
It has to be easy enough for your grandmother to use.
It has to work on shared hosting or a VPN, since many of these hubs are run by individuals instead of corporations.

So, let's say you do the master/slave setup.

If the rogue admin controls the master, well, you are screwed in that case. But if the rogue admin controls the slave, then we have to answer the following questions:

Considering that the master and slave are synced instantly, how can you tell if it is the rogue admin posting or the user in real time?
What if the rogue admin changes the slave to the master?

Countermeasures

There are some things you can do, but the fact that changes are instantly mirrored in both directions poses a problem.

You could track which changes are from which clone, making it easier to clean up. Perhaps set it up so that changes made by a clone could be disavowed by the primary, and then deleted by the primary. But this solution is not perfect either, since a rogue admin on your primary server can lock you out of your own account, including your clones.

You can make it easy to fork your identity, so you disassociate yourself from the bad clone, and can disavow and delete all posts from that clone on your new fork. But how do you prevent them from forking your identity, especially if the rogue admin has control of your primary?

But none of these prevent the initial breech.

If you did control your own primary server, there are some things you could so, at the expense of being able to easily switch servers if yours goes down or crashes.

For example, you could disallow your clones from becoming a primary, but that prevents you from recovering your identity if your primary fails or you lose access. Which basically defeats the purpose of having a clone in the first place.

Summary

I don't think the master/slave paradigm works for a system that is instantly synced in both directions. It certainly would not work if the user is not the admin on either server, and both their primary and their clone are on someone else's server.

If you have some solutions, I would love to hear them.

Scott M. Stolz

Thu, 02 Jun 2022 09:39:51 -0400 last edited: Thu, 02 Jun 2022 09:54:31 -0400

@Malendur

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...

No, I am not confused. I think we are just talking about two different things.

I said that a rogue admin can corrupt your channel. You just said that a rogue admin can corrupt the slave. We agree. An admin can corrupt data. That was my entire point. Don't clone your channel on hubs you don't trust.

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.

If you want to brainstorm on ways to reverse a breach, I think that would be productive. But as far as a rogue admin goes, we both seem to agree that they can do damage. A fact that might not be obvious to some users.

Tejan Ausland

Tue, 07 Jun 2022 23:00:12 -0400

@Scott M. Stolz

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.

So, what can be done about it?

Scott M. Stolz

Fri, 10 Jun 2022 08:01:32 -0400

I was thinking about five different issues and realized they are all part of the same problem: knowing if the account on the other end is controlled by the same legitimate user.

Such as:

A rogue admin or hacker takes over a cloned account.
A new owner takes over the domain, reinstalls the hub software, and recreates the same channels.
A user needs or wants to change their keys.
How to recover access on a remotely authenticated server.
How a remote server could identify that they are dealing with the same user.

This would work with the following situations:

Remotely authenticated user’s data is stored on the user’s server and then federated (i.e. Hubzilla social media model).
Remotely authenticated users can store non-federated data on the remote server (i.e. Log in with Hubzilla / Nomad).

Key concepts:

Server becomes an additional actor, with its own keys.
Users can change their keys without losing their identity.
If a user changes their key, the server can validate whether they are the same person.
User can roll back changes made by a corrupted clone.
User can fork their account and disavow certain servers from acting on their behalf.
There is a way to recover your account on a remote server (e.g. an option to specify a recovery email or 2FA method).
There are procedures on what to do if different clones disagree on who is the real owner.
Users can still move their accounts (nomad style).
Users can still have clones.

Structure

Server has its own key.
User’s account contains the current user key for new conversations.
Old disused user keys are also stored in the user’s account, but no new content should be coming from these keys. Can be used to verify that it is the same person after a key change.
A disavowed list of keys that are specifically blacklisted. Any content coming from them should not be considered coming from this user.
Servers have procedures for when clones of an account disagree on the above.
Servers track which content or message came from which server and key in case a rollback is needed.
Changes and old content are stored on the server for a duration specified by the user in case they need to restore their account.
Remote servers that store non-federated data have an account recovery method.

I can go into how the server handles each situation, but this post is already getting too long. Perhaps we should start a new post if someone is interested in discussing the concepts I just laid out, and how they would be implemented.

Scott M. Stolz

Sat, 11 Jun 2022 00:52:19 -0400

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). You could make it so that a clone can be revoked, and each clone would have to re-authenticate with the user's device to continue working on the network.

You would still want to track which content came from which clone, and provide a rollback/cleanup method, but using Webauthn could be used to provide an extra layer of security.

neue medienordnung plus

Sun, 12 Jun 2022 06:51:49 -0400

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.

#^https://wistex.biz/item/2cb950e8-4b9f-442d-82e2-6be82379a1cc

On the one hand, on the trivial level for a little savvy and thinking user, the statement

you should only clone your identity on hubs you trust

is self-explanatory. But if you take into account that you can NOT rely on the fact that for many, maybe for the majority of users the statement above is not self-explanatory, then I assume that the above-mentioned explanation can only understand the users when these users understand the unique selling propositions of Hubzilla or of #Fediverse solutions. And to explain these qualitatively new compared to conventional solutions unique selling propositions is a serious challenge.

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 point of view is that no binding to hardware should be built into the Hubzilla framework.

#challengeFediverse #USP #UniqueSellingPropositions #cloneIdentity

Scott M. Stolz

Sun, 12 Jun 2022 07:22:00 -0400 last edited: Sun, 12 Jun 2022 07:25:51 -0400

@neue medienordnung plus

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.

That might have been because such code would have been proprietary years ago. Things have changed a bit though. Now, the major browsers are providing an interface to their software, and code is being released as open source. So, technically, you would be talking to the browser, not the hardware. The browser talks to the hardware. One major initiative right now is FedCM.

Unless there is another reason.