Various types and means of account blocks

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Various types and means of account blocks

Frederik Ramm
Hi,

I would like to start a discussion/brainstorming about the technical
aspects and means of blocking OSM user accounts.

First of all, the wider OSM community uses a wealth of communications
channels, most of which are not even controlled by us; here I just want
to discuss the actual OSM account and the means of communication
associated with that.

Currently an account can be blocked (by the DWG for a limited time, or
by admins for arbitrary timespans). There's a UI for that (even though I
think the long-term blocks need manual database fiddling). A blocked
user cannot edit OSM data. They can, however, still use the various
communication functions: write personal messages, write or comment on
diary entries, comment on changesets, and open, close, and comment on
notes. And they can modify their user page, change their account name,
and "befriend" other users.

Currently, if we wanted to keep someone from using these functions, we'd
have to "suspend" the account altogether, which is almost the same as
deleting it: The account will not be visible any more, at all, and
nobody can log in to it (cf. discussion in
https://github.com/openstreetmap/openstreetmap-website/issues/1946).

OSM has largely been spared from obnoxious nutcases that you find online
elsewhere, but our increasing popularity will certainly send a couple of
them our way in the future.

Some examples of borderline behaviour that we have seen in the past:

* user creating tons of playful/funny notes, and modifying his user name
several times a day

* user closing 100s of notes without actually doing something about them

* user "stalking" another user in changeset comments, writing rant-y
comments in response to everything the other user writes

* user writing longish, rant-y, unwanted, and off-topic diary comments
 to third party's diary entries

* user sending legal threats to other users in personal messages

* user adding a "shit list" to his profile page listing the account
names of other mappers they don't like

I wonder what the best way would be to deal with issues like that. The
ticket I quoted above is from a DWG member suggesting that normal user
blocks should simply be extended to block all the "communication"
functions as well. In the discussion it was suggested that someone
blocked for, say, participating in an edit war, should not necessarily
be prevented from writing and receiving messages.

Is the opposite true as well - would/should someone given a cool-off
period for being a dick in a discussion still be allowed to do mapping?

Should a normal user block perhaps simply come in two flavours, "block
mapping only" and "block all"?

It has been suggested that blocking *all* communication functions might
be problematic because one thing you might expect from someone you have
blocked is that they apologise, or set something right, which they might
not be able to do without the ability to write messages.

Do we need a full array of permissions - "can change user name", "can
edit own user page", "can write personal messages", etc. - and the
ability to short-time suspend any and all of them?

Thoughts are welcome.

This also ties in somewhat with a separate discussion, on how a
prerequisite for allowing children on the platform might be that we can
disable the "social" functions of an account. In that case it would not
be a short-term block, but a whole class of accounts that can edit, but
not participate in discussions (for their own protection). I'm not sure
that can work at all (given that the ability to contact a mapper is very
important to us). Maybe such accounts would have to be linked to a
"responsible" parent account who then gets the messages...

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Various types and means of account blocks

ika-chan! (OpenStreetMap)
There are two common types of account blocks on MediaWiki, which could form the basis for the proposed reform:

1. A block where a user cannot edit any page except their own talk page.
2. A block where a user cannot edit any page at all.

So on OSM, it would be:

1. Editing block
2. Full block

I think that should take care of it.

— ika-chan!

> On 24 Sep 2018, at 16:57, Frederik Ramm <[hidden email]> wrote:
>
> Hi,
>
> I would like to start a discussion/brainstorming about the technical
> aspects and means of blocking OSM user accounts.
>
> First of all, the wider OSM community uses a wealth of communications
> channels, most of which are not even controlled by us; here I just want
> to discuss the actual OSM account and the means of communication
> associated with that.
>
> Currently an account can be blocked (by the DWG for a limited time, or
> by admins for arbitrary timespans). There's a UI for that (even though I
> think the long-term blocks need manual database fiddling). A blocked
> user cannot edit OSM data. They can, however, still use the various
> communication functions: write personal messages, write or comment on
> diary entries, comment on changesets, and open, close, and comment on
> notes. And they can modify their user page, change their account name,
> and "befriend" other users.
>
> Currently, if we wanted to keep someone from using these functions, we'd
> have to "suspend" the account altogether, which is almost the same as
> deleting it: The account will not be visible any more, at all, and
> nobody can log in to it (cf. discussion in
> https://github.com/openstreetmap/openstreetmap-website/issues/1946).
>
> OSM has largely been spared from obnoxious nutcases that you find online
> elsewhere, but our increasing popularity will certainly send a couple of
> them our way in the future.
>
> Some examples of borderline behaviour that we have seen in the past:
>
> * user creating tons of playful/funny notes, and modifying his user name
> several times a day
>
> * user closing 100s of notes without actually doing something about them
>
> * user "stalking" another user in changeset comments, writing rant-y
> comments in response to everything the other user writes
>
> * user writing longish, rant-y, unwanted, and off-topic diary comments
> to third party's diary entries
>
> * user sending legal threats to other users in personal messages
>
> * user adding a "shit list" to his profile page listing the account
> names of other mappers they don't like
>
> I wonder what the best way would be to deal with issues like that. The
> ticket I quoted above is from a DWG member suggesting that normal user
> blocks should simply be extended to block all the "communication"
> functions as well. In the discussion it was suggested that someone
> blocked for, say, participating in an edit war, should not necessarily
> be prevented from writing and receiving messages.
>
> Is the opposite true as well - would/should someone given a cool-off
> period for being a dick in a discussion still be allowed to do mapping?
>
> Should a normal user block perhaps simply come in two flavours, "block
> mapping only" and "block all"?
>
> It has been suggested that blocking *all* communication functions might
> be problematic because one thing you might expect from someone you have
> blocked is that they apologise, or set something right, which they might
> not be able to do without the ability to write messages.
>
> Do we need a full array of permissions - "can change user name", "can
> edit own user page", "can write personal messages", etc. - and the
> ability to short-time suspend any and all of them?
>
> Thoughts are welcome.
>
> This also ties in somewhat with a separate discussion, on how a
> prerequisite for allowing children on the platform might be that we can
> disable the "social" functions of an account. In that case it would not
> be a short-term block, but a whole class of accounts that can edit, but
> not participate in discussions (for their own protection). I'm not sure
> that can work at all (given that the ability to contact a mapper is very
> important to us). Maybe such accounts would have to be linked to a
> "responsible" parent account who then gets the messages...
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> dev mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/dev


_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Various types and means of account blocks

Michael Reichert-3
In reply to this post by Frederik Ramm
Hi Frederik,

Am 24.09.2018 um 17:57 schrieb Frederik Ramm:
> Is the opposite true as well - would/should someone given a cool-off
> period for being a dick in a discussion still be allowed to do mapping?

No. Anyone who is able to edit the map data should be able and has to
answer sensible questions.

> Should a normal user block perhaps simply come in two flavours, "block
> mapping only" and "block all"?
>
> It has been suggested that blocking *all* communication functions might
> be problematic because one thing you might expect from someone you have
> blocked is that they apologise, or set something right, which they might
> not be able to do without the ability to write messages.

If we implement the new block type proposed by ika-chan!, the DWG can
place a type 1 block (editing block) on the account and tell him to
aplogoise. If the user fails to do so, it's a sign of bad intentions and
a full block can be placed.

> Do we need a full array of permissions - "can change user name", "can
> edit own user page", "can write personal messages", etc. - and the
> ability to short-time suspend any and all of them?
>
> Thoughts are welcome.
>
> This also ties in somewhat with a separate discussion, on how a
> prerequisite for allowing children on the platform might be that we can
> disable the "social" functions of an account. In that case it would not
> be a short-term block, but a whole class of accounts that can edit, but
> not participate in discussions (for their own protection). I'm not sure
> that can work at all (given that the ability to contact a mapper is very
> important to us). Maybe such accounts would have to be linked to a
> "responsible" parent account who then gets the messages...
I think that any mapper should have the possibility to ask another
mapper any question on their edits. Currently, we often place a 0-hour
block on accounts who fail to respond and continue editing. What shall I
myself as a mapper do if the user whose edits look strange cannot answer
my question why he deleted the restaurant? Shall he/she restore it
because the child does not respond?

The concept of hiding minors from communications might work if they are
asked/told to map just due to their ability to draw geometries, e.g. in
an enclosed system or for mapping a few villages in an area where no
data has been before and nobody else is mapping. But once they edit
existing data, "conflicts" (questions and comments) with the community
will arise.

It might be possible to solve these issues but figuring out solutions is
up to those who need minors below 16 years mapping.

Best regards

Michael


--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)


