Working as a team without shared passwords

A login pasted into a chat has no owner and no end. It stays in that history, on both machines and in their backups.

It also cannot be taken back. The only revocation left is a password change, which locks everybody out at once and tells the platform the account changed hands.

Each person signs up for an account of their own, and an invite puts it into your workspace. From that moment the plan they work under is yours.

Profile quota, the address library, folders and the history all resolve against the owner. One team works inside one paid allowance and one bill.

A role is a rank rather than a list of ticks. Every action on the server names the lowest rank it accepts, so a role the server does not recognise opens nothing.

A role applies to the whole workspace, so it cannot say that a contractor works on one client. Folders say that: tick the groups a person may see and their list narrows to those groups.

The rule is read twice, when the list is built and when a profile is opened by its own identifier. A profile outside the allowed folders answers as if it had never existed.

• An empty choice

  reads as no restriction, so unticking the last folder widens the view

• A profile in no folder

  stays hidden once a restriction is set, or filing nothing would bypass the rule

• The restriction itself

  belongs to your workspace and does not follow the person into their next one

You tick colleagues in the profile's own share window, and it appears in their list marked as somebody else's. The choice is set as a whole, so unticking a name is what revokes access.

The fingerprint and the settings travel with the profile, so a colleague opens the same identity rather than a copy. Cookies and logins travel through profile sync where that is on.

One window holds a profile at a time. The second machine is told which one took it, and the hold lapses on its own when a machine goes quiet.

The address library belongs to the workspace rather than to one computer, so it is one library for everyone in it. Attaching an address to a profile is how a colleague gets a way out.

The ordinary list carries the address, the label and the fact that a password is set. The password is not in that answer, and pulling the whole library with its passwords belongs to a manager and above.

Where a password rests on disk, the system that already keeps your passwords keeps this one. Where the system cannot, the value is written as it is rather than dressed up as protected.

Every action worth arguing about writes one row: who, what and when. A password handed out of the library is one of those rows, so who took the working keys has an answer.

Names are frozen as they stood that day, so renaming a profile today does not rewrite last week. Reading the history belongs to the owner and to an admin.

Removal and leaving on your own run one path, because two paths to one event eventually disagree and one of them forgets to revoke something.

All of it happens in one step, and that is the point of this lesson: access ends in one place instead of being remembered from a chat.

• Access ends both ways

  their reach into your profiles goes, and anyone's reach into the profiles leaving with them

• Their hold is released

  an open profile would otherwise look occupied to everyone who stayed

• Work profiles stay

  profiles made after they joined were created in your quota and stay with the workspace

• Library addresses stay

  a profile that walks out loses the workspace address behind it, and keeps their own

• Unused invites are burned

  an unaccepted code to the same address would be a key back in