| • bzimport | |
| Apr 26 2013, 12:07 AM |
| F4358485: google-remember.png | |
| Aug 13 2016, 2:10 AM |
| F10961: Google_2-factor.png | |
| Nov 22 2014, 1:40 AM |
Author: Thehelpfulonewiki
Description:
On https://en.wikipedia.org/w/index.php?title=Special:UserLogin&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)".
See Also:
T62437: 'Keep me logged in' checkbox should specify expiry time (if any)
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Invalid | None | T40638 [DO NOT USE] Interface messages needing rewording or documentation and other issues with existing messages [superseded by #Voice_&_Tone] | ||
| Open | None | T49694 "Remember me" on Login interface should state duration | ||
| · · · |
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?
Thehelpfulonewiki wrote:
(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?
(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.
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).
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).
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.
swalling wrote:
(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.
swalling wrote:
(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.
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.
swalling wrote:
(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.
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.
mwalker wrote:
(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.
swalling wrote:
(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 beI 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.
(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.
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.
(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}})".
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.
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?"
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)
- 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:
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.
(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
Hmmm, four wontfixes here:
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:
To sum up the arguments against the change, and (IMO) the problems with them:
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.
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.
The value of $wgCookieExpiration has been 180 days since rMW7d7ebfc93a3721eba51c647ae705bdeab9307cb1 from August 2011. Wikimedia switched back to 30 days in rOMWCe28970a768b00e356d40725f174afd9b4abdef1b from March 2013.
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.