If users can't edit an article, don't encourage them to edit its Wikidata item

List overview All Threads
Download

newer

older

Phabricator monthly statistics -...

Was macht dich diese Woche...

David Abián

28 Oct 2018 28 Oct '18

10:53 p.m.

Hi, I'm sending this email to request your help with... https://phabricator.wikimedia.org/T207648 We don't want non-confirmed users to see links from semiprotected Wikipedia articles to their corresponding Wikidata items. This is a well-known source of vandalism (and bad press) that is seriously affecting Wikidata and some Wikipedias. As Lydia describes on T205783, "When contentious topics show up in the news vandalism on the Wikipedia articles related to it usually shows up pretty quickly. The article then might be protected for some time in order to prevent more vandalism. A pattern we are seeing now is that people then move over to Wikidata and continue their vandalism there. (This might then in turn lead to vandalism showing up in the article anyway if it uses the data.) This especially happens when an infobox has "edit on Wikidata" links or something similar. We need to find a way to make this attack vector less of a problem." We don't want to hide these links from everyone, just from non-confirmed users. We could write CSS rules for certain user groups, but this can bring undesired side effects like giving all users the possiblity of hiding arbitrary content (e.g., vandalism) from other users who should be able to see it. We also have `mw.title.protectionLevels["edit"]` in Lua, but this option is documented as "expensive" and I can't guess what its impact could be if applied on a large scale. Any action or suggestion on how to achieve this is more than welcome. Thanks in advance! -- David Abián

Show replies by date

nguyen dinh truong nguyen

29 Oct 29 Oct

1:47 a.m.

Thank you, I think that it is vandalism of victor Charlie (slang in vn war) On 29 Oct 2018 04:53, "David Abián" <davidabian(a)wikimedia.es> wrote:

...

Daniel Kinzler

2:18 p.m.

Am 28.10.2018 um 22:53 schrieb David Abián:

...

We don't want to hide these links from everyone, just from non-confirmed users. We could write CSS rules for certain user groups, but this can bring undesired side effects like giving all users the possiblity of hiding arbitrary content (e.g., vandalism) from other users who should be able to see it.

How exactly could that be abused? CSS rules seem the best approach to me.

...

We also have `mw.title.protectionLevels["edit"]` in Lua, but this option is documented as "expensive" and I can't guess what its impact could be if applied on a large scale.

I don't see how this can work with the parser cache. The Lua code runs once every time the page is purged. The result is then shown to everyone. The code does not run per user. I assume you would still want to show the link to users who actually do have the right to edit. -- Daniel Kinzler Principal Software Engineer, MediaWiki Platform Wikimedia Foundation

David Abián

6:59 p.m.

Hi,

...

I assume you would still want to show the link to users who actually do have the right to edit.

Yes, that's it.

...

How exactly could that be abused? CSS rules seem the best approach to me.

