New sitter plan

Goals

1. Simplify sitting for other accounts
2. Enable better tracking of sitters
3. Reduce vulnerabilities for accounts through insecure shared passwords, especially as alliances change
4. Eventually remove inactive empires
5. Clearer lines in the sand as to what sitters can do on behalf of their babies.

Plan

Remove the sitter password altogether. There will be no more reason to give out passwords to allies, friends, whatever. Even asking for a password could become an offense since it may confuse people into giving out their (remaining) password.

Simultaneously, there will be a server-managed list of one-way sitter authorisations (just because I give you access to my account doesn't mean you give me access to yours).

A set of new API calls, and something in the UI to call them, will:

a. switch the current session ID to operate as an account that has authorised the real user logged in. (Should be able to switch from one sat account to another without logging out or switching back to the main account.) The currently displayed planet should be the same if it's a station that the sat account ("baby") can see, otherwise needs to go to the capital. Captcha not required.

b. authorise someone to sit for your account. This is reserved only for main accounts - sitters cannot authorise new sitters. This API could take multiple empires as input to allow it to be scripted easier. And then the UI could also have some sort of selection ability ("authorise everyone in my alliance" for example, or "choose from everyone in my alliance") at some point in the future. Captcha required.

c. RE-authorise someone to sit for your account. Again, sitters cannot re-authorise sitters, and, again, could take multiple empires as input (allowing for a reauthorise-all type button). Captcha required.

d. List who can sit your account. Captcha not required.

e. List who you can sit for (this might become part of the empire view, though it has to return for the real account, not the one you're currently acting for). Captcha not required.

Each authorisation has a timed duration, whether that's 20 days or 60 days, to be determined (opinions?). It can be reauthorised early, resetting the timer back to the full amount, whatever that may be. Sitting will continue to prevent auto-self-destruction of inactive accounts, but since the authorisation will expire without regular logins, self destruction will still happen eventually. Also, multiple ingame emails (possibly with click-here links that fail if it's clicked via sitting) should be sent as the deadline looms. For example, if the expiry is 60 days, then perhaps 14 days, 7 days, and 3 days prior to expiry, they should receive a reminder, plus one when it expires. (Expiry can be at end-of-day, doesn't have to be to-the-minute via scheduler, allowing a single email to list multiple soon-to-expire authorisations.)

All authorisations, in both directions, are automatically severed whenever someone leaves an alliance, but only among that alliance. If someone is authorised to sit your account but they leave your alliance, that authorisation is revoked, and if you leave your alliance, any ability you have to sit for your now-former allies is also revoked. However, any authorisations that are outside of your alliance should not be revoked. For example:

Users A and B are in an alliance, Z. User A has authorised B to sit for A, so B can switch to A while playing. User A has also authorised user C, who is not in alliance Z, to sit A's account, so C can also switch to A while playing. If user B leaves alliance Z, B's ability to become A will be revoked, but C will be unaffected. Similarly, if it is user A leaving the alliance, B's ability to become A will be revoked, but C will still be unaffected.

This will make it much more difficult to encounter certain abuses, including no-longer-allies who may have your sitter pw since you forgot to change it, or may not have realised you needed to change it.

Implementation Details

A new table required linking the accounts.

baby_id (int) The "baby"
sitter_id (int) The "sitter"
expiry (date) when this is good until

Indexes are likely required on both baby and sitter. There is no id field, instead the primary key is a combination of baby_id and sitter_id.

The session also needs to be expanded somewhat to save who this really is, though is_sitter can go away (the method can simply check if real_user_id != empire_id).

Admins becoming a player should not be able to switch to that account's sat accounts, either. An admin wanting to become another account should go back to the admin UI and become the account there for proper accountability.

Need to determine how login_log will work with this, if at all. I'm thinking that logins via the switch-user API should change the switched-to empire's last login, but not add it to the login_log table, partly because I expect players to switch between accounts willy-nilly. Today, it's a lot of extra work to log out and log in if they're going to do this by hand. But with this, it'll be easy to switch, especially going to a station and switching between empires for voting for alliances without scripting ability. (Note that some votes will require main passwords, so this still won't help them, either.) A lot of logins will be captured, making it less useful.

If a way is found to only log one login from a given sitter session to a given baby, that might be reasonable.

RPC costs could be born by either the sitter or the baby - right now, the leaning is towards the baby. This makes it the same as the current code.

Sitter clarification

Some things that sitters may be used for now that may be of dubious legality can also be clamped down on server-side.

• Almost all actions that require a captcha probably should not be allowed via sitter.
• Defensive spy actions (training, recruiting, counter esp, sec sweeps) should be allowed (and maybe the captcha removed?), offensive actions to be eliminated.
• Trade min purchases should also not be allowed via sitter, but this will have to wait until the TM "fetch" functionality is added - sending halls to allies is part of building and repairing a sat planet. However, draining a sat empire's E is probably not what a sitter is for.
• Trade min selling is dubious and hard to stop. Sending E to a baby for subbing stuff is legitimate, but draining the baby's high-value plans is not. Again, though, once fetch works, pushing all the plans to a station for others to take will make this hard to police, and worrying about stuff going through the TM might be moot. We could prevent pushing and selling non-station-module plans and glyphs via sitter, which would allow the baby to fetch halls without being able to send them.

People who are actively quitting can always push/sell all their high-value stuff and give away their E, but then they're actively doing it before setting self-destruct.

Short term pain

Inactives at the time this is implemented will go into self-destruct mode quickly even if they were being sat fine before. This is seen as a feature.

Player strategies

Once you kick an inactive out of your alliance, you get 20 days (plus one day per E) to flip them or lose them forever. This, too, is seen as a feature. We may want to shorten that - maybe consume more E per day, and/or not count e-veins for players who are in this shut down mode.