-
Notifications
You must be signed in to change notification settings - Fork 0
New sitter plan
- Simplify sitting for other accounts
- Enable better tracking of sitters
- Reduce vulnerabilities for accounts through insecure shared passwords, especially as alliances change
- Eventually remove inactive empires
- Clearer lines in the sand as to what sitters can do on behalf of their babies.
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.)
To prevent self-destruction, the counter will only count from the later of the expiry of the last sitter or the last real login. Even if the sitter doesn't actually do anything to your account, it will still prevent self-destruction. This is made feasible by the auto-expiry of those sitter auths.
All authorisations, in both directions, are automatically severed (instantly expired) 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.
To aid in scripting for non-scripters, who can currently take advantage of allies with scripting capability, the server will also track active users. An active user is someone who has clicked on something in the last 30 minutes. (Note that running your own scripts will keep you marked active, since that "clicks" for you, but you probably won't need anyone to run stuff for you.) The onus to still ensure that the player is active remains with the scripter, but this will allow us to block the majority of potential abuses. A user that is active will enable sitters for that account to run things that sitters normally couldn't run, such as spy_run.pl --flip or anything else that is tedious that we don't want players to run for inactives.
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.
Input: session ID, array of empires to authorize.
Output: status, rejected
This will reauthorize IDs that already have been authorized as well, so a single API for both. The rejected key shows which IDs were rejected.
Each empire can be either the ID or the empire name, doesn't matter. The names might be easier for scripting and such. All numeric becomes user ID, so names like 0088 and 2112 need to use their user IDs. (A leading space will work, too, but might be confusing.)
Input: session ID, array of IDs to deauth
Output: status
The sitter information is passed back as part of format_status, so will always be available at a quick glance. This is because most of that info was already required for the UI's right sidebar anyway, so a few extra fields and we can eliminate an API.
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.
To be thought about:
- unallied players where fetching from a station isn't an option, players in an alliance of one where there's no one to fetch from.
- Logging who did what as a sitter (to find abuses of sitting). Probably just logging that user A became user B (whatever that means) will suffice.
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.
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.