moderated Limit number of group aliases #suggestion


Bruce Bowman
 

Premium/Enterprise groups can create an unlimited number of group aliases. Those names become unavailable for others to use. As GIO grows, this strikes me as increasingly problematic. Someone with malicious intent could even create hundreds just to fleece the system.

On that basis I'd like to suggest that 5 group aliases should be more than enough.

Thanks for your consideration,
Bruce


Malcolm Austen
 

As I was the cause of this being raised, I'll offer a view that 5 might be considered too few but I appreciate that there must be some restriction because they all restrict (or are restricted by) the overall (and finite sized) collection of group names.

For subgroups though, the limit can be higher (but still finite, just for sanity) because they come from a different pool.

Keep safe, Malcolm.

-- 
Malcolm Austen <malcolm.austen@...>

On 29/01/2021 22:07:12, Bruce Bowman <bruce.bowman@...> wrote:

Premium/Enterprise groups can create an unlimited number of group aliases. Those names become unavailable for others to use. As GIO grows, this strikes me as increasingly problematic. Someone with malicious intent could even create hundreds just to fleece the system.

On that basis I'd like to suggest that 5 group aliases should be more than enough.

Thanks for your consideration,
Bruce


 

Bruce,

>>>
Premium/Enterprise groups can create an unlimited number of group aliases. Those names become unavailable for others to use. As GIO grows, this strikes me as increasingly problematic. Someone with malicious intent could even create hundreds just to fleece the system.
<<<

That can be/is a possibility but the good mitigating factor to that is that group aliases are not available in free groups so it would mean someone would have to pay $220 for a year (or monthly) in order to be able to do that "DNS parking", which lowers the probability it could happen.

But you are right, it can.  However,

>>> On that basis I'd like to suggest that 5 group aliases should be more than enough.

5 is too low IMO; regardless of retro-application of it or not, you would be handicapping certain types of groups which use the aliases for what they are useful over here, search keywords for finding the group***, and also prevent "competitors" from causing unnecessary group-related headaches.  For example, see attached, this printer hardware user group of mine, it covers the whole MicroDry (MD) line of ALPS printers plus re-branded ones.  As such, you can tell the aim/intent in my alias names, and by virtue of the whole model line +, it has to be big.  I'm sure there are other types of similar-purpose/function groups that do this, not just me or my type of group only.  I've also done a similar setup on another group which is a Special Interest Group which builds airliner model kits exclusively.

