Last modified: 2014-09-25 06:06:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 47694 - "Remember me" on Login interface should state duration
"Remember me" on Login interface should state duration
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.22.0
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: i18n
: 60437 70348 (view as bug list)
Depends on:
Blocks: messages
  Show dependency treegraph
 
Reported: 2013-04-26 00:07 UTC by Thehelpfulone
Modified: 2014-09-25 06:06 UTC (History)
15 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Google 2-factor "remember me" text (22.72 KB, image/png)
2014-09-16 05:40 UTC, Matthew Flaschen
Details

Description Thehelpfulone 2013-04-26 00:07:22 UTC
On <https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page&useNew=1> next to the check box and the text "Remember me" the "(for a maximum of 30 days)" is missing. Perhaps we can shorten it to "(for 30 days)" or even "(30 days)".
Comment 1 MZMcBride 2013-04-26 00:07:54 UTC
Heh.
Comment 2 Amgine 2013-04-26 00:15:49 UTC
Should be value of $wgCookieExpiration
Comment 3 Matthew Flaschen 2013-04-26 00:18:22 UTC
If we show it, it should be based on the actual configuration.  But I'm not convinced this is necessary.  It's information on the page that might not need to be there.

If you don't feel comfortable with long-term cookies, you don't have to check it.  The exact time period is not strictly necessary to make this call.

