mwalker wrote:

(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.

Related URL: https://gerrit.wikimedia.org/r/61168 (Gerrit Change I7cfa4bb36368277a934144c1724ec437c426eacf)

(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).

(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?

Thehelpfulonewiki wrote:

(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?

This request for a handful more characters on login seems quite straightforward; 4 months later, can we proceed or are fingers still heated?

swalling wrote:

(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.

(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.

wmf.amgine3691 wrote:

(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.

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?

wmf.amgine3691 wrote:

(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.

swalling wrote:

(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.

(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?

swalling wrote:

(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.

(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.

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.

aravikn wrote:

Isn't this fixed?

(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}})".

aravikn wrote:

Would you tell me what I'm supposed to do to fix this bug?

Aravind: Find the string yourself in the codebase, change it (see comment 0 and 34 for hints), and put a patch into Gerrit.

swalling wrote:

(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.

I've filed bug 60437 about having a duration at all.

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".

Thehelpfulonewiki wrote:

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?

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?

swalling wrote:

(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.

swalling wrote:

(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."

(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.

(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.

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.

swalling wrote:

(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

• Bug 60437 has been marked as a duplicate of this bug. ***

(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...

(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.

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.

swalling wrote:

(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.

(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.

(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. :)

As I said on bug 60437 already, I also think Isarra's proposal in comment 49 here is the best solution.

(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.

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

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. :-)

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.

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.

swalling wrote:

(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.)

(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.

(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.

wmf.amgine3691 wrote:

(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.

Created attachment 16479
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.

Attached:

• Bug 70348 has been marked as a duplicate of this bug. ***

To sum up the arguments against the change, and (IMO) the problems with them:

• MediaWiki (or Wikimedia?) will change to indefinite password length, making the duration meaningless - that did not happen and AFAIK is not currently planned to happen
• Wikimedia is about to increase password length to 1 year (T68699) which is long enough that it should be considered practically infinite - maybe, but that's not relevant for a discussion about a core change; at most it's a reason to hide the duration via WikimediaMessages or some similar mechanism, or display it selectively based on some limit. There is no plan to change the core default of 30 days.
• other big sites don't do it - the examples were questionable: Facebook remembers users for a very long time (right now they use 90-day cookie expiration but extend the cookies whenever you visit). Google also remembers practically forever and only repeats the 2FA check and does show the duration there (screenshot: F4358485) although it might be different for users with no 2FA. (Did not check Twitter.)
• Our primary standard is for inclusion is, "Is this actually necessary to log in?" - that's clearly not the case, as the whole checkbox is unnecessary for login and nevertheless displayed. Helping users understand the system and make it seem less random is good UX.

So I don't think any of those arguments are strong enough to overturn consensus.

In T49694#2550035, @Tgr wrote:

There is no plan to change the core default of 30 days.

The core default is 180 days.

In T49694#2550035, @Tgr wrote:

So I don't think any of those arguments are strong enough to overturn consensus.

I'm not sure which consensus you're referring to overturning. The English Wikipedia continues to have "Keep me logged in (for up to 30 days)" at https://en.wikipedia.org/wiki/Special:UserLogin. I imagine other wikis do as well?

If we removed the checkbox altogether, the duration discussion would become moot.

In T49694#2550035, @Tgr wrote:

• MediaWiki (or Wikimedia?) will change to indefinite password length, making the duration meaningless - that did not happen and AFAIK is not currently planned to happen

I still think we should at least consider this idea. Do you think a separate task should be filed to focus on this (an auto-extending cookie expiry) specifically?

• Wikimedia is about to increase password length to 1 year (T68699) [...]

I guess I'm behind on that task. When I last looked, I remember objections to setting such a long cookie.

In T49694#2550506, @matmarex wrote:

The core default is 180 days.

Uh... I should probably have checked that first. Don't mind me then :)

In T49694#2551236, @MZMcBride wrote:

I still think we should at least consider this idea. Do you think a separate task should be filed to focus on this (an auto-extending cookie expiry) specifically?

Sure.

In T49694#2551246, @Tgr wrote:

In T49694#2550506, @matmarex wrote:

The core default is 180 days.

Uh... I should probably have checked that first. Don't mind me then :)

The value of $wgCookieExpiration has been 180 days since rMW7d7ebfc93a3721eba51c647ae705bdeab9307cb1 from August 2011. Wikimedia switched back to 30 days in rOMWCe28970a768b00e356d40725f174afd9b4abdef1b from March 2013.

In T49694#2551246, @Tgr wrote:

In T49694#2551236, @MZMcBride wrote:

I still think we should at least consider this idea. Do you think a separate task should be filed to focus on this (an auto-extending cookie expiry) specifically?

Sure.

That is T143019: Consider alternative cookie schemes for keeping users logged in.

In T49694#2558468, @Mattflaschen-WMF wrote:

That is T143019: Consider alternative cookie schemes for keeping users logged in.

Sweet, thank you!

I'm a bit confused by this issue. Judging by its title and description, isn't it the same as T62437? And if so, isn't it resolved already? If not, it probably needs clarification.

In T49694#3136685, @waldyrious wrote:

I'm a bit confused by this issue. Judging by its title and description, isn't it the same as T62437? And if so, isn't it resolved already? If not, it probably needs clarification.

I think it's just a relic of the bugzilla import; T62437 was apparently closed as a duplicate, not actually resolved, but that wasn't properly reflected in the status.

Oops.