First I thought on introducing something like `.myclass{display:none;}` in [[MediaWiki:Common.css]] and `.myclass{display:inline;}` in [[MediaWiki:Group-autoconfirmed.css]], but this would let users freely hide arbitrary content from newbies on any Wikimedia page (Wikipedia articles, user pages, etc.) by using <div class="myclass">...</div>. Although this permission hierarchy would be theoretically correct (trusted users would see more things than newbies, not the opposite), we probably don't want to offer this "feature" by default with the solution to T207648. On the other hand, this would only solve the task of identifying when a user is autoconfirmed. However, I like <https://phabricator.wikimedia.org/T207648#4701665>, which would combine the information about the protection status and the user groups. With this solution we wouldn't introduce the "feature" of selectively hiding arbitrary content from certain users on any page. This class may be included only in [[MediaWiki:Common.css]], where we could define rules body.myclass (the element body isn't allowed in wikitext). We could also tweak the HTML code of the Wikidata links in a similar way, but that might be already exaggerated. -- David Abián

Pine W

7:29 p.m.

I'm hesitant to support hiding information from readers, including links to Wikidata. As an alternative to hiding information, could articles that are semi-protected on Wikipedia (I assume that this refers to ENWP, but perhaps it refers to other languages also) automatically have semi-protection applied to the relevant items on Wikidata? Pine ( https://meta.wikimedia.org/wiki/User:Pine )

David Abián

7:58 p.m.

Vandalism mainly comes from es.wikipedia, but more Wikipedias are affected. What you suggest was proposed by Lydia at <https://phabricator.wikimedia.org/T205783> considering a threshold of N Wikipedias. El 29/10/18 a las 19:29, Pine W escribió:

...

-- David Abián

Pine W

8:06 p.m.

OK, so that makes at least two of us thinking along those lines. I suggest that you cross-post this discussion to the Wikidata email list to invite more people to participate in this discussion. Thanks for bringing up this subject for discussion. I am not fond of vandals. Pine ( https://meta.wikimedia.org/wiki/User:Pine ) On Mon, Oct 29, 2018 at 6:58 PM David Abián <davidabian(a)wikimedia.es> wrote:

...

I'm hesitant to support hiding information from readers, including links

Wikidata. As an alternative to hiding information, could articles that

are

semi-protected on Wikipedia (I assume that this refers to ENWP, but

perhaps

it refers to other languages also) automatically have semi-protection applied to the relevant items on Wikidata?

-- David Abián _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Daniel Kinzler

11:06 p.m.

Am 29.10.18 um 7:29 nachm. schrieb Pine W:

...

Does this only apply to the "connected" data item, or all data items used? Note that some items are used on a *lot* of pages, and would end up always protected. Maybe that'S good, if they are used so much, don't know. It would be hard to see on Wikidata why they are protected, though. Also, I cannot think of an efficient way to manage this information in the database. Also, would you also want this the other way around? If the data item is protected, the respective page on all wikis should be automatically protected? -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation

Amir E. Aharoni

11:34 p.m.

Including information from Wikidata in a page is not so different from transcluding a template. So in theory, protecting a page from vandalism through Wikidata should be similar to cascading protection, which exists in core and auto-protects images and transcluded templates on a page. In fact, maybe cascading protection should simply apply to transcluded items. Of course, it's more difficult to extend cascading protection to Wikidata because Wikidata is a different wiki (even Commons images are not included in cascading protection last time I checked). Nevertheless, it should be a goal. And maybe—just maybe—getting blocked on one wiki could make one automatically blocked on wikis that are common repositories, such as Commons and Wikidata (and perhaps Meta), although this should be reversible. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬ ‫בתאריך יום ג׳, 30 באוק׳ 2018 ב-0:06 מאת ‪Daniel Kinzler‬‏ <‪ dkinzler@wikimedia.org‬‏>:‬

...

Am 29.10.18 um 7:29 nachm. schrieb Pine W:

I'm hesitant to support hiding information from readers, including links

Wikidata. As an alternative to hiding information, could articles that

are

semi-protected on Wikipedia (I assume that this refers to ENWP, but

perhaps

it refers to other languages also) automatically have semi-protection applied to the relevant items on Wikidata?

Daniel Kinzler

30 Oct 30 Oct

12:37 a.m.

Am 29.10.2018 um 23:34 schrieb Amir E. Aharoni:

...

And maybe—just maybe—getting blocked on one wiki could make one automatically blocked on wikis that are common repositories, such as Commons and Wikidata (and perhaps Meta), although this should be reversible.

I like that idea, actually. It could just be a block option. -- Daniel Kinzler Principal Software Engineer, MediaWiki Platform Wikimedia Foundation

Brad Jorsch (Anomie)

4:49 p.m.

On Mon, Oct 29, 2018 at 6:35 PM Amir E. Aharoni < amir.aharoni(a)mail.huji.ac.il> wrote:

...

Of course, it's more difficult to extend cascading protection to Wikidata because Wikidata is a different wiki (even Commons images are not included in cascading protection last time I checked). Nevertheless, it should be a goal.

I'm not so sure of that. Some admin on a tiny, little-watched wiki then could cascade-protect arbitrary Commons images and Wikidata items by overusing cascade protection despite not having adminship on Commons or Wikidata.

...

Same problem. We'd likely wind up having to have Stewards start policing the use of cascade protection and blocking on all wikis to adjudicate whether one wiki's use of cascade protection or blocking was really trying to disrupt Commons/Wikidata/Meta. -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

David Abián

1 Nov 1 Nov

12:12 a.m.

Probably some of you can help with... https://phabricator.wikimedia.org/T208315 (MediaWiki) ... or... https://phabricator.wikimedia.org/T208279 (Wikibase). These tasks seem feasible and uncontroversial. Thanks! -- David Abián

2003

days inactive

2006

days old

wikitech-l@lists.wikimedia.org

Manage subscription

11 comments

6 participants

tags (0)

participants (6)

Amir E. Aharoni
Brad Jorsch (Anomie)
Daniel Kinzler
David Abián
nguyen dinh truong nguyen
Pine W