Are there other sites that show the time period for this?
Comment 4 Thehelpfulone 2013-04-26 00:33:23 UTC
(In reply to comment #3)
> If we show it, it should be based on the actual configuration.  But I'm not
> convinced this is necessary.  It's information on the page that might not
> need
> to be there.

I'm not sure if there are legal reasons we show it, per the privacy policy at <https://wikimediafoundation.org/wiki/Privacy_policy#Cookies>. Perhaps something to confirm with LCA?

 
> If you don't feel comfortable with long-term cookies, you don't have to check
> it.  The exact time period is not strictly necessary to make this call.
> 
> Are there other sites that show the time period for this?

Hmm, do other top sites set expiring cookies for login?
Comment 5 Matthew Flaschen 2013-04-26 00:45:06 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > If we show it, it should be based on the actual configuration.  But I'm not
> > convinced this is necessary.  It's information on the page that might not
> > need
> > to be there.
> 
> I'm not sure if there are legal reasons we show it, per the privacy policy at
> <https://wikimediafoundation.org/wiki/Privacy_policy#Cookies>. Perhaps
> something to confirm with LCA?

CCed Luis Villa.  If they don't respond, my feeling is the "Privacy policy" link on every page footer is sufficient.

> > If you don't feel comfortable with long-term cookies, you don't have to check
> > it.  The exact time period is not strictly necessary to make this call.
> > 
> > Are there other sites that show the time period for this?
> 
> Hmm, do other top sites set expiring cookies for login?

I don't know the exact behavior, but for example Google ("Stay signed in"), Facebook ("Keep me logged in"), and Twitter ("Remember me") all have such a checkbox on log in, and none say the time period.
Comment 6 Luis Villa (WMF Legal) 2013-04-26 01:06:47 UTC
I don't believe there is a legal or policy requirement for this - the mention in the privacy policy should be sufficient (assuming, of course, that the two numbers match, which I believe they do now).
Comment 7 MZMcBride 2013-04-26 01:11:16 UTC
For the history here, I originally added the duration on the English Wikipedia. Other wikis followed and eventually the feature was integrated into MediaWiki core (where $1 could be used within the "Remembermypassword" MediaWiki message to output the value of $wgCookieExpiration).
Comment 8 Derk-Jan Hartman 2013-04-26 09:46:10 UTC
Slightly related btw; I like "Stay signed in" and "Keep me logged in" better than "Remember me". It's not just remembering you, it's also remembering your session. There is a difference. I find the FB and Google descriptions more descriptive and they are not too difficult for ppl I think.
Comment 9 Steven Walling 2013-04-26 17:40:43 UTC
(In reply to comment #8)
> Slightly related btw; I like "Stay signed in" and "Keep me logged in" better
> than "Remember me". It's not just remembering you, it's also remembering your
> session. There is a difference. I find the FB and Google descriptions more
> descriptive and they are not too difficult for ppl I think.

I think "Keep me logged in" is a viable option. Simple, obvious.
Comment 10 Steven Walling 2013-04-26 20:15:58 UTC
(In reply to comment #6)
> I don't believe there is a legal or policy requirement for this - the mention
> in the privacy policy should be sufficient (assuming, of course, that the two
> numbers match, which I believe they do now).

Okay, since there is no legal requirement to be loquacious about this, I'm going to say that we're not going to. We took this out intentionally because it's overly wordy, and doesn't substantially make it easier to make a decision about whether you want to stay logged in. The length of login persistence may change in the future with revisions to the privacy policy etc., and other versions where it was "180 days" were obtuse. 

I think Derk-Jan's suggestion for a wording change is a good one, I'll make sure that happens.
Comment 11 Isarra 2013-04-26 20:47:02 UTC
Most other sites may not say how long sessions last, but that does not make the information not useful when it indeed is a finite session - a reason to not say how long it lasts, for instance, would be if it weren't a finite session, such as where the cookie automatically renews on each visit - which may indeed be the case for those other sites mentioned, but it is not case with mediawiki.

So while not specifying the session time saves space, that space would not be otherwise wasted. Users tend to feel more comfortable with a system if they have a good mental model of it, and that means not being surprised - and suddenly finding oneself logged out is a pretty significant surprise. Just telling them from the start that the session only lasts so long helps avoid that surprise, and the note isn't a significant burden on the UI.
Comment 12 Steven Walling 2013-04-26 20:53:46 UTC
(In reply to comment #11)
> Most other sites may not say how long sessions last, but that does not make
> the
> information not useful when it indeed is a finite session - a reason to not
> say
> how long it lasts, for instance, would be if it weren't a finite session,
> such
> as where the cookie automatically renews on each visit - which may indeed be
> the case for those other sites mentioned, but it is not case with mediawiki.
> 
> So while not specifying the session time saves space, that space would not be
> otherwise wasted. Users tend to feel more comfortable with a system if they
> have a good mental model of it, and that means not being surprised - and
> suddenly finding oneself logged out is a pretty significant surprise. Just
> telling them from the start that the session only lasts so long helps avoid
> that surprise, and the note isn't a significant burden on the UI.

More information is not always an advantage, and short, simple messages provide a huge advantage to all users in reducing cognitive load when dealing with an interface of any sort. 

Our primary standard is for inclusion is, "Is this actually necessary to log in?". Obviously the answer for this entire element is "No". Thus we'd be adding complexity with a nice-to-have time description on a feature that's already a nice-to-have. Especially since the time element may change in the future or be configured differently by third party users, this is the simplest thing that works for all without adding complexity. 

I know the Wikimedian instinct is always to be 100% precise in all descriptions of things. I often have the same pull myself, but that's not always a good thing for interface design.
Comment 13 Isarra 2013-04-26 21:09:19 UTC
Would you say that "Keep me logged in for 30 days" is hugely disadvantageous? It's short, to the point, and should be immediately clear what it does.
Comment 14 Matt Walker 2013-04-26 21:12:15 UTC
(In reply to comment #12)
> Our primary standard is for inclusion is, "Is this actually necessary to log
> in?". Obviously the answer for this entire element is "No". Thus we'd be

I would argue the opposite -- a user who was logged in, but is now logged out will be asking "Why am I logged out?" which leads to the "Why am I being required to log in?" - a question the system should be prepared to answer.
Comment 15 Steven Walling 2013-04-26 21:13:37 UTC
(In reply to comment #14)
> (In reply to comment #12)
> > Our primary standard is for inclusion is, "Is this actually necessary to log
> > in?". Obviously the answer for this entire element is "No". Thus we'd be
> 
> I would argue the opposite -- a user who was logged in, but is now logged out
> will be asking "Why am I logged out?" which leads to the "Why am I being
> required to log in?" - a question the system should be prepared to answer.

"Keep me logged in" satisfies this need.
Comment 16 Isarra 2013-04-26 21:18:55 UTC
(In reply to comment #15)
> "Keep me logged in" satisfies this need.

It only keeps one logged in for $wgCookieExpiration. It should specify that it lasts for $wgCookieExpiration - for instance by saying "Keep me logged in for 30 days" instead.
Comment 17 Matt Walker 2013-04-26 21:29:19 UTC
(In reply to comment #15)
> "Keep me logged in" satisfies this need.

Keep me logged in implies perpetuity. Which is what triggers the confusion when someone is logged out.

Look at a service like Gmail -- initially it says "keep me logged in" because it will. But if you have two factor auth; it then gives you a new form that specifically says "Remember this computer for 30 days."

The expectations are completely different and we should be managing that.
Comment 18 Gerrit Notification Bot 2013-04-27 05:01:29 UTC
Related URL: https://gerrit.wikimedia.org/r/61168 (Gerrit Change I7cfa4bb36368277a934144c1724ec437c426eacf)
Comment 19 MZMcBride 2013-04-27 21:19:50 UTC
(In reply to comment #12)
> Especially since the time element may change in the future or be configured
> differently by third party users, this is the simplest thing that works for
> all without adding complexity. 

I personally think your use of weasel wording here is pretty nasty and uncalled for. You know that this problem was already solved in the previous login form (the one that you and your team are attempting to replace) by using a "$1" variable in the MediaWiki message that was substituted with the value of $wgCookieExpiration. And if somehow you managed to redesign this form without knowing that, I said as much in comment 7 of this bug.

You can make your point about interface simplicity without being intentionally misleading or constructing false implementation obstacles.

What's worse is that if we move forward without proper support for this functionality (using a "$1" variable), local wikis _will_ in fact hardcode the cookie expiration in their MediaWiki messages (as they did previously).
Comment 20 MZMcBride 2013-04-27 21:28:48 UTC
(In reply to comment #19)
> What's worse is that if we move forward without proper support for this
> functionality (using a "$1" variable), local wikis _will_ in fact hardcode
> the cookie expiration in their MediaWiki messages (as they did previously).

Never mind! It seems that your concern about additional code complexity was so farfetched that someone already implemented "$1" variable support in this new MediaWiki message. You can see it in action here: <https://test.wikipedia.org/wiki/Special:UserLogin?useNew=1>. It uses this message: <https://test.wikipedia.org/wiki/MediaWiki:Userlogin-remembermypassword>.

Thehelpfulone: is your goal to have the _default_ message value include the "$1" variable that's substituted with the value of $wgCookieExpiration or is your goal simply to have this functionality available on a per-wiki basis?
Comment 21 Thehelpfulone 2013-04-27 21:37:51 UTC
(In reply to comment #20)

> Thehelpfulone: is your goal to have the _default_ message value include the
> "$1" variable that's substituted with the value of $wgCookieExpiration or is
> your goal simply to have this functionality available on a per-wiki basis?

Yes, I think it'd be a good idea to include this as default on all wikis,  to match existing behaviour and for consistency (it doesn't add too much extra to the   new interface in my opinion). Perhaps we could just upstream your change to MediaWiki:Userlogin-remembermypassword?
Comment 22 Nemo 2013-08-11 10:42:20 UTC
This request for a handful more characters on login seems quite straightforward; 4 months later, can we proceed or are fingers still heated?
Comment 23 Steven Walling 2013-08-15 01:10:42 UTC
(In reply to comment #22)
> This request for a handful more characters on login seems quite
> straightforward; 4 months later, can we proceed or are fingers still heated?

It's still a bad idea. 

1). The "30 days" is likely change to be much longer, or indefinite, if you check the box. It's one of the pieces of privacy policy feedback that keeps coming in, and with a revision to the policy going to be published for community input soon, there's not much point in specifying something that may not need to be specified soon. 

2). Knowing how long doesn't actually help you make a decision. Either you do or do not want to be remembered. If you do, the amount of time doesn't matter. If you don't (such as for being on a shared system), it doesn't matter if it's 30 days or 2. 

This is another case where details don't help you make a choice, but we're being pushed to carry over legacy content despite the fact that most people agreed that the legacy message ("remember me for 180 days") was bizarre and unnecessary.
Comment 24 Nemo 2013-08-15 16:34:46 UTC
(In reply to comment #23)
> (In reply to comment #22)
> > This request for a handful more characters on login seems quite
> > straightforward; 4 months later, can we proceed or are fingers still heated?
> 
> It's still a bad idea. 
> 
> 1). The "30 days" is likely change to be much longer, or indefinite, if you
> check the box. It's one of the pieces of privacy policy feedback that keeps
> coming in, and with a revision to the policy going to be published for
> community input soon, there's not much point in specifying something that may
> not need to be specified soon.

I don't understand this point. The cookie expiry is set now, not in the future. Are you saying it can be changed retroactively?

> 
> 2). Knowing how long doesn't actually help you make a decision. Either you do
> or do not want to be remembered. If you do, the amount of time doesn't
> matter.

It does when you find yourself logged out. It also helps understanding the impact of your choice; for instance, I personally allow most sites to keep cookies for one browser session only, and I am happier if their cookie expires earlier.

> If you don't (such as for being on a shared system), it doesn't matter if
> it's
> 30 days or 2. 
> 
> This is another case where details don't help you make a choice, but we're
> being pushed to carry over legacy content despite the fact that most people
> agreed that the legacy message ("remember me for 180 days") was bizarre and
> unnecessary.

This is just an assumption so I won't reply.
Comment 25 Amgine 2013-08-15 17:51:21 UTC
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #22)
> > 1). The "30 days" is likely change to be much longer, or indefinite, if you
> > check the box. ...
> 
> I don't understand this point. The cookie expiry is set now, not in the
> future.
> Are you saying it can be changed retroactively?

I suspect the person is unaware that value would be the wiki's configuration value, and made the assumption it would be hard-coded into the skin.
Comment 26 Matthew Flaschen 2013-08-15 18:17:13 UTC
Right, we don't need to hard-code it; we would use the configuration.  The issue is just whether it helps the user to show it.  I.E. is it good UX?
Comment 27 Amgine 2013-08-15 19:21:01 UTC
(In reply to comment #26)
> Right, we don't need to hard-code it; we would use the configuration.  The
> issue is just whether it helps the user to show it.  I.E. is it good UX?

heh. Not a UX expert. But my n of one is slightly more confident when I know the cookie isn't indefinite.
Comment 28 Steven Walling 2013-08-15 20:44:53 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > (In reply to comment #22)
> > > 1). The "30 days" is likely change to be much longer, or indefinite, if you
> > > check the box. ...
> > 
> > I don't understand this point. The cookie expiry is set now, not in the
> > future.
> > Are you saying it can be changed retroactively?
> 
> I suspect the person is unaware that value would be the wiki's configuration
> value, and made the assumption it would be hard-coded into the skin.

Nope, I know it's not hard coded. What I was talking about is the justification for including it.

As Matt correctly points out in comment 17, this is partially about managing expectations. If you look at it from that point of view, you could say that people expect "remember me" to work for an indefinite period, since that's how it works most other places if you choose that option. If it's likely that we change our config to be the same based on a privacy policy revision, then there's no need to say something extra, because it fits with the usual mental model of what such a checkbox does.
Comment 29 Nemo 2013-08-15 21:06:25 UTC
(In reply to comment #28)
> 
> Nope, I know it's not hard coded. What I was talking about is the
> justification
> for including it.
> 
> As Matt correctly points out in comment 17, this is partially about managing
> expectations. If you look at it from that point of view, you could say that
> people expect "remember me" to work for an indefinite period, since that's
> how
> it works most other places if you choose that option. If it's likely that we
> change our config to be the same based on a privacy policy revision, then
> there's no need to say something extra, because it fits with the usual mental
> model of what such a checkbox does.

You realize that all this privacy policy change argument carries no value for a bug in MediaWiki product which shall consider only the MediaWiki default, don't you?
Comment 30 Steven Walling 2013-08-15 21:14:53 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > 
> > Nope, I know it's not hard coded. What I was talking about is the
> > justification
> > for including it.
> > 
> > As Matt correctly points out in comment 17, this is partially about managing
> > expectations. If you look at it from that point of view, you could say that
> > people expect "remember me" to work for an indefinite period, since that's
> > how
> > it works most other places if you choose that option. If it's likely that we
> > change our config to be the same based on a privacy policy revision, then
> > there's no need to say something extra, because it fits with the usual mental
> > model of what such a checkbox does.
> 
> You realize that all this privacy policy change argument carries no value
> for a
> bug in MediaWiki product which shall consider only the MediaWiki default,
> don't
> you?

No, this bug is primarily about what's on Wikimedia projects. That's what Thehelpfulone was asking about in the original comment, why Luis commented about privacy as well, and why MZ's solution was to locally change the enwiki message. I could care less if someone wants to change the MediaWiki default as long as they leave Wikimedia projects untouched.
Comment 31 Nemo 2013-08-15 21:35:19 UTC
(In reply to comment #30)
> No, this bug is primarily about what's on Wikimedia projects. That's what
> Thehelpfulone was asking about in the original comment, why Luis commented
> about privacy as well, and why MZ's solution was to locally change the enwiki
> message. I could care less if someone wants to change the MediaWiki default
> as
> long as they leave Wikimedia projects untouched.

Those are just examples, while your recurring argument is only about WMF wikis; this bug has never been in WikimediaMessages component or Wikimedia product, IIRC. That said, sure, many of the comments here have gone off track.
I don't care much about this request (I was originally against it, it seems) but I still don't see compelling arguments to reject the addition of a handful characters to core.

Then, this can be closed and a bug filed for WikimediaMessages if you wish; or this can be ignored for core and moved to somewhere else. Whatever eliminates this from my bug 38638 backlog is fine, thanks.
Comment 32 Raimond Spekking 2013-08-16 07:38:01 UTC
I remember that I added the value of $wgCookieExpiration to the login form some years ago because there were ongoing questions on the Germen Village Pump about "how long is the login valid?"

Therefore I think it would be a good idea to re-add this information.
Comment 33 Aravind K N 2014-01-25 09:28:40 UTC
Isn't this fixed?
Comment 34 Kevin Israel (PleaseStand) 2014-01-25 09:40:06 UTC
(In reply to comment #33)
> Isn't this fixed?

No. In MediaWiki core, the "userlogin-remembermypassword" message is still
just "Keep me logged in", though at least English Wikipedia has overridden
it to add "(for up to $1 {{PLURAL:$1|day|days}})".
Comment 35 Aravind K N 2014-01-25 10:17:54 UTC
Would you tell me what I'm supposed to do to fix this bug?
Comment 36 Andre Klapper 2014-01-25 17:23:07 UTC
Aravind: Find the string yourself in the codebase, change it (see comment 0 and 34 for hints), and put a patch into Gerrit.
Comment 37 Steven Walling 2014-01-26 07:16:34 UTC
(In reply to comment #35)
> Would you tell me what I'm supposed to do to fix this bug?

I am closing this bug as I should have done a long time ago, per the reasoning in comment 10

If an individual community wants to disagree with the MediaWiki default, then they can customize it like English Wikipedia has. This should not be changed in core.
Comment 38 Isarra 2014-01-26 08:25:36 UTC
I've filed bug 60437 about having a duration at all.
Comment 39 Kevin Israel (PleaseStand) 2014-01-26 13:46:01 UTC
MZMcBride, the "easy" keyword should not be used for issues for which
the fix is controversial, including those that someone at the WMF would
likely mark RESOLVED WONTFIX. It doesn't make sense to consider these
to be "Issues recommended to try for new developers".
Comment 40 Thehelpfulone 2014-01-26 18:42:50 UTC
So looking through the comments, I see the following breakdown:

Support: Myself, MZMcBride, Nemo, Amgine, Isarra, Matt Walker, Raimond

Opposition: Steven Walling, Matt F (weak)

It seems to be Steven you're the only person that's strongly opposed against this idea - the rest of the people that have commented on this bug (who are from a wide range of projects/locations) support this change.

I don't think that this change should be opposed on the basis of *one* person's opposition - we work with consensus. Furthermore, by telling the user that we are going to keep them logged in, then logging them out after 30 days we are effectively lying to them - can you tell me that's good UX?
Comment 41 Isarra 2014-01-26 19:20:10 UTC
While Thehelpfulone makes good points, I wasn't opposed to closing this bug specifically since according to the bug description/title way up there, it is resolved (hence why I just opened a new bug for the issue that we're poking at now), but... eh. Trying to move a discussion can be iffy and we're all already here so I just don't know.

Andre! What do you think?
Comment 42 Steven Walling 2014-01-26 21:23:37 UTC
(In reply to comment #40)
> Furthermore, by telling the user that we
> are going to keep them logged in, then logging them out after 30 days we are
> effectively lying to them - can you tell me that's good UX?

Yes, I can elaborate. 

The goal of the checkbox is to help user stay logged in for longer than their normal browser session. The label should provide only as much information is needed for the user to decide, "Do I want to have this site remember my login on this computer?" 

1. When asking about good UX in log in forms, etc. we can obviously look to other sites, since we are far from the only people to have a user registration systems. I cannot find a _single_ good example of a login form which specifies an exact time limit on saved login sessions, even if cookie policies may differ. This obviously supports the view that it would be unusual to present this, and probably unnecessary. 

2. Even without differences in cookie policies, the information is not necessary to decide "Do I want this site to remember me?". It's a simple yes or no state. The user does not 

3. The fact that our cookie policy only allows for 30 days of remembering a user _even if_ they opt in to being remembered is a broken UX. Numerous users have complained about this, and with the upcoming privacy policy we will not need to have a hard 30 day limit on cookies. This will soon make the need to specify a time limit completely unnecessary, because our cookie policy for users who opt-in via this checkbox will be just like other sites. 

4. Regardless of what time period the cookie lasts, we are fulfilling the user's request to be remembered beyond the normal session. The idea that we're lying to users without the 30 day mention is absurd. 

TL;DR: this will soon be obviated by the new privacy policy which won't require 30 day limits on cookies, and it's unnecessary information for the user to be able to make a decision about whether they do or do not want to be remembered.
Comment 43 Steven Walling 2014-01-26 21:25:09 UTC
(In reply to comment #42)

> 2. Even without differences in cookie policies, the information is not
> necessary to decide "Do I want this site to remember me?". It's a simple yes
> or
> no state. The user does not 
> 

Sorry, got clipped. The final sentence is, "The user does not have multiple options, only a binary state."
Comment 44 Nemo 2014-01-26 21:26:47 UTC
(In reply to comment #42)
> [...] with the upcoming privacy policy we will not
> need to have a hard 30 day limit on cookies. [...]

Note: possibly upcoming, may not need.
Comment 45 Matthew Flaschen 2014-01-28 05:09:23 UTC
(In reply to comment #5)
> I don't know the exact behavior, but for example Google ("Stay signed in"),
> Facebook ("Keep me logged in"), and Twitter ("Remember me") all have such a
> checkbox on log in, and none say the time period.

For the record, Google still just says "Stay signed in"; they have a finite but long expiration (two years for what seem to be the main cookies, but shorter for another one that is not impacted by "Stay signed in".

For Facebook, the main cookie expires in one month if it's checked, similar to our current behavior.
Comment 46 MZMcBride 2014-01-28 05:27:03 UTC
I find comment 40 compelling.

Steven: while I understand that you personally disagree here, the reality is that MediaWiki core supports this functionality and the English Wikipedia uses it (cf. [[MediaWiki:Userlogin-remembermypassword]]). Given these two facts, it's reasonable to consider including the duration in the default message, in my opinion. And both current consensus (on this bug report) and past consensus (the duration was previously included by default, as I recall) seem to agree here. Please do not mark this bug as resolved/wontfix again.

(In reply to comment #39)
> MZMcBride, the "easy" keyword should not be used for issues for which
> the fix is controversial, including those that someone at the WMF would
> likely mark RESOLVED WONTFIX. It doesn't make sense to consider these
> to be "Issues recommended to try for new developers".

Kevin: I'm not sure one Wikimedia Foundation staffer objecting makes this controversial. As comment 40 summarizes, consensus seems fairly clear here. This bug _is_ trivial to resolve, but if it's somehow still inexplicably a political issue to resolve this bug, then you're correct that we can safely drop the "easy" keyword here.
Comment 47 Steven Walling 2014-01-28 05:52:58 UTC
(In reply to comment #46)
> I find comment 40 compelling.
> 
> Steven: while I understand that you personally disagree here, the reality is
> that MediaWiki core supports this functionality and the English Wikipedia
> uses
> it (cf. [[MediaWiki:Userlogin-remembermypassword]]). Given these two facts,
> it's reasonable to consider including the duration in the default message, in
> my opinion. And both current consensus (on this bug report) and past
> consensus
> (the duration was previously included by default, as I recall) seem to agree
> here. Please do not mark this bug as resolved/wontfix again.
> 

This is not a system where we just do what the most people commenting on the bug happen to like. We do the right thing by users. The right thing for a label description is _clarity_. Clarity is not necessarily comprehensive detail, but providing the user: 

- What essential information they need to make decisions, and no more
- What they expect, which is largely shaped by their experiences on other sites

Since it is completely obvious that you don't need to know the time period to make a decision, and literally no one has been able to provide a relevant example of another site that follows the practice being recommended, it makes no sense to revert back to the historic practice of declaring what is obviously superfluous information. Providing this information is a good example of "implementation model" rather than "mental model", meaning shaping the user interface to exactly match how the system functions behind the scenes, rather than what the user expects and needs.[1][2]

To make myself crystal clear here: I am not arguing we should be shaping core to what English Wikipedia needs. Excessively detailed copy and unnecessary logic to include the value of the cookie expiration is a bad user experience for any MediaWiki installation. 

1. http://www.uxpassion.com/blog/strategy-concepts/implementation-mental-representation-models-ux-user-experience
2. http://www.sfs.uni-tuebingen.de/~cculy/courses/S2012/visDesignEval/presentations/Chapter_2_Daniil_Sorokin.pdf
Comment 48 Isarra 2014-01-28 06:16:55 UTC
*** Bug 60437 has been marked as a duplicate of this bug. ***
Comment 49 Isarra 2014-01-28 06:39:47 UTC
(In reply to comment #45)
> 
> For the record, Google still just says "Stay signed in"; they have a finite
> but long expiration...

Aye, indefinite ones or very long ones probably wouldn't need to be specified.

Copying what I said on Bug 60437 over to here (sorry about it winding up over there initially):

The expiry time should not be displayed if it's set to indefinite. This may also apply if it's set to a sufficiently long duration (for instance if it expires after 6 months, that may well be plenty that it doesn't really matter anymore), though what the boundary would be, or if this is indeed that case, is more up in the air.

It is most important to specify the duration where it is shorter, such as of a week (wikitech), 30 days (wikipedia), etc. There, the logins will be expiring quite frequently, and for the users, quite unexpectedly: if they told it to keep them logged in, it will appear to them that they are being logged out after they specifically told it to not log them out, because that's what it said.

> For Facebook, the main cookie expires in one month if it's checked, similar
> to our current behavior.

Hey, just because Facebook does something, that doesn't mean it's a good idea. I mean, yeah, I doubt it causes them any real problems, but we can still do better.


(In reply to comment #47)

You're wrong. Stating that things are completely obvious does not make you not wrong. Interestingly, if you revert again, you'll be past three reverts on this bug. You're from Wikipedia, right? They have a rather neat three revert rule...
Comment 50 MZMcBride 2014-01-28 06:44:36 UTC
(In reply to comment #49)
> The expiry time should not be displayed if it's set to indefinite. This may
> also apply if it's set to a sufficiently long duration (for instance if it
> expires after 6 months, that may well be plenty that it doesn't really matter
> anymore), though what the boundary would be, or if this is indeed that case,
> is more up in the air.
> 
> It is most important to specify the duration where it is shorter, such as of
> a week (wikitech), 30 days (wikipedia), etc. There, the logins will be
> expiring quite frequently, and for the users, quite unexpectedly: if they told
> it to keep them logged in, it will appear to them that they are being logged
> out after they specifically told it to not log them out, because that's what
> it said.

This seems sensible.
Comment 51 Nemo 2014-01-28 07:21:57 UTC
Agreed. I think Steven is only bothered that if we mention an expiration explicitly people will get used to it, barring his plans to raise the cookie length. Isarra's proposal should make everyone happy.
Comment 52 Steven Walling 2014-01-28 08:59:43 UTC
(In reply to comment #51)
> Agreed. I think Steven is only bothered that if we mention an expiration
> explicitly people will get used to it, barring his plans to raise the cookie
> length. Isarra's proposal should make everyone happy.

Please don't read ulterior motives in to what I'm saying on the bug. 

Isarra's proposal is not reasonable. You want us to add logic for displaying the cookie expiration, while also saying "though what the boundary would be" for actually showing it is "up in the air". This is not a specification for a patch, it's vague handwaving.
Comment 53 Nemo 2014-01-28 09:08:09 UTC
(In reply to comment #52)
> Please don't read ulterior motives in to what I'm saying on the bug.

You talked so much in this bug that there's no need to invent anything. :) See in particular your comment 28; but also comment 10, comment 12, comment 23, comment 30.
Comment 54 Nemo 2014-01-28 09:13:39 UTC
(In reply to comment #28)
> If it's likely that we
> change our config to be the same based on a privacy policy revision, then
> there's no need to say something extra

Before Steven says I'm reading too much into this, here he states A -> B, Isarra et al. state ¬B. But Steven's sentence is equivalent to ¬B -> ¬A, hence the logic translation of his concerns is what I said in comment 51. :)
Comment 55 Bartosz Dziewoński 2014-01-29 14:38:22 UTC
As I said on bug 60437 already, I also think Isarra's proposal in comment 49 here is the best solution.
Comment 56 Isarra 2014-01-29 23:42:03 UTC
(In reply to comment #52)
> Isarra's proposal is not reasonable. You want us to add logic for displaying
> the cookie expiration, while also saying "though what the boundary would be"
> for actually showing it is "up in the air". This is not a specification for a
> patch, it's vague handwaving.

Development is not an exact science. This is why iteration is so popular. If you've ever done anything Agile, it's all about iteration.

Now I don't know what random number is best so I'm not going to specify a specific random number, but at this point it really doesn't matter what it is anyway. We need the logic first, and if the logic is there, we can then just pick anything for the cutoff number, 182 days, a year, whatever. If it turns out to be a bad number, people will complain and we can change it. An iteration, see?

Changing a variable is easy. We do it all the time.
Comment 57 Gerrit Notification Bot 2014-01-30 00:54:56 UTC
Change 110279 had a related patch set uploaded by Bartosz Dziewoński:
"Keep me logged in" on Special:UserLogin should sometimes state duration

https://gerrit.wikimedia.org/r/110279
Comment 58 MZMcBride 2014-01-30 02:53:23 UTC
Hmmm, four wontfixes here:

* 2014-01-26 07:16:34 UTC comment 37
* 2014-01-26 21:23:37 UTC comment 42
* 2014-01-28 05:52:58 UTC comment 47
* 2014-01-28 08:59:43 UTC comment 52

Bartosz's patch came in at comment 57. Fun pattern. :-)
Comment 59 Tyler Romeo 2014-01-30 05:33:13 UTC
Speaking directly from [[mw:Bug management/Bugzilla etiquette]], "bug status, priority, and target milestone fields summarize and reflect reality and do not cause it".

With that in mind I ask that this "edit war" of sorts on this bug please stop. It is extremely obvious that, at the very least, the outcome of this bug is disputed. Thus closing it as WONTFIX is unproductive and aggressive.

To the contrary, I recommend that this discussion be taken to a more public forum, e.g., the mailing list, where it is more likely to get a wider range of responses and criticisms.
Comment 60 Nemo 2014-01-30 09:03:30 UTC
I'm not sure whether this bug should be fixed or not, even though Isarra's compromise is sensible, because I agree that in an ideal world we'd just have a checkbox "remind me forever" with unanimous research telling us that N days feels exactly like forever/what the users think forever (or "forever enough") and MediaWiki would set expiry accordingly. However, I doubt this is possible: for some users "forever" is 2 years renewing at every visit (like Google), for others 1 week is already a painfully long time. See also below.

This said, it seems Steven lacks an answer on this point:

(In reply to comment #59)
> I cannot find a _single_ good example of a login form which
> specifies
> an exact time limit on saved login sessions, even if cookie policies may
> differ. This obviously supports the view that it would be unusual to present
> this, and probably unnecessary.

As most arguments where Steven uses the word "obviously", this is IMHO a very weak and disputable one. Cookies are one of the least honest businesses of the internet and few or no websites are straightforward with their users about them (though this is getting better in EU thanks to recent directives): however, MediaWiki's ethical standards are higher than the average and we shouldn't blindly follow bad practices, however common they might be.
Best example of dishonesty has always been Google (which triggered the EU directive):
https://www.eff.org/deeplinks/2007/07/edition-privacy-theater-googles-cookie-monster
http://edri.org/edrigramnumber5-15search-engine-privacy/
Many users are bothered, as the number of featured browser extensions with hundreds thousands users show:
https://addons.mozilla.org/it/firefox/addon/betterprivacy/
https://addons.mozilla.org/it/firefox/addon/anonymox/
https://addons.mozilla.org/en/firefox/addon/self-destructing-cookies/

On the other hand, other users just hate logging in and whatever expiry you pick will make someone unhappy. This bug is IMHO about acknowledging that no expiry is perfect and that we must let the users decide. For the cost of 6 characters or so on the login form, yes.
Comment 61 Steven Walling 2014-01-30 09:42:58 UTC
(In reply to comment #60)
> 
> (In reply to comment #59)
> > I cannot find a _single_ good example of a login form which
> > specifies
> > an exact time limit on saved login sessions, even if cookie policies may
> > differ. This obviously supports the view that it would be unusual to present
> > this, and probably unnecessary.
> 
> As most arguments where Steven uses the word "obviously", this is IMHO a very
> weak and disputable one. Cookies are one of the least honest businesses of
> the
> internet and few or no websites are straightforward with their users about
> them
> (though this is getting better in EU thanks to recent directives): however,
> MediaWiki's ethical standards are higher than the average and we shouldn't
> blindly follow bad practices, however common they might be.
> Best example of dishonesty has always been Google (which triggered the EU
> directive):
> https://www.eff.org/deeplinks/2007/07/edition-privacy-theater-googles-cookie-
> monster
> http://edri.org/edrigramnumber5-15search-engine-privacy/
> Many users are bothered, as the number of featured browser extensions with
> hundreds thousands users show:
> https://addons.mozilla.org/it/firefox/addon/betterprivacy/
> https://addons.mozilla.org/it/firefox/addon/anonymox/
> https://addons.mozilla.org/en/firefox/addon/self-destructing-cookies/
> 

We're discussing about setting a long term login cookie for users who opt-in, not auto-renewing cookies or any number of other scummy things in the post you link to. Users already get to decide. We're talking about how to choose the clearest language to describe the choice they're making. Matching user expectations by using similar language that is familiar to them from the same generic interface on other popular sites helps users make a decision quickly and without needing to read excess detail like "keep me logged in for 180 days".  

No one here has actually presented a real-world complaint from users, about how they can't use the login form because it doesn't precisely specify the length of a login session. That's because it doesn't happen. Most users don't really care exactly how many days you remember them when they're trying to finish the login process quickly and without having to think much about it. They either want their session to expire, or to be remembered. (Yes, we all use MediaWiki. We're also all technical people commenting here, many of us people who submit patches. We don't represent what most average users need and expect.)
Comment 62 Raimond Spekking 2014-01-30 10:08:30 UTC
(In reply to comment #61)
> 
> We're discussing about setting a long term login cookie for users who opt-in,
> not auto-renewing cookies or any number of other scummy things in the post
> you
> link to. 

We are discussing a core functionality if MediaWiki. I have the feesling that you are talking about Wikipedia and the upcoming long term cookie for it only.


> No one here has actually presented a real-world complaint from users, about
> how
> they can't use the login form because it doesn't precisely specify the length
> of a login session. 

Probably because the latest MediaWiki release with the new login form is not very often deployed to third parties. Especially companies do not very often update a MediaWiki installation.

And I can confirm, that some of the installations I care for are using very different cookie lifetime settings. Between some days and some weeks. Depending on the security rules of the company. But I am not able to link to them because most of them are in an intranet, not public available.
Comment 63 Bartosz Dziewoński 2014-01-30 12:23:27 UTC
(In reply to comment #62)
> We are discussing a core functionality if MediaWiki. I have the feesling that
> you are talking about Wikipedia and the upcoming long term cookie for it
> only.

The MediaWiki default is 180 days already, which is sensible unlike the Wikimedia default which is currently 30 days.
Comment 64 Amgine 2014-01-31 17:16:49 UTC
(In reply to comment #61)
> (In reply to comment #60)
> > 
> > (In reply to comment #59)
...snip
> > > differ. This obviously supports the view that it would be unusual to present
> > > this, and probably unnecessary.

The above argument is the same argument as

> > Many users are bothered, as the number of featured browser extensions with
> > hundreds thousands users show:
> > https://addons.mozilla.org/it/firefox/addon/betterprivacy/
> > https://addons.mozilla.org/it/firefox/addon/anonymox/
> > https://addons.mozilla.org/en/firefox/addon/self-destructing-cookies/

And both arguments, being based on deduction, obviate this argument:

> No one here has actually presented a real-world complaint from users, about
> how
> they can't use the login form because it doesn't precisely specify the length
> of a login session. That's because it doesn't happen. 


The rest of that comment was speculative (although I happen to agree with it.)

The question is not about cookie life, but about displaying that cogently to the user. The real question is: is this a real problem? for some users it is because they have reported it as a problem. No one previously reported the existence of the text as a problem; it was a change made without an outside (user) instigation (at least, I never saw a bug report about it.)

The heat in these comments suggests it's a real issue, too.
Comment 65 Matthew Flaschen 2014-09-16 05:40:58 UTC
Created attachment 16479 [details]
Google 2-factor "remember me" text

(In reply to Matt Walker from comment #17)
> (In reply to comment #15)
> > "Keep me logged in" satisfies this need.
> 
> Keep me logged in implies perpetuity. Which is what triggers the confusion
> when someone is logged out.
> 
> Look at a service like Gmail -- initially it says "keep me logged in"
> because it will. But if you have two factor auth; it then gives you a new
> form that specifically says "Remember this computer for 30 days."

Is this still the case?  This is a different use case anyway, because it's a distinct feature (this computer is particularly private, so I don't want to enter my 2-factor code every time) from the regular login screen.

However, it looks like they're using (screenshot attached), "Don't ask for codes again on this computer" now unless we're considering different forms.
Comment 66 Isarra 2014-09-25 06:06:45 UTC
*** Bug 70348 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links