Topics

moderated Update login expiration on site visit #suggestion

 

Mark,

Background:

There's been some discussion in GMF about the current login mechanism, in particular dissatisfaction with the user experience of having one's login suddenly evaporate (30 days after your last login) even though one has recently - even a second ago - been logged in and active on site.

Usually I'm heading for a page that requires login (such as GMF's Pending list), so my experience has been to be suddenly faced with the login page. That's fairly self-explanatory (at least to me) as to what happened and what I need to do next.

But if one is heading for a page that doesn't require login, say GMF's or beta's public messages, then the effect is much more disconcerting - you seem to have suddenly been unsubscribed from the group (the button list on the left shrank). If you're paying attention you'll notice that your name disappeared in the upper right, replaced with the Log In and Sign Up links - but that's not the most prominent change.

The consequence is that some group owners get complaints from members who believe they've been unsubscribed without cause, and who generally confound matters in their attempts to re-join the group.

Proposal:

Update the 30-day login period when the user visits the site, rather than only when they go through the login flow.

I presume you wouldn't want to add this to the burden of every page load, but if there's a way to do check it at most once daily per user that ought to be more than adequate.

Shal

Bruce Bowman
 

On Sun, Nov 4, 2018 at 12:59 AM, Shal Farley wrote:
Proposal:

Update the 30-day login period when the user visits the site, rather than only when they go through the login flow.
I am not fond of this idea. Confirmation of identity needs to be done on a periodic basis, and simply visiting the site using the same device does not accomplish that objective.

Has anyone given thought to the legal ramifications of this?

If we want subscribers to be less disconcerted, perhaps we should make them log in every time, and time them out after a certain interval of inactivity. That would be consistent with what most other sites do and certainly makes no less sense.

Thanks,
Bruce

 

I agree with Bruce. My reaction was the same as his, but I didn’t write it down here because it was more of a gut feeling that I couldn’t articulate or rationalize. He articulated it.


On Nov 4, 2018, at 5:38 AM, Bruce Bowman <bruce.bowman@...> wrote:

On Sun, Nov 4, 2018 at 12:59 AM, Shal Farley wrote:
Proposal:

Update the 30-day login period when the user visits the site, rather than only when they go through the login flow.
I am not fond of this idea. Confirmation of identity needs to be done on a periodic basis, and simply visiting the site using the same device does not accomplish that objective.

Has anyone given thought to the legal ramifications of this?

If we want subscribers to be less disconcerted, perhaps we should make them log in every time, and time them out after a certain interval of inactivity. That would be consistent with what most other sites do and certainly makes no less sense.

Thanks,
Bruce

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Jeremy H
 

My thought is that probbly what is required, is that when GroupsIO recognises an expired login (i.e login cookie older than 30 days) it puts up a page saying (essentially) 'Your login has expired. Please re-enter your password (or do whatever to) log back in.' 

Whether it mentions the 30 days, or what should be done for someone who has specifically logged off, are things that need to be thought, but which I haven't come to any decision about.  

Ken Schweizer
 

I agree with Bruce in that members should have to log in every time they visits a site; if that is consistent  it shouldn't confuse anyone who is able to use a computer. I would prefer a log out to be with a site disconnect or, if necessary, after a prolonged time of inactivity of say >1 hour along with a pop-up window announcing a pending log out in xx minutes. Automatic disconnects of <1 hour can be frustrating if you are researching a response.

 

Ken

 

"And if any man shall take away from the words of the book of this prophecy, God shall take away his part out of the book of life, and out of the holy city, and from the things which are written in this book." God

 

From: main@beta.groups.io [mailto:main@beta.groups.io] On Behalf Of Bruce Bowman
Sent: Sunday, November 4, 2018 7:39 AM
To: main@beta.groups.io
Subject: Re: [beta] Update login expiration on site visit #suggestion

 

On Sun, Nov 4, 2018 at 12:59 AM, Shal Farley wrote:

Proposal:

Update the 30-day login period when the user visits the site, rather than only when they go through the login flow.

I am not fond of this idea. Confirmation of identity needs to be done on a periodic basis, and simply visiting the site using the same device does not accomplish that objective.

Has anyone given thought to the legal ramifications of this?

If we want subscribers to be less disconcerted, perhaps we should make them log in every time, and time them out after a certain interval of inactivity. That would be consistent with what most other sites do and certainly makes no less sense.