_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Various types and means of account blocks

SimonPoole

As way of a clarification: the LWG was not proposing to block children from answering on changeset comments (given these are public and not so easily misued), but not allowing access to the blog and the internal message system.

Simon


Am 24.09.2018 um 20:22 schrieb Michael Reichert:
Hi Frederik,

Am 24.09.2018 um 17:57 schrieb Frederik Ramm:
Is the opposite true as well - would/should someone given a cool-off
period for being a dick in a discussion still be allowed to do mapping?
No. Anyone who is able to edit the map data should be able and has to
answer sensible questions.

Should a normal user block perhaps simply come in two flavours, "block
mapping only" and "block all"?

It has been suggested that blocking *all* communication functions might
be problematic because one thing you might expect from someone you have
blocked is that they apologise, or set something right, which they might
not be able to do without the ability to write messages.
If we implement the new block type proposed by ika-chan!, the DWG can
place a type 1 block (editing block) on the account and tell him to
aplogoise. If the user fails to do so, it's a sign of bad intentions and
a full block can be placed.

Do we need a full array of permissions - "can change user name", "can
edit own user page", "can write personal messages", etc. - and the
ability to short-time suspend any and all of them?

Thoughts are welcome.

This also ties in somewhat with a separate discussion, on how a
prerequisite for allowing children on the platform might be that we can
disable the "social" functions of an account. In that case it would not
be a short-term block, but a whole class of accounts that can edit, but
not participate in discussions (for their own protection). I'm not sure
that can work at all (given that the ability to contact a mapper is very
important to us). Maybe such accounts would have to be linked to a
"responsible" parent account who then gets the messages...
I think that any mapper should have the possibility to ask another
mapper any question on their edits. Currently, we often place a 0-hour
block on accounts who fail to respond and continue editing. What shall I
myself as a mapper do if the user whose edits look strange cannot answer
my question why he deleted the restaurant? Shall he/she restore it
because the child does not respond?

