Date   

moderated Re: User-friendly message rejection after attempt to post to a locked thread #suggestion

 

On Wed, Apr 24, 2019 at 08:47 AM, Shal Farley wrote:
Rejection notices typically contain a copy of the rejected message, in this scenario that would be the payload.
Why couldn't that be altered for this case? The original suggestion already would require some nontrivial programming. The suggestion is not just, "turn locked topics into moderated topics." It's "treat locked topics  similarly to moderated topics, but where the system automatically rejects the messages." So why not also do away with including the rejected message? Voila, no payload. I'm not suggesting making locked topics into moderated topics where everything has to remain the same, including pasting in a copy of the rejected message. I'm saying, IF the system can handle moderated topics without bouncing messages, it should also be able to handle locked topics without bouncing messages.
 
--
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: User-friendly message rejection after attempt to post to a locked thread #suggestion

Leeni
 

Just an added side note about lock topics while you can't delete them, you also can't start a new message from an email if your email has the same subject line as the locked messages.
 
Example: My groups are Creative Design groups
Graphics are shared
A member starts a topic and the subject line reads Easter Eggs and that topic is auto locked after one day.
 
Now another member a couple days later shared Easter Eggs and names their subject Easter Eggs.
 
Their email would be rejected saying that the subject is locked.
 
Leeni
 
 
 
 
 

-------Original Message-------
 
Date: 4/24/2019 12:31:45 PM
Subject: Re: [beta] User-friendly message rejection after attempt to post to a locked thread #suggestion
 
This also ties in, and pretty directly, with another feature request I made:  Hide Topic Function

The need to hide a topic, per se, is separate from this topic.  But the fact that one cannot delete a topic after locking it, and having it remain somehow stored by Groups.io as locked, without any trace of it being visible to anyone is not.

Locked topics should not only be able to have some sort of "human comprehensible" message of the "You can't post to this topic because it's locked" nature sent out, but if one locks a topic there should be a "locked list" maintained even if the topic itself is deleted afterward.   Locked is locked, and should not be volatile based on the presence or absence via deletion of the material that triggered a topic to be locked in the first place.

While I'd like to have the capability to hide a topic for its own sake, when it comes to locked topics that I wish to have purged from the archive I'd far rather do that than hide it just so that no one can post to it again.

It strikes me as entirely feasible (and I may be wrong) to maintain a history of all locked topics for a group, even if said topic were subsequently deleted, so that "late entries" cannot revive it from the dead when replying to it.   I know individuals can create a separate topic to try to revive or extend something, but that is taken care of by the moderators making clear that it will not be tolerated and immediately locking the revival attempt.  (Then, if I had the option, deleting it if it would keep it locked, or at the very least hiding it to keep it out of the archive view).

--

Brian - Windows 10 Pro, 64-Bit, Version 1809, Build 17763  

     Presenting the willfully ignorant with facts is the very definition of casting pearls before swine.

              ~ Brian Vogel

 


moderated Re: User-friendly message rejection after attempt to post to a locked thread #suggestion

Brian Vogel <britechguy@...>
 

This also ties in, and pretty directly, with another feature request I made:  Hide Topic Function

The need to hide a topic, per se, is separate from this topic.  But the fact that one cannot delete a topic after locking it, and having it remain somehow stored by Groups.io as locked, without any trace of it being visible to anyone is not.

Locked topics should not only be able to have some sort of "human comprehensible" message of the "You can't post to this topic because it's locked" nature sent out, but if one locks a topic there should be a "locked list" maintained even if the topic itself is deleted afterward.   Locked is locked, and should not be volatile based on the presence or absence via deletion of the material that triggered a topic to be locked in the first place.

While I'd like to have the capability to hide a topic for its own sake, when it comes to locked topics that I wish to have purged from the archive I'd far rather do that than hide it just so that no one can post to it again.

It strikes me as entirely feasible (and I may be wrong) to maintain a history of all locked topics for a group, even if said topic were subsequently deleted, so that "late entries" cannot revive it from the dead when replying to it.   I know individuals can create a separate topic to try to revive or extend something, but that is taken care of by the moderators making clear that it will not be tolerated and immediately locking the revival attempt.  (Then, if I had the option, deleting it if it would keep it locked, or at the very least hiding it to keep it out of the archive view).

--