Thanks,
Bruce

 

On Sun, Nov 4, 2018 at 06:50 AM, Ken Schweizer wrote:
I agree with Bruce in that members should have to log in every time they visits a sit
 I actually think that part would be going too far. It's the opposite extreme. I think the balance as it is now is a good one, with possibly some better messaging as previously suggested.
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

 

On Sun, Nov 4, 2018 at 07:00 AM, J_Catlady wrote:
as previously suggested.
as Jeremy suggested.
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

 

Bruce,

... perhaps we should make them log in every time, and time them out
after a certain interval of inactivity. That would be consistent with
what most other sites do and certainly makes no less sense.
For some definition of "most".

The only sites I use that behave that way are financial (banking) and other high-security sites.

Sites like Gmail, Yahoo, Facebook, and others seem to keep me logged in indefinitely. I'm not sure if they refresh on visit, or simply never expire, the effect is similar: I come back to the site days, weeks, or even months later (it seems) and I'm still logged in.

Even Amazon seems to use a kind of hybrid system. You retain your logged in identity, apparently indefinitely, for most browsing purposes, but after some time (days? I'm not sure) you'll be asked to log in again to access certain things, like your prior orders.

Shal

 

Jeremy,

My thought is that probbly what is required, is that when GroupsIO
recognises an expired login (i.e login cookie older than 30 days) it
puts up a page saying (essentially) 'Your login has expired. Please
re-enter your password (or do whatever to) log back in.'
A distinct landing page like this would make the experience more comparable to what I get (the login page) if my destination required login. Or it could be just a red-box page banner, that would inform the user but allow them to continue browsing as "guest" (not logged in).

Whether it mentions the 30 days, or what should be done for someone
who has specifically logged off, are things that need to be thought,
That's the key. The page or banner obviously should not appear for someone who explicitly logged out, nor for someone who visits the site having not been (recently) logged in.

Shal

Bruce Bowman
 

On Sun, Nov 4, 2018 at 02:49 PM, Shal Farley wrote:
For some definition of "most".

The only sites I use that behave that way are financial (banking) and other high-security sites. etc...
The only cogent reason I've heard to suggest that we need to change the current login process is that subscribers are becoming "disconcerte." I offered that alternative only as a bit of reductio ad absurdum rhetoric -- a way to address [what I consider to be] a non-existent problem. 

Looking back at the GMF archives, we might get 6-8 inquiries about this a month. There are half a million subscribers to the Updates group; certainly more actual accounts. It could be that many group owners are struggling to head off questions about logon problems so that they don't land in GMF. My own experience with my own groups is that not one person has made an inquiry that directly relates to expiration of the logon cookie.

I do believe that a "you are not logged in" banner of some sort has merit; and you may recall that I supported that idea in GMF. Other than that, it remains my opinion that the seriousness of this issue has been blown out of proportion.

Regards,
Bruce

 

I agree. I don't think this is really even an issue. Once in awhile, a member doesn't get it and think they were unsubscribed. So then I just explain that the login lasts 30 days, etc. It is a trifling matter IMO and I totally agree with Bruce here.
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Don Clark
 

I agree with Shal. Too many of my members are computer illiterate and panic. 

 

On Sun, Nov 4, 2018 at 06:40 PM, Don Clark wrote:
Too many of my members are computer illiterate and panic.
Do they panic when, I don't know, craigslist forums, for example, logs them out? Who do they turn to then? etc. One does need a modicum of computer literacy, just a smidgeon, to participate in any online forum.
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

 

On 4 Nov 2018 at 12:00, Shal Farley wrote:
That's the key. The page or banner obviously should not appear for
someone who explicitly logged out, nor for someone who visits the site
having not been (recently) logged in.

Shal
So how is the web site (i.e. Mark when coding it) supposed to know that? The
normal way for a cookie to be used for login purposes is to simply set it when
a person logs in and subsequently check for its existence whenever they visit a
page requiring a login. The cookie is simply deleted when they log out or when
it expires (in the latter case by the browser). No record is maintained
anywhere of why it was deleted or even if it ever existed. To do anything more
than that standard process would involve Mark in a whole lot of work using
permanent special purpose cookies, if it's possible at all.

Jim Fisher

--
http://jimellame.tumblr.com - My thoughts on freedom (needs updating)
http://jimella.wordpress.com - political snippets, especially economic policy
http://jimella.livejournal.com - misc. snippets, some political, some not
Forget Google! I search with https://duckduckgo.com which doesn't spy on you

 

Jim,


So how is the web site (i.e. Mark when coding it) supposed to know that?

Not being a web developer I don't really know, but I'm confident Mark can easily work it out.

The cookie is simply deleted when they log out or when it expires (in the
latter case by the browser). No record is maintained anywhere of why it
was deleted or even if it ever existed.

I'm aware of that much about cookies, and have suspected that that is exactly how Groups.io's login mechanism currently works. Simple, effective and consistent with observation. A naive suggestion would be to use a second cookie that has a (much) longer expiration as a marker for "has been logged in". That one would also be deleted by explicitly logging out.
That said, I've come around to the point of view that refreshing the logon at visit would be the better user experience. But maybe something like this should be done in that case as well, if the user has stayed away "too long".

Shal

Bob Bellizzi
 

My gosh, The great majority of websites that  require one to log in, terminate that login either:
   When the browser window is closed
   When the user logs off
If the user wishes to again utilize the website, they must log in again.
Even yahoo would log one out after some period of time and we would have to log in again.  I think it was much more arcane and obtuse.

What's different about groups.io in this regard?
   Mark decided to make things much more easy for the untrained user by providing a cookie with a 30 day expiration date.

What should be done to assuage those who freak out when they can't siimply access groups.io but are sent to a page clearly informing them about what they must do and with all choices visible on the page?
  In my opinion, Owners and Moderators have the responsibility to educate their members.
   We have almost 3500 members in our late onset rare disease group.  It's a fairly even mix of email and online users.  About 60 new members join per month.  Our long term average age is about 55.
  They receive instructions in their Welcome email. 
  A weekly calendar note on "Where to find Help" is sent out. 
  Moderators have experience handling questions online.
But considering the number of members, questions about being "dropped" are few and far between and are usually handled easily by the Moderators.
--

Bob Bellizzi

Founder, Fuchs Friends ®
Founder & Executive Director, The Corneal Dystrophy Foundation

 

Bob,

What should be done to assuage those who freak out when they can't siimply access groups.io but are sent to a page clearly informing them about what they must do and with all choices visible on the page?

You're missing the other case, the case where they are not taken to the login page. That's the case that motivated my suggestion.
Shal

Don Clark
 

Believe me when most of your members are seniors they don't even have "just a smidgeon" of  computer literacy
I really have to hold the hands of most members.

 

On Mon, Nov 5, 2018 at 01:36 PM, Don Clark wrote:
Believe me when most of your members are seniors they don't even have "just a smidgeon" of  computer literacy I really have to hold the hands of most members.
I'm getting really tired of these ageist remarks. I'm over 50, and I'm betting that the majority of my group members are over 50, and it's only once in a blue moon that I have to hold anybody's hand. So please, tell us that your group members are computer illiterate. Tell us that you have to hold their hands. But please stop justifying that on the basis of their ages.
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Jim Higgins
 

Received from Jim Fisher at 11/5/2018 08:05 PM UTC:

The normal way for a cookie to be used for login purposes is to simply set it when a person logs in and subsequently check for its existence whenever they visit a page requiring a login.
That's not quite how LOGIN cookies are handled. You can't just check for EXISTENCE of the cookie because they aren't all the same. You must also check the specific cookie CONTENT against the subscriber database so that the specific user is authenticated and the areas he may visit and privileges he has are known before granting access. It's not enough to say a cookie EXISTS so it's OK to give the person privileges in whatever area of the site he happened to land on. You have to authenticate the cookie contents.

The cookie is simply deleted when they log out or when it expires (in the latter case by the browser). No record is maintained anywhere of why it was deleted or even if it ever existed.
Yes... in the case of a deletion by the browser. Not necessarily in the case of an explicit log-out. In that latter case some sites may want to replace the log-in credentials stored in the cookie with something else. The point being that what MIGHT be put in that cookie isn't as important as understanding that deletion isn't the only option.

To do anything more than that standard process would involve Mark in a whole lot of work using permanent special purpose cookies, if it's possible at all.
Having some experience in this area, unless the implementation of lasting log-in cookies is made as complicated and with as many interacting options as hashtags are, it should be almost trivial to implement. If the cookie authenticates, update the cookie's expiration date. It's as easy as that.

Jim H