The concept of hiding minors from communications might work if they are
asked/told to map just due to their ability to draw geometries, e.g. in
an enclosed system or for mapping a few villages in an area where no
data has been before and nobody else is mapping. But once they edit
existing data, "conflicts" (questions and comments) with the community
will arise.

It might be possible to solve these issues but figuring out solutions is
up to those who need minors below 16 years mapping.

Best regards

Michael




_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Various types and means of account blocks

tigerfell-688
In reply to this post by ika-chan! (OpenStreetMap)
Well, as outlined in GitHub, these concepts seem to exist already. Number 1 would be called "block" (you could still use the forum, I guess) and (2) "suspension" (everything hidden).
I would suggest (if not already present) to add an option to block a user from using the forum or their user page separately. (Later this could be extended to the wiki.)
I oppose the current practice of "suspensions", because I was once suspended for a diary entry, as it contained links (to the forum and the wiki only) and I had not made a map edit before, but my (approved) forum comments were not taken into consideration when suspended.
I would like to propose this to be more open and selective towards blocking certain functions only. Having a list of suspended accounts and reasons would be great (like the current practice for "blocks").
Considering minors: Frederik's suggestion to link accounts sounds good but also complicated. I mean the fact that the accounts linked needs to be hidden as well, right? Otherwise, someone could search for all minors...
Maybe, it would be sufficient to use the parent's email address and set a flag that this user cannot use the functions mentioned by itself (and not change the email address). So, the parent would receive the message and could answer to it directly (comparable to answering GitHub-notifications by mail)?
Replying to Frederik: Yes, there should be more selective permissions that also take other OSM services into account (Forum, maybe QA, in the future also Wiki) so it is more general.