*** (I do know about the group description "hidden-text" trick but many don't)

But I have a relatively simple and easy suggestion to alleviate the concern without altering anything on current group aliases' functionality.  Here's the thing; alias creation/editing is an infrequent task, it may spike after (and a bit after) group creation, but after that, it should be relatively quiet; or the corollary, it may not happen until some time in the group's future and then go quiet again, same end result.  The point is, for all groups, any generated auditing data related to alias editing is not really going to be a large amount, therefore impact should be minimal/very-small on that end.  So,

- Create a "new"* table/place, GroupAlias_ActivityLog or whatever. (* "new" could be a literally-new one or use an existing table like the ActivityLog if it can support this)

- Add a few lines of code to the group-alias-deletion part, so it saves the pertinent info to the GroupAlias_ActivityLog, at the very least date & time, GroupID of where the alias was deleted from, OwnerID of that group, UserID & IsMod/IsOwner status of the person who did the deletion, and the alias text/pointer/whatnot; plus anything else that can be of use for this.

That's it, for now.  This would create the infrastructure needed and would start logging deletions.  Then we figure out how to get the warning light to blink.  My suggestion would be to create a reporting/trend-analysis script/job that at some specified interval depending on how quickly Mark would want to be given a heads-up.  It would compare all the group names that have been newly-created during that interval against the name of any GroupAlias_ActivityLog deletions during that same interval.  Also do a second same comparison but since-beginning-of-auditing-data this time.

1. If the count of matches (interval-only or since-beginning-of-log-data) is 0 all is kosher.

2. Otherwise break down the distribution of that count data based on the combinations of who did what and when, both for just the interval and since-beginning-of-log-data.  For example, how many new groups were created during the two timeframes:
- by the same owner, and the owner was the one who did the alias deletion. (more-or-less OK I'd think)
- by the same owner, and a mod was the one who did the alias deletion. (could point to the mod being cheeky/sneaky/whatnot, unbeknownst to the (possibly AWOL or non-savvy) owner)
- where the new group owner is neither the owner nor a mod of the alias-deleted group. (could be suspect)
- where the new group owner is a mod of the alias-deleted group and the owner was the one who did the alias deletion. (more-or-less OK I'd think)
- where the new group owner is a mod of the alias-deleted group and the mod was the one who did the alias deletion. (could be suspect)
- relationship between new group owner and their group membership in the group where the [owner/mod] alias deletion took place, or a member of any group of said owner/mod. (could be both I think)
And so on, you get the idea, whatever we may think could/would be suspicious.  For example, if the same group owner/mod seems to be consistently deleting aliases only for those to show up as new group names (at any point in time now or later on), by consistently totally unrelated people (i.e. they are not in a group the owner/mod are in), that would definitively be worth IMO having a look at, even if a cursory one at the very least.  It could be innocent (as me for example releasing and giving gratis one of the aliases in my example above to a "competitor" if I wanted to), but it could also be something more sinister afoot, including Bruce's concern, in which case some setup like this should help alert and eventually catch the perpetrator(s).

Cheers,
Christos


Duane
 

On Fri, Jan 29, 2021 at 04:07 PM, Bruce Bowman wrote:
Someone with malicious intent could even create hundreds just to fleece the system.
I remember/know of one case so far where a group wanting to move from Yahoo couldn't use the old group name.  A 'competitor' used it as an alias here just so the group moving couldn't.  There are liable to be more of these as GIO grows, so I hope Mark has something in place to handle it.  Allowing aliases isn't something I'd do at all because of the ensuing headaches, but a low limit should help.

Duane


Glenn Glazer
 

On 01/30/2021 14:43, Duane wrote:
On Fri, Jan 29, 2021 at 04:07 PM, Bruce Bowman wrote:
Someone with malicious intent could even create hundreds just to fleece the system.
I remember/know of one case so far where a group wanting to move from Yahoo couldn't use the old group name.  A 'competitor' used it as an alias here just so the group moving couldn't.  There are liable to be more of these as GIO grows, so I hope Mark has something in place to handle it.  Allowing aliases isn't something I'd do at all because of the ensuing headaches, but a low limit should help.

Duane

I would agree with zero as the limit. Name squatting, like domain name squatting, is pretty evil.

Best,

Glenn

--
PG&E Delenda Est


 


I remember/know of one case so far where a group wanting to move from Yahoo couldn't use the old group name.  A 'competitor' used it as an alias here just so the group moving couldn't.  There are liable to be more of these as GIO grows, so I hope Mark has something in place to handle it.  Allowing aliases isn't something I'd do at all because of the ensuing headaches, but a low limit should help.

I would agree with zero as the limit. Name squatting, like domain name squatting, is pretty evil.
 
 
This group alias issue is one of those bits that can get somewhat complicated.

If the aim of the no-more or limited aliases is to disable or discourage/curb squatting (malevolent or not for that matter), that can easily be defeated and the same net effect achieved by smartly creating & configuring groups, it would just be a bit more work; you can't (easily) stop/discourage someone knowledgeable from malevolently doing what that owner did, neither here nor on the net. 

You can however monitor them for recurring/suspect behavior.

I don't want to start a philosophical discussion on the ethics of group name (or domain) parking, there are valid points from both sides of the debate.  Plus after all, Mark implemented it here (and it has remained, so far), apparently it must have some type of value to him.  I don't know the origins, maybe it was just a convenience gifted to the paid groups due to an Enterprise request, I don't know; only Mark knows about the value of this feature to him and whether taking it away could present the potential impact of removing a convenience feature for prospective clients.  And if applied retroactively it could cause complications to existing Enterprise groups using it, so if that was to be avoided it may be yet another grandfathered thing now that needs tracking.

Cheers,
Christos

PS: One of my other selves, the green-eyed one, whispered to my ear "paid optional feature", but he's known to be a troublemaker, I don't know, maybe I should throw him out of the room.


Duane
 

On Sat, Jan 30, 2021 at 08:09 PM, Christos G. Psarras wrote:
I don't know the origins, maybe it was just a convenience gifted to the paid groups due to an Enterprise request
Probably.  It was originally only available on Enterprise groups:

On Wed, Nov 23, 2016 at 05:38 PM, Mark Fletcher wrote:
NEW: For enterprise groups, you can set up group aliases, which redirect to your group (for misspellings, prevent sound-alike squatters, etc).
A few months later, it was allowed on Premium groups:

On Fri, Mar 3, 2017 at 11:11 PM, Mark Fletcher wrote:
CHANGE: Premium plans now support having group aliases (previously this was an Enterprise plan only feature).
Duane