Brian - Windows 10 Pro, 64-Bit, Version 1809, Build 17763  

     Presenting the willfully ignorant with facts is the very definition of casting pearls before swine.

              ~ Brian Vogel


moderated Re: User-friendly message rejection after attempt to post to a locked thread #suggestion

Glenn Glazer
 

On 4/24/2019 08:32, Shal Farley wrote:
I admit it does seem far-fetched that a miscreant would put together the pieces necessary to exploit this particular suggestion.

This I agree with. And furthermore, the way around all of the speculation is to make it a feature that individual groups can turn on or off as a preference. So, for those groups for whom it works and want this, great and if some spammer is attacking a group, they can turn it off temporarily or permanently without impairing the usage by other groups.

The same holds true, incidentally, of my other suggestion to send it a queue, by which I meant a different queue than the regular moderation queue. The idea would be that it would be easier in a separate queue to select all and send the group's customized locked thread message than to have to pick them out of the general moderation queue.

Best,

Glenn

--
We must work to make the Democratic Party the Marketplace of Ideas not the Marketplace of Favors.

Virus-free. www.avast.com


moderated Re: User-friendly message rejection after attempt to post to a locked thread #suggestion

 

J,


Do you mean they would spoof various group members' email addresses in order to connivingly and deliberately send messages to locked topics in their name, just so that the group members would get the rejection message?

That is the scenario, as I understand it. Rejection notices typically contain a copy of the rejected message, in this scenario that would be the payload.


I considered myself cynical, but even I am not as cynical as that.

It is a concern (as Mark said), not a proven threat that I know of.

I admit it does seem far-fetched that a miscreant would put together the pieces necessary to exploit this particular suggestion. Perhaps ironically beta itself seems like one of the juicier targets because it has public archives, unrestricted membership, and (formerly) generous use of thread locking; yet even so it seems unlikely to me. However, once someone figures it out history has shown us that the dark corners of the internet are pretty good at sharing "how-to" info and packaged scripts to exploit anything they can.

Shal


moderated Re: User-friendly message rejection after attempt to post to a locked thread #suggestion

Brian Vogel <britechguy@...>
 

Being someone who deals with spam management on a daily basis, I have to say that I find the idea that spammers would do what is proposed highly, very highly, unlikely.

It's not something that would be of any value to them in any way I can think of.  They want their message out there, and no matter what they'd get back from trying to e-mail to a locked thread if it isn't a posted message they'd almost certainly move on.   Spam is a "drive by" activity using the broadest and quickest scatter and run methods possible.

When they get a rejection message they move along.
--

Brian - Windows 10 Pro, 64-Bit, Version 1809, Build 17763  

     Presenting the willfully ignorant with facts is the very definition of casting pearls before swine.

              ~ Brian Vogel


moderated Re: User-friendly message rejection after attempt to post to a locked thread #suggestion

 

On Tue, Apr 23, 2019 at 10:44 PM, Shal Farley wrote:
Automatically sending back a message runs the risk of allowing spammers to deliberately trigger this response, targeting group members.
Shal,

Ok, I read Lena's message about backscatter, and yours explaining it, and I am missing something. It seems unrealistic/overly pessimistic to assume that spammers would somehow find and send messages to locked topics. Even if they were somehow able to do that (which could only occur in unrestricted groups anyway), how would this "target group members"? Do you mean they would spoof various group members' email addresses in order to connivingly and deliberately send messages to locked topics in their name, just so that the group members would get the rejection message? I considered myself cynical, but even I am not as cynical as that. Or perhaps I'm actually overly naive and trusting. :)
 
--
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: User-friendly message rejection after attempt to post to a locked thread #suggestion

 

J,

I still have not heard what's infeasible about my original suggestion,
Read back through the topic for the word "backscatter", starting with Lena's message of 2018-01-02.

Automatically sending back a message runs the risk of allowing spammers to deliberately trigger this response, targeting group members.

Shal


moderated Re: User-friendly message rejection after attempt to post to a locked thread #suggestion

 

On Tue, Apr 23, 2019 at 12:50 AM, Shal Farley wrote:
2. Have an option that messages that go to locked threads go to a
moderation queue and the humans can determine what is backscatter
and what gets a nice message.
This seems to me to be the same as moderating the topic, rather than locking it.
I still have not heard what's infeasible about my original suggestion, which is to treat locked topics as moderated topics but wherein all posts are rejected automatically by the system and sent a canned "this subject is locked" rejection notice. 
 
