Change Details

We might want to explore session store implementations which do not put load on our infrastructure (see {T394075} for motivation). The ultimate version of this is not using our infrastructure at all, and storing the session on the client side. We probably don't want to do this for security-sensitive data (we don't want the security of our session encryption scheme and key management to be the only things preventing an attacker from impersonating any other account by just changing the username in the session data), but for anonymous sessions it might be fine. Some potential complications: * Sessions can be large. AuthManager puts a fair amount of data in the session. Special:Book can put an arbitrarily large amount of data in the session. * Especially during login, we do store security-sensitive information in the session; an attacker manipulating that would be functionally equivalent to being able to manipulate the username in an authenticated session. So the exact scope of what sessions to use this for might be somewhat different from "unathenticated". Or maybe we might want to use a scheme where some data is stored in the cookie but it can have a pointer to further data in the session store. (We already have `Session::setSecret()`, that might be a reasonable way of differentiating.)

We might want to explore session store implementations which do not put load on our infrastructure (see {T394075} for motivation). The ultimate version of this is not using our infrastructure at all, and storing the session on the client side. We probably don't want to do this for security-sensitive data (we don't want the security of our session encryption scheme and key management to be the only things preventing an attacker from impersonating any other account by just changing the username in the session data), but for anonymous sessions it might be fine. Some potential complications: * Sessions can be large. AuthManager puts a fair amount of data in the session. Special:Book can put an arbitrarily large amount of data in the session. * Especially during login, we do store security-sensitive information in the session; an attacker manipulating that would be functionally equivalent to being able to manipulate the username in an authenticated session. So the exact scope of what sessions to use this for might be somewhat different from "unathenticated". Or maybe we might want to use a scheme where some data is stored in the cookie but it can have a pointer to further data in the session store. (We already have `Session::setSecret()`, that might be a reasonable way of differentiating.) * Using cookies as storage limits what code can write to the session (e.g. jobs or post-send deferred can't). That would break some use cases like storing upload progress in the session, although probably those use cases are not relevant for anonymous users. * Race conditions and similar problems will get worse as time between MediaWiki code issuing a session write and the session store (browser) actually receiving it goes up by a magnitude.

We might want to explore session store implementations which do not put load on our infrastructure (see {T394075} for motivation). The ultimate version of this is not using our infrastructure at all, and storing the session on the client side. We probably don't want to do this for security-sensitive data (we don't want the security of our session encryption scheme and key management to be the only things preventing an attacker from impersonating any other account by just changing the username in the session data), but for anonymous sessions it might be fine. Some potential complications: * Sessions can be large. AuthManager puts a fair amount of data in the session. Special:Book can put an arbitrarily large amount of data in the session. * Especially during login, we do store security-sensitive information in the session; an attacker manipulating that would be functionally equivalent to being able to manipulate the username in an authenticated session. So the exact scope of what sessions to use this for might be somewhat different from "unathenticated". Or maybe we might want to use a scheme where some data is stored in the cookie but it can have a pointer to further data in the session store. (We already have `Session::setSecret()`, that might be a reasonable way of differentiating.) * Using cookies as storage limits what code can write to the session (e.g. jobs or post-send deferred can't). That would break some use cases like storing upload progress in the session, although probably those use cases are not relevant for anonymous users. * Race conditions and similar problems will get worse as time between MediaWiki code issuing a session write and the session store (browser) actually receiving it goes up by a magnitude.