Kind regards,
Tigerfell

24. Sep 2018 18:44 by [hidden email]:

There are two common types of account blocks on MediaWiki, which could form the basis for the proposed reform:

1. A block where a user cannot edit any page except their own talk page.
2. A block where a user cannot edit any page at all.

So on OSM, it would be:

1. Editing block
2. Full block

I think that should take care of it.

— ika-chan!
On 24 Sep 2018, at 16:57, Frederik Ramm <[hidden email]> wrote:

Hi,

I would like to start a discussion/brainstorming about the technical
aspects and means of blocking OSM user accounts.

First of all, the wider OSM community uses a wealth of communications
channels, most of which are not even controlled by us; here I just want
to discuss the actual OSM account and the means of communication
associated with that.

Currently an account can be blocked (by the DWG for a limited time, or
by admins for arbitrary timespans). There's a UI for that (even though I
think the long-term blocks need manual database fiddling). A blocked
user cannot edit OSM data. They can, however, still use the various
communication functions: write personal messages, write or comment on
diary entries, comment on changesets, and open, close, and comment on
notes. And they can modify their user page, change their account name,
and "befriend" other users.

Currently, if we wanted to keep someone from using these functions, we'd
have to "suspend" the account altogether, which is almost the same as
deleting it: The account will not be visible any more, at all, and
nobody can log in to it (cf. discussion in
https://github.com/openstreetmap/openstreetmap-website/issues/1946).

OSM has largely been spared from obnoxious nutcases that you find online
elsewhere, but our increasing popularity will certainly send a couple of
them our way in the future.

Some examples of borderline behaviour that we have seen in the past:

* user creating tons of playful/funny notes, and modifying his user name
several times a day

* user closing 100s of notes without actually doing something about them

* user "stalking" another user in changeset comments, writing rant-y
comments in response to everything the other user writes

* user writing longish, rant-y, unwanted, and off-topic diary comments
to third party's diary entries

* user sending legal threats to other users in personal messages

* user adding a "shit list" to his profile page listing the account
names of other mappers they don't like

I wonder what the best way would be to deal with issues like that. The
ticket I quoted above is from a DWG member suggesting that normal user
blocks should simply be extended to block all the "communication"
functions as well. In the discussion it was suggested that someone
blocked for, say, participating in an edit war, should not necessarily
be prevented from writing and receiving messages.

Is the opposite true as well - would/should someone given a cool-off
period for being a dick in a discussion still be allowed to do mapping?

Should a normal user block perhaps simply come in two flavours, "block
mapping only" and "block all"?

It has been suggested that blocking *all* communication functions might
be problematic because one thing you might expect from someone you have
blocked is that they apologise, or set something right, which they might
not be able to do without the ability to write messages.

Do we need a full array of permissions - "can change user name", "can
edit own user page", "can write personal messages", etc. - and the
ability to short-time suspend any and all of them?

Thoughts are welcome.

This also ties in somewhat with a separate discussion, on how a
prerequisite for allowing children on the platform might be that we can
disable the "social" functions of an account. In that case it would not
be a short-term block, but a whole class of accounts that can edit, but
not participate in discussions (for their own protection). I'm not sure
that can work at all (given that the ability to contact a mapper is very
important to us). Maybe such accounts would have to be linked to a
"responsible" parent account who then gets the messages...

Bye
Frederik

--
Frederik Ramm ## eMail [hidden email] ## N49°00'09" E008°23'33"

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev


_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Various types and means of account blocks

Frederik Ramm
Hi,

On 24.09.2018 21:05, [hidden email] wrote:
> Well, as outlined in GitHub, these concepts seem to exist already.
> Number 1 would be called "block" (you could still use the forum, I
> guess) and (2) "suspension" (everything hidden).

Yes. The "everything hidden" bit is very confusing though. One example
from the recent past:

https://www.openstreetmap.org/changeset/62773816

There used to be a changeset comment there. The user, and his comment,
were then kicked out. The response to his comment remains, though,
without any apparent motivation.

It would be better to have "(a comment by user X has been removed)" or so.

I guess if someone sets up an account just for adding a spam profile, it
would be ok to remove them without a trace, but once they've
participated in any way (and potentially provoked a response, like
here), you can't really act as if they never existed.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Various types and means of account blocks

Frederik Ramm
Hi,

On 26.09.2018 10:43, Frederik Ramm wrote:
> https://www.openstreetmap.org/changeset/62773816

Uh, the "discussion" there is currently taking a xenophobic turn that
will lead to more removals maybe it wasn't a good example.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Various types and means of account blocks

Mateusz Konieczny-3
In reply to this post by Frederik Ramm
Overall I would look at how Wikipedia solves it from technical viewpoint.

It is (hopefully) unlikely that we will get more vandals and trolls than English-language
wikipedia and they already spend quite significant effort on policing dedicated vandals.

24. Sep 2018 17:57 by [hidden email]:

Is the opposite true as well - would/should someone given a cool-off
period for being a dick in a discussion still be allowed to do mapping?


Absolutely no. It would give such person way to say "I was reverting you without

attempt to communicate because that was blocked".


That is just asking for trouble.


Should a normal user block perhaps simply come in two flavours, "block
mapping only" and "block all"?

It has been suggested that blocking *all* communication functions might
be problematic because one thing you might expect from someone you have
blocked is that they apologise, or set something right, which they might
not be able to do without the ability to write messages.


I agree, blocking mapping only may be really useful. For example user

refusing to communicate in changeset discussions may be blocked until (s)he

responds to comments.

 

Do we need a full array of permissions - "can change user name", "can
edit own user page", "can write personal messages", etc. - and the
ability to short-time suspend any and all of them?


How complicated would be implementing it? I can imagine situation where otherwise

unproblematic editor changes his username 20 times a day and blocking this

resolves the problem - but how much effort is needed to implement this compared

to say three groups "nuke user" (for spam and troll-only accounts), "block all",

"block mapping"?

 

This also ties in somewhat with a separate discussion, on how a
prerequisite for allowing children on the platform might be that we can
disable the "social" functions of an account. In that case it would not
be a short-term block, but a whole class of accounts that can edit, but
not participate in discussions (for their own protection). I'm not sure
that can work at all (given that the ability to contact a mapper is very
important to us). Maybe such accounts would have to be linked to a
"responsible" parent account who then gets the messages...

Bye
Frederik

--
Frederik Ramm ## eMail [hidden email] ## N49°00'09" E008°23'33"

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Various types and means of account blocks

Michael Reichert-3
Hi,

Am 26.09.2018 um 17:35 schrieb Mateusz Konieczny:

> 24. Sep 2018 17:57 by [hidden email] <mailto:[hidden email]>:
>> Do we need a full array of permissions - "can change user name", "can
>> edit own user page", "can write personal messages", etc. - and the
>> ability to short-time suspend any and all of them?
>
> How complicated would be implementing it? I can imagine situation where otherwise
> unproblematic editor changes his username 20 times a day and blocking this
> resolves the problem - but how much effort is needed to implement this compared
> to say three groups "nuke user" (for spam and troll-only accounts), "block all",
> "block mapping"?
If a user changes his username too frequently, I wonder if he has the
maturity required to edit OpenStreetMap in a productive way. Changing
the username frequently makes following the changes and analysing the
edits more difficult than necessary. Some drafts of the Organised
Editing Policy forbid frequent changes of usernames for a very good
reason (i.e. violating this rule might end in a ban).

Best regards

Michael

--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)


_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev

signature.asc (836 bytes) Download Attachment