--
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: User-friendly message rejection after attempt to post to a locked thread #suggestion

 

Glenn,

1. ... if a message is from member in group, send back new email with
nice message, else drop on the floor.
If the message is from a non-subscriber it should be given an error at connection time (not accepted then dropped) using the existing error code/text for non-subscriber messages -- unless the group is set to allow non-subscriber posts.

If the group is set to allow them, then a message to a locked topic from a non-subscriber should be handled the same as one from a member.

I realize that 1. risks backscatter, but until there is evidence of
such, there is no way to evaluate that risk and it just may be a case
of being too timorous.
This belongs in a different topic, but I've come to believe that Groups.io ought to be doing DMARC-like authentication on inbound group postings and email commands before accepting them. That would (I think) eliminate the risk of backscatter were Groups.io to accept the message and separately send back a "nice" error message.
https://beta.groups.io/g/main/topic/24836368#18077

2. Have an option that messages that go to locked threads go to a
moderation queue and the humans can determine what is backscatter
and what gets a nice message.
This seems to me to be the same as moderating the topic, rather than locking it.

Shal


moderated Re: User-friendly message rejection after attempt to post to a locked thread #suggestion

Sarah k Alawami
 

I'm in favor of option 2 personally. I'd rather hold the messages then either reject them all, or maybe let one or 2 through, or not depending on the case.

Sarah Alawami, owner of TFFP. . For more info go to our website.
For stuff we sell, mac training materials and  tutorials go here.
and for hosting options go here
to subscribe to the feed click here

The listen page is found here

Our telegram channel is also a good place for an announce only in regard to podcasts, contests, etc.

Finally, to become a patron and help support the podcast go here

On 22 Apr 2019, at 16:09, Glenn Glazer wrote:

So, I am also in the camp of making the message more human friendly. I understand HTTP status codes and so on, but only a tiny fraction of my group members do and they find the bounce message frightening, as Mark noted. 

I have two alternatives to suggest:

  1. As a slight modification to the alternative Mark describes, if a message is from member in group, send back new email with nice message, else drop on the floor. 
  2. Have an option that messages that go to locked threads go to a moderation queue and the humans can determine what is backscatter and what gets a nice message.

I realize that 1. risks backscatter, but until there is evidence of such, there is no way to evaluate that risk and it just may be a case of being too timorous.

A bonus to 2. is that each group could design its own lock message as a preference.

Best,

Glenn


moderated Re: User-friendly message rejection after attempt to post to a locked thread #suggestion

Glenn Glazer
 

So, I am also in the camp of making the message more human friendly. I understand HTTP status codes and so on, but only a tiny fraction of my group members do and they find the bounce message frightening, as Mark noted. 

I have two alternatives to suggest:

  1. As a slight modification to the alternative Mark describes, if a message is from member in group, send back new email with nice message, else drop on the floor. 
  2. Have an option that messages that go to locked threads go to a moderation queue and the humans can determine what is backscatter and what gets a nice message.

I realize that 1. risks backscatter, but until there is evidence of such, there is no way to evaluate that risk and it just may be a case of being too timorous.

A bonus to 2. is that each group could design its own lock message as a preference.

Best,

Glenn


moderated Re: Moderator Permissions

Jeremy H
 

On Fri, Apr 19, 2019 at 04:57 PM, Chris Jones wrote:
On Fri, Apr 19, 2019 at 04:34 PM, Jeremy H wrote:
A further point to mention - as it is relevant, and needs to be catered for - is that it possible (and reasonable) for a moderator to have no specific privileges (but just be a moderator), which gives them access to various features, which can be set to '(all) moderators only'.
I think you would need to clarify exactly what you mean by a moderator to have no specific privileges. Now it would be possible (I suppose) to appoint a subscriber as a moderator but not give them any of the permissions in the picklist, unless of course the system spots that and stops you doing it! As it happens anyone thus appointed would still have permissions to upload / edit material to the Files & Photos sections (etc) if those sections were set to Owners & Moderators only.
Yes, that is what I mean - a moderator with none of the picklist permissions granted - the system permits this - who hence have the ability to do those things restricted to  'Owners and Moderators' only, in Group settings. And because of what those things mainly are (Uploading/Editing Files/Folders, etc.) that role might be better described as 'Trusted User', rather than 'Owner's Assistant', which is what I would expect the term Moderator to mean, and which requires those privileges granted by the picklist options. But - for reasons lost in the mists of time - both roles are combined as 'moderator' - I suspect it was a quick and dirty solution to a requirement, that in a sense, has now come back to bite us - but changing it is a different issue.

