Date   

moderated Re: Update login expiration on site visit #suggestion

 

Mark,

Caveat: I know enough about computer security to know that I don't know much about computer security.

Me too. I think it is very important to understand that actual security (as opposed to security theater) is hard. That's my take-away from experts like Krebs.

Inevitably there's a trade-off between usability and security, and I don't think Groups.io needs to hold itself to the standards of a financial institution. Hence my support for the idea of automatically extending the login cookie on visit. However, I'm perfectly content to have an explicit notification on expiration instead (I'd still want this even if the cookie were extended).

The question is, what should I do in that situation? Should I take you to the login screen with a notice that you've been automatically logged out?

I would favor this.

Mostly because it brings the user directly to the page they need to correct the situation. The only downside I can see is that it would be more jarring than a banner, especially to a user who is navigating public pages (such as beta's) but arguably someone who had been logged in would want to know about the expiration anyway..

Shal


moderated Re: Update login expiration on site visit #suggestion

Dave Sergeant
 

Maybe Yahoo works differently in your part of the world. In the UK
(both yahoo.co.uk and yahoo.com) I have always had to re-login every 14
days despite never deleting cookies. A well known feature, I am sure
you will find discussion about it on the Yahoogroups gmf.

But hey, now that all our groups have moved to GIO I have now
permanently deleted my Yahoo cookies.

Dave

On 9 Nov 2018 at 23:12, Jim Higgins wrote:

I NEVER encountered any 14-day time out in my 16 years of managing
groups on Yahoo!

Unless I accidentally deleted cookies or manually logged out I NEVER had
to enter Username and Password to access Y! or Y!Groups.

http://davesergeant.com


moderated Site updates #changelog

 

Changes to the site this week:

Web:

  • SYSADMIN: Increased heap memory of search nodes to hopefully stop random crashes.
  • BUGFIX: Reply to sender on the web to a non-member of the group produced an error.
  • BUGFIX: Reply to Group & Sender on the web in some cases did not send the message to the sender, only to the group.
  • CHANGE: Tweak the formatting of photo album descriptions to allow for longer descriptions.
  • BUGFIX: Some Facebook posts would duplicate the first image.
  • CHANGE: Bolded the current page in the pagination links.
  • BUGFIX: Fixed a couple of broken links in the More menu on mobile.

API:

  • NEW: New subscription_plus field: nice_group_name.
  • NEW: New /gettopics parameter: extended.

Have a good weekend everyone.

Mark


moderated Re: Marking members with Advanced Preferences for email delivery #suggestion

 

Frances,

It would be useful if there was a flag - even an asterisk or AP - for
members who have chosen Advanced Preferences.
I like this idea.

Perhaps some badges (akin to those used in the email column) to indicate Advanced Preferences. For example:

(none) - All Messages (the default)
F - Following Only
FF - Following Only w/ First Message Also
R - Auto Follow Replies
A - Max. Attachment Size limit (any selection except Unlimited)

Shal


moderated Re: #cal-notices/page refreshing

Jim Higgins
 

Received from J_Catlady at 11/9/2018 11:31 PM UTC:

I would still like to be able to send files on a regular basis, not only the Group Guidelines. But I think this is very low on the priorities.

I agree. Cal-notices aren't a really good way to send regular information that isn't a calendar type event.

If/when sending files on a regular basis is implemented, I'd like a checkbox option to send as a "special notice" that would be sent to all subscribers regardless of their email preference. Too many just plain don't read all the mail and if a file is important enough to send regularly it (at least in some cases) needs to be seen by all.

Jim H


moderated Re: Update login expiration on site visit #suggestion

Jim Higgins
 

Received from JohnF via Groups.Io at 11/8/2018 03:45 PM UTC:

Say a login cookie is stolen somehow, never mind how. If the legitimate user logs out and logs back in, getting a new login cookie, does that invalidate the stolen cookie?

It should.


If so, then a 90-day expiration is likely OK, as any user suspecting cookie theft has an easy way to fix it.

Yes... as long as the one who stole the cookie hasn't changed the email address and password... all of which can be done at day 1 as easily as at day 15, 30, 60, or 90.

But let's get serious... attempting to steal cookies passed over an encrypted (https) connection is a lesson in futility. It's not the route by which credentials to things like Groups.io or Yahoo or Google Groups (etc) are stolen. Those are stolen from people who use trivial passwords - like 1234 on their iPhones - or who use the names of pets, children, etc whose names are plastered all over their social media pages... or who respond to bogus email "from" places like Gio or Yahoo saying their account will be closed in 5 days unless they reverify their login credentials; i.e., via social engineering. Etc. The worries over stolen cookies passed over an encrypted connection as a threat to the security of our Gio accounts are very seriously misplaced.

If Groups.io were deadly serious about security they wouldn't use our email address as the "Username" portion of a login. Members' email addresses are found in every email that Gio forwards to a home account. Not so for user names on Yahoo. After that, along with a name in many cases, it's not so hard to find some social media pages for that person and start looking for names of pets, children, birth dates, etc that are commonly used as passwords. That's how our login credentials are going to be stolen, not via cookies.


I would recommend adding a second cookie that lasts a year, indicating the user is logged on, but doesn't provide any authorization. If the user logs out, that cookie also gets deleted. If the user has that cookie but not the authorization cookie, a "pop-up" (not a real pop-up, as those tend to get blocked these days) message should be displayed: "Your login session has expired. Click here to log back in, or here to continue without being logged in.". Either click deletes the year-long cookie, so the message won't keep re-appearing.

I know what you're looking for, but the algorithm you described for handling that second cookie is incorrect. If the subscriber logs out that second cookie should NOT be deleted. That cookie is how Gio would know that that person is a subscriber who currently has no logon cookie (expired or logged out) and thus should be shown the "Your login session has expired... " message. Once the login cookie is restored, the second cookie remains, probably best renewed for a year upon each new login, but otherwise ignored as long as a login cookie exists.


If the user hasn't logged in in a year, or if the user deletes cookies, it's not your responsibility to remind the user to log in.

I suppose not anyone's responsibility, but that second cookie could just as well never expire and things would be just as secure as if it expired in a year. As for the user who deletes cookies, they get to sleep in the bed they made for themselves... if only because reminding that user requires Gio to be clairvoyant.

Jim H


moderated Re: #cal-notices/page refreshing

 

On Thu, Nov 8, 2018 at 01:25 AM, Victoria wrote:
even better would be an option in the files (like yahoo-groups has) for documents to be  sent to the group in regular intervals
I agree. This was requested a lot "in the beginning," until people (including me) gave up on it. We were successful in persuading Mark to set up the "Group Guidelines" notice, which is a single document that can be sent monthly. It was pushed in large part by people (including me) who felt that cal-notices were an unacceptable way to send a monthly (or otherwise regular) file, or files.

I would still like to be able to send files on a regular basis, not only the Group Guidelines. But I think this is very low on the priorities.
 
--
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


moderated Re: Update login expiration on site visit #suggestion

Jim Higgins
 

Received from Dave Sergeant at 11/8/2018 06:43 AM UTC:

I fail to see what the problem is. After all, Yahoogroups where many of the current users have come from, has a 14 day time out. Nobody ever had issues with this. Why is groups.io any different.

I NEVER encountered any 14-day time out in my 16 years of managing groups on Yahoo!

Unless I accidentally deleted cookies or manually logged out I NEVER had to enter Username and Password to access Y! or Y!Groups.

I currently have no Y! cookies that expire in 14 days (or less) most are at least a year and some expire in 2038.


But the fact that you are logged out needs making more obvious. If you visit anything other than groups.io homepage such as a private group that requires login or parts of a group that needs login to access you should get a prominent login box, just like any other forum on the internet does. Taking you to the groups.io homepage with a fairly well hidden login link in the corner is NOT the way to do it.

What you say should happen already does happen, EXCEPT when the group visited is readable by non-subscribers. Is it possible that you've formed an opinion based on incorrect information?


I am not in favour of extending the timeout.

Why not? Why can't those of use who would like to manage our own security have the convenience of a longer expiration (and preferably one that renews upon each visit)? Why can't the folks who want cookies to expire in 14 days simply log themselves out on the 1st and 15th of the month and log back in? Would that be annoying? Yep... about as annoying as finding yourself unexpectedly logged out. And that's precisely why some would like a longer expiration period (and preferably renewable on each visit).

Jim H


moderated Re: Update login expiration on site visit #suggestion

 

Say a login cookie is stolen somehow, never mind how. If the legitimate user logs out and logs back in, getting a new login cookie, does that invalidate the stolen cookie? If so, then a 90-day expiration is likely OK, as any user suspecting cookie theft has an easy way to fix it.

I would recommend adding a second cookie that lasts a year, indicating the user is logged on, but doesn't provide any authorization. If the user logs out, that cookie also gets deleted. If the user has that cookie but not the authorization cookie, a "pop-up" (not a real pop-up, as those tend to get blocked these days) message should be displayed: "Your login session has expired. Click here to log back in, or here to continue without being logged in.". Either click deletes the year-long cookie, so the message won't keep re-appearing.

If the user hasn't logged in in a year, or if the user deletes cookies, it's not your responsibility to remind the user to log in.

JohnF


moderated #cal-notices/page refreshing

 

I have a few suggestions that would make handling in groups.io easier:

- in the Message Policies section there should be a way to prevent the automatic appearance of #cal-notice on the "Top Hashtags" display of the home page every time a cal notice is generated. I find it quite bothersome to have to check on the homepage regularly, then click and delete each notice individually. Clarification: I send regular notices via calendar, each member gets them anyway, so reminders on the "Top Hashtags" display are bothersome since they must be deleted individually.

- even better would be an option in the files (like yahoo-groups has) for documents to be  sent to the group in regular intervals. In that case they would not have to be sent via #cal-notices.
- Another issue is that pages do not refresh automatically. For example each time I delete one of the #cal-notices the side is changed to the messages side. Another example: members trying to join a certain group are sent to the groups.io starting page instead of remaining on the one they wanted to join.

Victoria


moderated Re: Update login expiration on site visit #suggestion

Dave Sergeant
 

I fail to see what the problem is. After all, Yahoogroups where many of
the current users have come from, has a 14 day time out. Nobody ever
had issues with this. Why is groups.io any different.

But the fact that you are logged out needs making more obvious. If you
visit anything other than groups.io homepage such as a private group
that requires login or parts of a group that needs login to access you
should get a prominent login box, just like any other forum on the
internet does. Taking you to the groups.io homepage with a fairly well
hidden login link in the corner is NOT the way to do it.

I am not in favour of extending the timeout.

Dave

On 7 Nov 2018 at 13:47, Bruce Bowman wrote:

The only way to "fix" this is with some clear indication that the
subscriber is not logged in.

http://davesergeant.com


moderated Re: Update login expiration on site visit #suggestion

 

I don’t do FB any more either. But of course you can log yourself out any time, just like every other site. The issue for me is the long length of time they keep you logged in. Logging out of anything and then back in is a PITA. So you’re generally not going to do it. OTOH you want to feel that a site takes even the smallest measure to protect your security. Three months doesn’t cut it for me personally.

On Nov 7, 2018, at 5:12 PM, Jim Higgins <HigginsJ@sc.rr.com> wrote:

Received from J_Catlady at 11/7/2018 11:41 PM UTC:

It's not a big deal to me, but I have really always disliked Facebook's policy. It seems like they never log you out (although you're saying it's three months), and frankly it's always made me nervous.

I don't do Facebook, so I have to ask... isn't there something to click to log yourself out?

Jim H



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


moderated Re: Update login expiration on site visit #suggestion

Jim Higgins
 

Received from J_Catlady at 11/7/2018 11:41 PM UTC:

It's not a big deal to me, but I have really always disliked Facebook's policy. It seems like they never log you out (although you're saying it's three months), and frankly it's always made me nervous.

I don't do Facebook, so I have to ask... isn't there something to click to log yourself out?

Jim H


moderated Re: Update login expiration on site visit #suggestion

Jim Higgins
 

Received from Bruce Bowman at 11/7/2018 09:47 PM UTC:

Extending the cookie to expire at 90 days or (30 days or inactivity) only delays the inevitable.

Exactly, but it's a step toward the ***OPTION*** of a cookie that doesn't expire.


Even setting the cookie to NEVER expire doesn't really help. As soon as these subscribers delete cookies on their own, or attempt to open the site with another browser/device, they will become disoriented all over again.

There are certain things you can't fix... but at least then it's their own fault... while the ones who are savvy benefit from a cookie that doesn't expire.

Jim H


moderated Re: Update login expiration on site visit #suggestion

Jim Higgins
 

Received from Mark Fletcher at 11/7/2018 08:35 PM UTC:

I did some tests with Facebook. They apparently expire their login cookie after 3 months. I would be fine extending our expiration to that as well. Anyone have an objection?

Strongly in favor of extending the expiration to 3 months, but...

...in addition to that, could you also offer the option of a cookie that never expires, effectively letting each of us decide how to manage our own security. Since Groups.io uses secure connections, the liklihood that anyone would try to steal my login data is remote.

Jim H


moderated Re: Update login expiration on site visit #suggestion

 

It's not a big deal to me, but I have really always disliked Facebook's policy. It seems like they never log you out (although you're saying it's three months), and frankly it's always made me nervous.
--
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


moderated Re: Update login expiration on site visit #suggestion

Bruce Bowman
 

On Wed, Nov 7, 2018 at 03:35 PM, Mark Fletcher wrote:
I did some tests with Facebook. They apparently expire their login cookie after 3 months. I would be fine extending our expiration to that as well. Anyone have an objection?
Mark -- It seems to me that no one has been very clear about defining what the problem is. 

  • Users are becoming disoriented whenever the logon cookie expires.
Extending the cookie to expire at 90 days or (30 days or inactivity) only delays the inevitable. Even setting the cookie to NEVER expire doesn't really help. As soon as these subscribers delete cookies on their own, or attempt to open the site with another browser/device, they will become disoriented all over again.

The only way to "fix" this is with some clear indication that the subscriber is not logged in. Personally, I feel that a collapsed left-side menu and the "login" button at top right is adequate. Others seem to disagree. Perhaps a red banner or simply a different-colored menu bar/login button at the top of the page could serve to capture the attention of the inattentive.

Regards,
Bruce


moderated Re: Update login expiration on site visit #suggestion

 

Hi All,

Caveat: I know enough about computer security to know that I don't know much about computer security.

I think the general reason that sites use expiring cookies (ie log you out after N days) is to prevent attacks where a cookie is stolen and then is used to impersonate the user. With HTTPS, the chance of cookies being stolen is pretty low these days.

I agree that being 'silently logged out' can present a confusing situation. I can add another cookie that never expires that indicates that you've been logged in. That way, I will know when your cookie has expired. The question is, what should I do in that situation? Should I take you to the login screen with a notice that you've been automatically logged out? Or should I just show a banner on whatever page you're visiting? If I do that, should I only show the banner on the first page you visit after your login cookie expires, or something else?

I did some tests with Facebook. They apparently expire their login cookie after 3 months. I would be fine extending our expiration to that as well. Anyone have an objection?

Thanks,
Mark


moderated Re: Update login expiration on site visit #suggestion

Jeremy H
 

On Mon, Nov 5, 2018 at 09:19 PM, Shal Farley wrote:
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
Getting back to the original issue, the root of the problem is that, after 30 days of just going in to a page and doing whatever, a user is presented with essentially the same page (with only an inconspicuous change that I would suggest few people notice) but where you can't do whatever, in other words - from the user perspective - it's broken. (In a sense the '30 day' feature is it's own enemy - if people always had to logon, they'd be used to doing so, and so it wouldn't be a real problem).

If handling cookies differently to solve this is going to fall into the 'undesirable' category, the alternative is to make the page more obviously different - something probably most simply done by some sort of banner or popup, saying you need to login for full functionality (with appropriate butttons).

Possibly modifying the standard groups.io banner to be different colours for logged in or not is the way to go.

Jeremy


moderated Re: Group Setting to Enable From Address via groups.io #suggestion

Panagiotis Georgopoulos <panagiotis.georgopoulos@...>
 

I would certainly agree with that as I am facing bouncing problems with my corporate mailing service and I, and other colleagues, don't receive any messages to groups.io that we sent.  

10081 - 10100 of 28895