Beacon Child Accounts Proposal

[thommcgrath]

One issue with Beacon at the moment is account reuse. One admin will purchase a copy of Beacon and simply let their whole team of admins use the account. On the surface, this seems like a revenue problem and I'm not going to deny that it bothers me a bit, the bigger issue is revocation. Sometimes admins go bad, and the true account owner may believe they can just change their password if it were to happen, but it's not that simple. Since the private key is downloaded to each computer signed in, changing the password gracefully (that is, when the password is known) doesn't change the private key. The "bad" admin will be able to immediately re-authenticate because they still have the private key. There's no way to get that off the their system if they don't want to do it. The only option becomes a force password reset, which generates a new private key. However, this means all data in the user's cloud bucket will be lost, which includes presets and custom engrams. The user's documents will also lose any encrypted data, such as server records and admin passwords. So for these reasons, account sharing is very strongly discouraged because recovery options are limited.

Beacon's document sharing is a good solution, but while not every user needs Omni, any user who wishes to push changes to the server would need their own copy. That could become an expensive option, and it's not my goal to bleed users dry.

This proposal is to offer an alternative to these teams of admins: child accounts. The "head" admin would be able to create Beacon accounts that mostly share the permissions of the parent account. Child accounts would automatically get access to the parent's documents and cloud files, just like they were signed into the parent account directly. The parent account could at any time turn off a child account, so no password changes or private key regeneration would be necessary.

This ability would not be free, but would come at a steep discount. These numbers are not set in stone. I envision a "Beacon for Teams" product for $25 that would include access for 2 child accounts. Buying separate copies would normally cost $45, so this would be a significant savings. I don't believe a lot of teams are even considering buying every admin a copy, so this probably isn't leaving money on the table. Instead, I believe this would encourage teams to take the more legit approach. Teams needing additional child accounts could purchase them for $5 each. Any user of Beacon Omni would be able to purchase child seat slots, not just those who purchased the "Beacon for Teams" option. That option would essentially just be a bundle.

There is the occasional purchase of 1 copy and 1 giftable copy that I assume is somebody purchasing for themselves and one other admin. This proposal would cannibalize those sales by $5, but they're rare enough as to not be a concern. I cannot recall any purchases of more than 2 full-priced copies at a time.

Child Account Restrictions & Considerations

• Due to the need of the parent account's private key, child accounts could not force reset their password. They can gracefully change their password, but the parent account would need to force reset a child account password the password is lost.
• This also means the parent account creates and assigns the passwords for all child accounts. A flag on the child account could force a password reset on the next login... maybe. That would work fine on the website, but isn't necessarily intuitive in the app.
• If the parent account performs a forced password reset all child account passwords would be changed. This is because each child account has their own copy of the parent account's private key, and that private key will have changed.
• Email verification is a bit tricky. Child accounts should still require email verification, but the database won't allow setting of the private key until a full user profile is available. This will need some consideration.
• Beacon versions before 1.5 would not be able to sign into a child account.
• Since child accounts have mostly full access to the parent's resources, child accounts could delete documents and objects in the cloud. However, Beacon 1.5 will also bring document revisions, so any one of the accounts would be able to restore a deleted document or fall back to a revision before damage was done.

Concerns

There is a potential for abuse that would need to be monitored. I could imagine somebody trying to make a buck by offering Beacon Omni for $10, and simply buying a $5 child account for the user. There's honestly no real solution though. Terms of service would need to explicitly prohibit reselling of child accounts, and usage would need to be monitored. If such a behavior were detected, the parent account would need to be disabled and something done about all the child accounts.

[jackchristel]

This is a good idea, I feel like if someone buys beacon Omni for $15, then any child account they want can be added for $5 so people don't need to buy a whole different plan, or instead they can upgrade to a teams account account, and add as many child accounts as they need for a price, the more child slots you buy are cheaper maybe? And the teams account would just be a upgrade to the Omni account, for the extra $5 or $10 depending on the extra slots they wanted.

[Redriver559559]

I agree with this..and i have a system you can use..maybe a whitelist method for all keys..if a present key like a $15 plan keeps getting switched between 2 locations make it a 24 hour blacklist wait to prevent stealing or sharing keys. And the family methkd for $5 to add a extra key I really like..though I feel like people would abuse it and make people buy them a key for $5 instead of $15 so just be aware. But I love the idea

[thommcgrath]

@Redriver559559 I think the DRM stuff would be too heavy-handed. Although people aren't really traveling now, some day that will become normal again. I don't want somebody to be locked out because they happen to be on a trip. Piracy will happen, and my goal isn't to stop it outright. That never works. My goal is to redirect it. The safety aspect is not just an excuse either. Account sharing is dangerous, so I want users to consider ways to reach their goal safely. Security is about more than just putting the biggest lock on something, the human nature of why users want to make themselves less secure needs to also be considered.

[thommcgrath]

Adding some notes from a private Discord conversation. It would be a good idea if the parent account can maintain some kind of control over the passwords used by the child accounts. Password reuse is a real problem, it would be a shame for somebody's files to be accessed by a child account with poor security when the parent is taking proper steps. Assigning a good random password sounds like a good idea at first, but would probably reduce security because people won't remember it and likely store it someplace insecure. It would solve the reuse issue though. Another option could be two factor authentication. Beacon doesn't support it right now, but it could. Child accounts could have a hard 2FA requirement, if the parent so chooses. Or maybe just always. Something to consider.

The other idea from this conversation was change tracking. That would be tricky, especially in a way that could be presented to the user. In theory, a document could be decompressed and compared with its previous version using an off-the-shelf diff engine. In practice, there's lots of issues with this such as storing the diffs, displaying them to the user, and the fact that the compressed JSON is not "pretty" which makes it hard to compare. Change tracking is a good idea that may be beyond the reach of practicality.

[thommcgrath]

Might end up punting on this. Checked in the work I've done on the concept to 0a7f632, but the changes required are getting out of hand. The code was only committed so it doesn't get discarded, but it isn't usable and will probably be started over if I decide to try again.

[thommcgrath]

Child accounts ended up having a security flaw that I have not been able to solve. I'd still like to do something in the spirit of helping teams, so to that end, maybe a workspace would be a better idea. The general idea is a user could create a shared workspace which has its own private key. Other users can be added to the workspace. Saving a document could then be done to the computer, personal cloud, or a chosen workspace. When saved to a workspace, the encryption key of the workspace is used. In case it's not clear, a workspace would be a cloud-level item. So documents saved to a workspace are still technically in the cloud, but they would be owned by the workspace, and the workspace owned by a user, rather than a user owning the document directly.

For anybody looking in, I'm really just jotting down ideas right now so I don't forget them.