While I would expect the number of Owner's Assistants for any group to be small, I can foresee groups that - because of the sort of group they are - will want a substantial number (dozens?) of 'Trusted Members' (or 'responsible officers') able to do things that ordinary members cannot.

FWIW I simply cannot see what your suggestion would achieve. The objective of my suggestion detailed in the initial post on this topic is for moderators to know exactly what permissions they do and do not have; as Catlady clearly stated in her post Without that, it's a guessing game. If a puzzled moderator comes to the GMF (or here, for that matter) for guidance about some difficulty it becomes impossible to give any sort of meaningful answer if the person concerned has no clear view of the permissions they have and no straightforward means of finding out either.
I agree - and was not suggesting anything other than a means of how moderators could see what privileges they have, taken account of concerns raised by others. Not having any specific privileges is a current possibility... 

Something that has occurred to me more recently is that there a two extra privileges that might usefully be established: 'Show moderator privileges' (which would let them see their and, if they have access to the member list, others' privileges) and 'Show group settings' - which together may let them see why things do or do not happen.

Jeremy


moderated Re: Moderator Permissions

Brian Vogel <britechguy@...>
 

On Sun, Apr 21, 2019 at 03:43 PM, J_Catlady wrote:
I think it's safer to have them unchecked.
About which, for the record, we're in absolute agreement (or very near, there might be a couple of the "innocuous" ones I might pre-check - and I'd make that an owner setup function for the group).

It is far better, when there is any question about the desirability of granting something, to create a situation where the individual doing the granting has to read and consider before each click of the checkbox.   Not that all will necessarily either read or consider, but you create a situation that forces that as much as one possibly can.
 
--

Brian - Windows 10 Pro, 64-Bit, Version 1809, Build 17763  

     Presenting the willfully ignorant with facts is the very definition of casting pearls before swine.

              ~ Brian Vogel


moderated Re: Moderator Permissions

 

On Sun, Apr 21, 2019 at 12:35 PM, Chris Jones wrote:
at the instant you promote "Subsciber X" to the status of Moderator the drop down box with the picklist appears, so in one way it makes no difference if  the owner has to either assign or remove permissions.
I see what you're saying, but I think it's safer to have them unchecked. It used to be otherwise (they were all checked and had to be explicitly unchecked).
 
--
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: Moderator Permissions

 

