Last modified: 2007-07-06 02:13:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5214, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3214 - Commons: Restricted ability to override files to prevent vandalism
Commons: Restricted ability to override files to prevent vandalism
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement with 27 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
-
: shell
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-20 22:07 UTC by bdk
Modified: 2007-07-06 02:13 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description bdk 2005-08-20 22:07:35 UTC
Wikimedia Commons: 
Because of increasing image vandalism which affects many other projects I would like to propose 
a restriction of some abilities of new users on Commons. In particular overriding of files and restoring 
of old versions should be disabled until a new user has at least 10 accepted file uploads.
Comment 1 Patrick-Emil Zörner 2005-08-20 22:10:12 UTC
The vandalism on commons is starting. Now people will say that it is nothing new
and that they have vandals and trolls everywhere on their Wikimedia-Projects.
But commons is first of all a baby and one of the youngest projects. Commons
goal is to provide pictures and other media for many Wikimedia projects. If one
central media file is vandalised it means that it inevitably will strike several
other more or less prominent projects. Commons has too few administrators to do
solve problems within seconds. Media is cached so long, that you get a porn
picture even though it originally was not (see the puss/ass user that constantly
uploads disgusting images). Only solution is editing the page with no
contribution to get rid of the cache problem.

I therefore agree with Bdk.
Comment 2 bdk 2005-08-20 22:51:43 UTC
(In reply to comment #0)
Related reference: Compare the restriction of the right to move pages for new users on at least de.wikipedia (for the 
latest 1 % of new users) - also to prevent vandalism by multiple movement of pages. 
Comment 3 David Benbennick 2005-08-22 15:35:42 UTC
Sounds like a good idea.  I guess "at least 10 accepted file uploads" could mean
something like "the user's tenth upload occurred at least a week ago".  That
would mean the AP vandal would have to invest non-trivial effort to create an
account that could be used for vandalism.
Comment 4 bdk 2005-08-22 16:25:53 UTC
(In reply to comment #3)
Yes, of course. The formulation "at least 10 ..." was meant just as an example to give an approximate value. 

Comment 5 Elke Wetzig 2005-08-24 21:36:22 UTC
Pro - sounds reasonable, especially because many prestigious projects are concerned by only one vandal attac over 
here. I would approve an even more restrictive rule than "only" 10 edits.   
Comment 6 Dan100 2005-08-24 22:35:36 UTC
This would be a godsend. Please any devs out there, take this challenge on! We'd 
love you forever.
Comment 7 Aka 2005-09-04 18:38:49 UTC
Strong support, I really hate this crazy AP guy ...
Comment 8 Ian Woollard 2005-12-27 15:58:58 UTC
I think this bug is too vague. Exactly what rights should new users have and not
have?
Comment 9 bdk 2005-12-27 16:32:20 UTC
(In reply to comment #8)
changed summary to clarify

This bug only is about one specific right: 
Users should not be able to override files and to restore old versions until 
they have at least x file uploads in their contributions (perhaps in addition: 
and the last upload occurred at least x days ago). If many/all files of a user 
were deleted and the number was reduced to under x again, the user also 
loses this right again. 

Leave the specification of "x" or further decisions to our developers ;-)
Comment 10 Brion Vibber 2005-12-28 15:25:10 UTC
Currently all wikimedia wikis are set to restrict overwrite-uploads to accounts meeting the automatic confirmation criteria (currently set to 4 days delay since registration).
Comment 11 Chris McKenna 2005-12-30 23:32:41 UTC
The x good image uploads at least y days ago would be very useful for dealing
with vandals at commons, as registering a sleeper account and waiting 4 days is
comapatively trivial. 

I would also suggest suggest limiting the number of overwrite uploads to 1 per
24 hours for non-administrators. If flexible permissions are invovled this right
could be awarded to users short of adminship if desired - but that can come later.
Comment 12 Erik Moeller 2005-12-31 17:56:21 UTC
Chris: I'm against implementing more than one hard security mechanism at the
same time. There are legitimate reasons to make multiple overwrites in a short
period. We should also consider soft security mechanisms. They tend to be more
complex to implement, especially those involving time delays, but better
monitoring would help already. For starters, Special:Newimages could provide a
filter to view only overwrites, and also highlight them in the general list.
Comment 13 Daniel Kinzler 2006-02-16 00:32:28 UTC
As of now, new users (new than four days, i think), are not allowed to overwrite
existing files. Maybe that's close enough to what is requested here, and this
bug can be closed.

Anyway, I'd suggest to allow "restricted" users to overwrite their own uploads.
Comment 14 Aaron Schulz 2007-07-06 02:13:55 UTC
(In reply to comment #13)
> As of now, new users (new than four days, i think), are not allowed to overwrite
> existing files. Maybe that's close enough to what is requested here, and this
> bug can be closed.
> 
> Anyway, I'd suggest to allow "restricted" users to overwrite their own uploads.

OK, closing this.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links