Last modified: 2014-10-18 00:25:35 UTC
Previously, we were required to remember a user's session information for no longer than 30 days on Wikimedia sites. The new privacy policy (https://meta.wikimedia.org/wiki/Privacy_policy) does not require such a limitation, and in fact explicitly calls out remembering logins as a use case: "...such as by using cookies to maintain your session when you log in or to remember your username in the login field." As such, if a user checks the "keep me logged in option" on the login form, cookie expiry should be set to one year. In practice, this will often be shorter, since users often travel across many browsers or devices, and may clear their cookies. At the very least, users who opt in to being remembered should have their sessions remembered for longer than the arbitrary 30 day limit.
Is this cleared by legal and security? Also, note that https://meta.wikimedia.org/wiki/Privacy_policy/FAQ#cookieFAQ will need to be updated.
(In reply to James Forrester from comment #1) > Is this cleared by legal and security? Also, note that > https://meta.wikimedia.org/wiki/Privacy_policy/FAQ#cookieFAQ will need to be > updated.
(In reply to Steven Walling from comment #2) > (In reply to James Forrester from comment #1) > > Is this cleared by legal and security? Also, note that > > https://meta.wikimedia.org/wiki/Privacy_policy/FAQ#cookieFAQ will need to be > > updated. (In reply to James Forrester from comment #1) > Is this cleared by legal and security? Also, note that > https://meta.wikimedia.org/wiki/Privacy_policy/FAQ#cookieFAQ will need to be > updated. Yes, the change has been cleared by legal. The extension to one year is permissible under the new privacy policy, as Steven indicated. We will update the FAQ once the change goes into effect.
My initial reaction is that for privileged accounts, 1 year sounds excessive. But for normal accounts, this should be fine. When we're able to implement password length and https requirements per use group, we may also customize this.
(In reply to Chris Steipp from comment #4) > My initial reaction is that for privileged accounts, 1 year sounds > excessive. But for normal accounts, this should be fine. > > When we're able to implement password length and https requirements per use > group, we may also customize this. Does this mean you're OK with going with this change for all accounts for now, with the intent to reduce it back down for privileged accounts later, or do you want us to hold off until that functionality is created (and if so, when will that happen and who will do it)?
(In reply to Chris Steipp from comment #4) > My initial reaction is that for privileged accounts, 1 year sounds > excessive. But for normal accounts, this should be fine. > > When we're able to implement password length and https requirements per use > group, we may also customize this. Privileged users will definitely want this feature just as much as those without special permissions. Maybe even more, since they tend to be active more often. If we think privileged accounts need extra session security then we should enforce that through other means I think, like increased minimum password lengths/complexity, force use of HTTPS, and so on. From a design standpoint, changing the expected behavior (either the length of the cookie expiration or the visibility of the checkbox) depending on the user's permissions is awkward. It seems pretty likely to confuse or annoy users to have logins behave differently depending on account type/permissions.
(In reply to James Forrester from comment #5) > (In reply to Chris Steipp from comment #4) > > My initial reaction is that for privileged accounts, 1 year sounds > > excessive. But for normal accounts, this should be fine. > > > > When we're able to implement password length and https requirements per use > > group, we may also customize this. > > Does this mean you're OK with going with this change for all accounts for > now, with the intent to reduce it back down for privileged accounts later, > or do you want us to hold off until that functionality is created (and if > so, when will that happen and who will do it)? Yes, I'm ok with it for now. Steven makes a good point on the usability. We'll discuss more whenever I get the chance to work on it.
(In reply to Chris Steipp from comment #7) > (In reply to James Forrester from comment #5) > > (In reply to Chris Steipp from comment #4) > > > My initial reaction is that for privileged accounts, 1 year sounds > > > excessive. But for normal accounts, this should be fine. > > > > > > When we're able to implement password length and https requirements per use > > > group, we may also customize this. > > > > Does this mean you're OK with going with this change for all accounts for > > now, with the intent to reduce it back down for privileged accounts later, > > or do you want us to hold off until that functionality is created (and if > > so, when will that happen and who will do it)? > > Yes, I'm ok with it for now. Steven makes a good point on the usability. > We'll discuss more whenever I get the chance to work on it. Thanks for the quick replies and flexibility Chris. Assigned this to Sam Smith, since we have the bandwidth to pick this up as part of our current sprint.
is there a related bug to remove this from the login form or the prefs page? its weird to have it in both places, and most users assume a "remember me" type behavior anyway.
(In reply to Jared Zimmerman (WMF) from comment #9) > is there a related bug to remove this from the login form or the prefs page? > its weird to have it in both places, and most users assume a "remember me" > type behavior anyway. It isn't in the prefs page anymore. Removed via bug 52342 in April/May. Semi-related, there's also bug 47694 ('"Remember me" on Login interface should state duration')
(In reply to Quiddity from comment #10) > Semi-related, there's also bug 47694 ('"Remember me" on Login interface > should state duration') FYI: The patch associated with that bug request (https://gerrit.wikimedia.org/r/#/c/110279/) states: "If $wgCookieExpiration is smaller than its default value of 180 days, the length of time the user will stay logged in will now be displayed next to the "Keep me logged in" checkbox on the login form." This means that it would show nothing if cookie expiration is one year.
I don't know that we want to keep using wgCookieExpiration for this, though. That would make the default (on WMF wikis) for all cookies a year, which would probably encourage proliferation of little cookies that are not as important as whether you're logged in (E.g. this cookie indicates you have the third sidebar of the page toggled; too bad we removed that feature X months ago). This also has performance implications, since cookies use bandwidth on every request. It's not a big deal to make a separate variable for this, I think.
"All cookies" meaning unless they specify an explicit expiration directly.
(In reply to Matthew Flaschen from comment #12) > I don't know that we want to keep using wgCookieExpiration for this, though. > That would make the default (on WMF wikis) for all cookies a year, which > would probably encourage proliferation of little cookies that are not as > important as whether you're logged in (E.g. this cookie indicates you have > the third sidebar of the page toggled; too bad we removed that feature X > months ago). This also has performance implications, since cookies use > bandwidth on every request. > > It's not a big deal to make a separate variable for this, I think. +1. Fully in support of making a login-specific setting for this.
I'm not entirely sure, but the login cookie expiration is only relevant in relation to how long a user is *not* active, not how long or how often they *are* active. Meaning, if you visit the site at least once or twice a month, your session will never expire because it's extended with every visit. Allowing existing sessions to be picked up again after more than a month of not using the site doesn't seem very valuable. If anything it sounds a little dodgy from a security perspective (e.g. stolen sessions, or computer theft). I'm not opposing it entirely on any of those grounds, just want to verify here: 1) Is it true that sessions are automatically extended with each visit and that therefore, with 30 days expiration, the session will last forever if you visit once every 30 days? 2) Is the only use case that would justify this change so that users who aren't very active don't have to log in again if they've been inactive for over a month?
(In reply to Krinkle from comment #15) > Allowing existing sessions to be picked up again after more than a month of > not using the site doesn't seem very valuable. If anything it sounds a > little dodgy from a security perspective (e.g. stolen sessions, or computer > theft). There's also a benefit if the user (think of new users especially) forgets their password, especially since we don't require an email. It's common for there to be a tension between security and convenience. > I'm not opposing it entirely on any of those grounds, just want to verify > here: > > 1) Is it true that sessions are automatically extended with each visit and > that therefore, with 30 days expiration, the session will last forever if > you visit once every 30 days? I don't believe so: git grep -F -- '->setCookies' Only specific login pages (Special:UserLogin and API login) and Special:ChangePassword seem to call that. I don't think there's anything that extends the expiration time when you're just browsing around. > 2) Is the only use case that would justify this change so that users who > aren't very active don't have to log in again if they've been inactive for > over a month? I think it's just 30 days from login, regardless of what you do in between.
Right, we only set the cookie at log in time and it expires after 30 days regardless of whether the user actively uses their account (at which point they'd randomly find themselves logged-out after 30 days, not in a middle of a browser session due to the session cookie, but the next time they re-open the browser). I believed we had this already (I don't recall having to authenticate anywhere in the last few months for Wikimedia wikis, so either something else is extending it or I just forgot I had to do it once). Same for Google, Facebook, etc., for those I'm quite certain it is being extended automatically. Sending the session cookies back to the browser on every request is not that expensive, but I can imagine that not being very attractive. Ideally we'd programmatically find out when the login session expires, and refresh it one a day or so. Unfortunately, the expiration property of a cookie can only be set, not read. The solution I used to use for my Toolserver is to store the expiration date given to the browser for the session id on on the server in the actual session data. Then whenever a request comes in and the cookie is more than e.g. 24h old, refresh it once. This covers the use case proposed in this bug: New users will not have to log in again after 30 days (especially if they forgot their password and didn't provide an e-mail address) Whilst having two additional advantages: * We don't accept dormant sessions over a year old to be used to authenticate the user. * We do distinguish between used and unused sessions. * We provide even more convenience to users (never[1] have to log in again, not even once a year). [1] never, that is, as much as we can help it. We may invalidate sessions for security reasons or when performing data centre maintenance. And browsers may garbage collect cookies at some point.
(In reply to Krinkle from comment #17) > This [proposal] covers the use case proposed in this bug: > > New users will not have to log in again after 30 days > (especially if they forgot their password and didn't > provide an e-mail address) > > Whilst having two additional advantages: > > * We don't accept dormant sessions over a year old to be used to > authenticate the user. > * We do distinguish between used and unused sessions. > * We provide even more convenience to users ("never" have to log in again, > not even once a year). > And, important for the legal/privacy angle: * We keep our cooky expiration dates under 31 days. We will not set cookies for a year.
(In reply to Krinkle from comment #17) > Right, we only set the cookie at log in time and it expires after 30 days > regardless of whether the user actively uses their account (at which point > they'd randomly find themselves logged-out after 30 days, not in a middle of > a browser session due to the session cookie, but the next time they re-open > the browser). > > I believed we had this already (I don't recall having to authenticate > anywhere in the last few months for Wikimedia wikis, so either something > else is extending it or I just forgot I had to do it once). > > Same for Google, Facebook, etc., for those I'm quite certain it is being > extended automatically. There was something on some private wikis that is based on activity, although so far I haven't been able to find out who set it up or how. But doing an automatic extension once a day seems like a much better solution, and as you point out, not that difficult.
(In reply to Chris Steipp from comment #19) > > But doing an automatic extension once a day seems like a much better > solution, and as you point out, not that difficult. This automatic extension doesn't sound like it adequately serves the type of infrequent editor who takes breaks in between site visits/editing sessions. You still get the effect of "I haven't visited for 30 days, and now I'm logged out", correct?
(In reply to Steven Walling from comment #20) > This automatic extension doesn't sound like it adequately serves the type of > infrequent editor who takes breaks in between site visits/editing sessions. > You still get the effect of "I haven't visited for 30 days, and now I'm > logged out", correct? Correct. Do think we have a significant number of these types?
(In reply to Matthew Flaschen from comment #16) > I don't believe so: > > git grep -F -- '->setCookies' > > Only specific login pages (Special:UserLogin and API login) and > Special:ChangePassword seem to call that. I don't think there's anything > that extends the expiration time when you're just browsing around. I didn't investigate CentralAuth, though. So it's possible that does extend your session through normal browsing (either deliberately or as a side effect).
(In reply to Chris Steipp from comment #21) > (In reply to Steven Walling from comment #20) > > This automatic extension doesn't sound like it adequately serves the type of > > infrequent editor who takes breaks in between site visits/editing sessions. > > You still get the effect of "I haven't visited for 30 days, and now I'm > > logged out", correct? > > Correct. Do think we have a significant number of these types? Yes. When you breakdown total active editors every month, there is a very large group of editors who return after more than a 30-day break. This type of reactivated editor is just as large as the group of people who edit month-to-month continuously.[1][2] 1. [[commons:File:Monthly active editors.by group.enwiki.svg]] 2. [[commons:File:Monthly active editors.facet group.enwiki.svg]]
Hm.. also relevant is that we invalidate existing sessions when a new session starts for a user. So in case of theft or hijacking in a way where the user logs in again on a different browser / account / computer, the old session will be immediately invalidated. Though only if the user logs in with "Remember me", a short session login maintains validity of the existing Remember-me session on the server.
(In reply to Steven Walling from comment #23) > Yes. When you breakdown total active editors every month, there is a very > large group of editors who return after more than a 30-day break. This type > of reactivated editor is just as large as the group of people who edit > month-to-month continuously.[1][2] This shows that there are a significant number of people editing with more than 30 day gaps. However, I would bet a lot of them *visited* I Wikimedia site with < 30 day gaps (e.g. to read an article, maybe from a search). Under this proposal, that would still extend their session.
(In reply to Matthew Flaschen from comment #25) > (In reply to Steven Walling from comment #23) > > Yes. When you breakdown total active editors every month, there is a very > > large group of editors who return after more than a 30-day break. This type > > of reactivated editor is just as large as the group of people who edit > > month-to-month continuously.[1][2] > > This shows that there are a significant number of people editing with more > than 30 day gaps. > > However, I would bet a lot of them *visited* I Wikimedia site with < 30 day > gaps (e.g. to read an article, maybe from a search). Under this proposal, > that would still extend their session. The truth is we don't know because we never track read-only sessions month to month. The safe bet here, if we want to ensure that *people who opt in* stay logged in, is to lengthen the cookie expiry beyond 30 days. Keep in mind that the change would only impact people who explicitly choose to be remembered. If we were discussing a default login session length, I would probably agree that we should err on the side of being more conservative.
Most modern sites have dispensed with this type of control all together, financial sites do the opposite and force log you out after 10-30 mins usually. If the use case were trying to solve for us the small set of more security conscious users we can mostly assume they'll log out after each session. What if we invert this option and in preferences:profile we have an initially unchecked option of "Automativally log me out after 40 days of inactivity" or whatever timespan these users prefer. Then the site behaves normally and smoothly for users who dont want to have to frequently reinter logging credentials?
(In reply to Jared Zimmerman (WMF) from comment #27) > Most modern sites have dispensed with this type of control all together, > financial sites do the opposite and force log you out after 10-30 mins > usually. > > If the use case were trying to solve for us the small set of more security > conscious users we can mostly assume they'll log out after each session. > What if we invert this option and in preferences:profile we have an > initially unchecked option of "Automativally log me out after 40 days of > inactivity" or whatever timespan these users prefer. Then the site behaves > normally and smoothly for users who dont want to have to frequently reinter > logging credentials? It's a good idea, but let's consider such an option as a separate bug/design idea iterating on this. Without redesigning the system completely, we can immediately take a very simple step to increase retention of registered users.
I strongly suggest this be discussed on meta before being implemented. Especially given the less than positive response last time around.
(In reply to Bawolff (Brian Wolff) from comment #29) > I strongly suggest this be discussed on meta before being implemented. > Especially given the less than positive response last time around. What response are you talking about? I haven't been aware of any recent previous discussion about this that was overly negative. For the record, any previous proposal to extend any cookie retention beyond 30 days should have been rejected or undone per the Wikimedia privacy policy, which expressly forbid such a thing. I think there might have been a period where it was 180 days, but that was undone IIRC. Getting rid of this hard requirement for Wikimedia sites is part of why we revised our privacy policy. You can see this reflected in comments during that lengthy discussion period.[1][2] Outside of the privacy policy discussion, I've repeatedly heard people asking for an option to be logged in longer than 30 days.[3][4][5] 1. "the expected improvements users should like this policy for (this is the only one mentioned so far apart from longer login duration, if I remember correctly)." https://meta.wikimedia.org/wiki/Talk:Privacy_policy/Archives/2014 2. "I'd rather be able to stay logged in forever" https://meta.wikimedia.org/wiki/Talk:Privacy_policy/Archives/2013#What_about_login_cookie_duration.3F 3. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_110#Only_30_days_per_login_AGAIN.3F 4. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_40#30_day_login_limit 5. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_47#Logging_out_after_30_days_feature
Change 141248 had a related patch set uploaded by Phuedx: Configure logged in session length independantly https://gerrit.wikimedia.org/r/141248
Change 141394 had a related patch set uploaded by Phuedx: Use $wgLoginCookieExpiration when setting login cookies https://gerrit.wikimedia.org/r/141394
(In reply to Jared Zimmerman (WMF) from comment #27) > Most modern sites have dispensed with this type of control all together I would be surprised if this is true of most major sites that are currently actively used. Google ("Stay signed in"), Twitter ("Remember me"), Facebook ("Keep me logged in"), Yahoo ("Keep me signed in"), and Pandora ("Remember me") all have it. I don't claim they all have the same behavior, but they all have a control on the login screen.
(In reply to Krinkle from comment #24) > Hm.. also relevant is that we invalidate existing sessions when a new > session starts for a user. So in case of theft or hijacking in a way where > the user logs in again on a different browser / account / computer, the old > session will be immediately invalidated. Is asking for year-long concurrent sessions on multiple devices on-topic here, is there a separate bug for this, should I file one or ask on Village Pump?
(In reply to Martin von Gagern from comment #34) > (In reply to Krinkle from comment #24) > > Hm.. also relevant is that we invalidate existing sessions when a new > > session starts for a user. So in case of theft or hijacking in a way where > > the user logs in again on a different browser / account / computer, the old > > session will be immediately invalidated. > > Is asking for year-long concurrent sessions on multiple devices on-topic > here, No. > is there a separate bug for this, No, I don't believe so. > should I file one Please do. > or ask on Village Pump? Please don't ask on the Village Pump intricate technical requests, as they're normally lost. However, feel free to mention on-wiki about the bug.
I was thinking about this from a different standpoint yesterday. Right now we're logging every time a user logs in with the AccountAudit extension to help with SUL finalization. We can roughly figure out if a user is active on a monthly basis since they have to login after 30 days, updating their row in the database. If we extend login time to 1 year, we wouldn't have that level of accuracy any more. Probably merits fixing in the AccountAudit extension, but I just wanted to note it here in case anyone else is collecting statistics on when users login.
(In reply to Martin von Gagern from comment #34) > Is asking for year-long concurrent sessions on multiple devices on-topic > here, is there a separate bug for this, should I file one or ask on Village > Pump? Filed as bug 67512.
Right now we have a bunch of CentralAuth code running on login to try and attach accounts which we can merge since we have access to the user's raw plaintext password, so I'd ask/request that this not move forward until alternative solutions are figured out for those processes.
(In reply to Kunal Mehta (Legoktm) from comment #38) > Right now we have a bunch of CentralAuth code running on login to try and > attach accounts which we can merge since we have access to the user's raw > plaintext password Are you automatically merging accounts with the same username and password? > so I'd ask/request that this not move forward until > alternative solutions are figured out for those processes. Hmm, I guess if you need people logging in regularly this has to be blocked by the SUL finalization bug.
(In reply to Matthew Flaschen from comment #39) > (In reply to Kunal Mehta (Legoktm) from comment #38) > > Right now we have a bunch of CentralAuth code running on login to try and > > attach accounts which we can merge since we have access to the user's raw > > plaintext password > > Are you automatically merging accounts with the same username and password? Yes.