On Sun, Apr 21, 2019 at 12:34 PM, Brian Vogel wrote:
I do NOT want all permissions assigned as the default. That would force me, or a co-owner, to immediately go in and take away the ones I don't want a particular mod to have.
Serious question:   Is that even what happens now?
I meant to add, "As what happens now" to my post but assumed everyone was aware that currently, no permissions are assigned by default. Only notifications are automatically checked. Each permission must be explicitly granted after someone is made a mod. (It used to be otherwise in the past. I'm not sure when this changed but it was a good change IMO.)
 
--
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: Moderator Permissions

Chris Jones
 

On Sun, Apr 21, 2019 at 06:52 PM, J_Catlady wrote:
I'm fine with them seeing which permissions they have and don't have, but I do NOT want all permissions assigned as the default. That would force me, or a co-owner, to immediately go in and take away the ones I don't want a particular mod to have.
I don't think that is true; at the instant you promote "Subsciber X" to the status of Moderator the drop down box with the picklist appears, so in one way it makes no difference if  the owner has to either assign or remove permissions. Furthermore the status of moderator does not become active until the Save tab is clicked, so the concept of being "forced" to do anything in any sort of rush doesn't arise.

Having said that I would agree that assigning permissions is preferable to removing them; the default should be "none" not "all".

Chris


moderated Re: Moderator Permissions

Brian Vogel <britechguy@...>
 

On Sun, Apr 21, 2019 at 01:52 PM, J_Catlady wrote:
but I do NOT want all permissions assigned as the default. That would force me, or a co-owner, to immediately go in and take away the ones I don't want a particular mod to have.
Serious question:   Is that even what happens now?

My perception, based on this topic and other related ones, is that the group owner creates/selects "the default slate of Moderator permissions" that are what get assigned to any Moderator upon their elevation to that role.  Is this or is this not the case?   I would hope it is, so that any group owner assigns, affirmatively, what they consider to be their "baseline cluster of permissions" and then anything that would be added would also need to be done intentionally, immediately after the elevation to Moderator (or as part and parcel of the process, but I think of it as "check those checkboxes right after the role is assigned").

If my presumption is correct, then there is no conflict between what Nimer is saying and what you want, J, as I'd interpret "all permissions" as "all permissions I've set up to be granted by default," which in all probability is not ALL permissions for most owners (but it may be for some).
 
--

Brian - Windows 10 Pro, 64-Bit, Version 1809, Build 17763  

     Presenting the willfully ignorant with facts is the very definition of casting pearls before swine.

              ~ Brian Vogel


moderated Re: Moderator Permissions

 

On Sun, Apr 21, 2019 at 10:46 AM, Nimer Jaber wrote:
I don't see the issue with moderators being able to see which permissions they have and don't have, and I don't have an issue with having to restrict permissions rather than assign them.
I'm fine with them seeing which permissions they have and don't have, but I do NOT want all permissions assigned as the default. That would force me, or a co-owner, to immediately go in and take away the ones I don't want a particular mod to have.

IMO there should not be any time interval, no matter how short, during which new (or any) mods have permissions they are not supposed to have. All permissions should all be affirmatively assigned
 
--
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: Moderator Permissions

Nimer Jaber
 

Hello,

From my perspective as a group owner, I don't see the issue with moderators being able to see which permissions they have and don't have, and I don't have an issue with having to restrict permissions rather than assign them. I have had a number of instances where I have had a change of moderator on my list, and at times it gets rather confusing because I have to dig in settings to find that a moderator doesn't have the ability to change something they believe they should have, but they don't even know whether the setting exists. It is better that they see all settings, even ones that haven't been delegated to them. This way, they can let the owner of the list know that there is a permission they need, this is what it is and where it is, and the owner can choose whether or not to delegate that. Also, if I invite someone to be a moderator on the list, I am demonstrating a level of trust in them. They ought to be able to have permissions to do as they wish in terms of day-to-day running of the list, and if I don't trust them with that, and I feel the need to severely restrict their permissions, then maybe I should consider whether they ought to be a moderator on my group.

Thanks.

On Sun, Apr 21, 2019 at 10:33 AM Brian Vogel <britechguy@...> wrote:
On Sun, Apr 21, 2019 at 10:53 AM, Sarah k Alawami wrote:
but can we not as mods see all check boxes but have them grayed out instead?
This is the crux of the discussion, and I see nothing in Bruce's former suggestion that conflicts with mine.

By default, unless a group owner chooses to mask, moderators should know what they can and cannot do, period.  If a group owner wants to hide ungranted privileges, they should have the option to do so, and have to make a conscious choice to exercise that option.

To me, even that option would have to be at the Moderator profile level, if one wanted to have certain moderators see only the permissions they've been granted versus others who might see both granted and ungranted privileges.   One could argue that it be set at the group level, but if that's the case then customizing on an individual basis for those who you want to be able to see more than whatever the defaults granted are becomes more difficult.

I am discussing what any given moderator can see about the permissions they have.   We already have a permission, mentioned by Bruce, that does control whether they can see what other Moderators have:  Set Moderator Privileges.   If that's off, you can't see what others have got, if it's on, you have, essentially, owner level access.
 
--

Brian - Windows 10 Pro, 64-Bit, Version 1809, Build 17763  

     Presenting the willfully ignorant with facts is the very definition of casting pearls before swine.

              ~ Brian Vogel



--
Best,

Nimer Jaber

The message above is intended for the recipient to whom it was
addressed. If you believe that you are not the intended recipient,
please notify me via reply email and destroy all copies of this
correspondence. Action taken as a result of this email or its contents
by anyone other than the intended recipient(s) may result in civil or
criminal charges. I have checked this email and all corresponding
attachments for security threats. However, security of your machine is
up to you. Thanks.

Registered Linux User 529141.
http://counter.li.org/

To find out about a free and versatile screen reader for windows XP
and above, please click here:
http://www.nvda-project.org

You can follow @nimerjaber on Twitter for the latest technology news.

To contact me, you can reply to this email or you may call me at (970) (393-4481) and I will do my best to respond to you promptly. Thank
you, and have a great day!

8761 - 8780 of 29629