Hi,
Someone on IRC, I forget who, suggested that we should end this ability to upload new revisions of images. I agree.
It's something vandals can use to alter articles without affecting the watchlist; it also means that when looking at an old version of a page, you don't necessarily see what content was there at the time.
In addition, the image usage (with reversions, etc) is quite tricky, and there seem to be some caching problems that can lead to people seeing an old version.
I suggest that we simply change the system so that, if you want to upload an image, you must give it a unique filename. You can then alter articles as necessary to link to the new version.
On Wednesday 20 October 2004 05:35, Allan Crossman wrote:
Someone on IRC, I forget who, suggested that we should end this ability to upload new revisions of images. I agree.
Sounds a good idea. How could I immediately implement it in my mediawiki installation?
Without expressing any particular opinion on this topic, I merely offer the following datapoint.
Yesterday, I took a photo of George Bush and uploaded it, and linked it into the article. Someone else at the same event (small world) did the same, changed the photo in the article to his instead of mine. No problem.
But, his photo, when I clicked on it, appeared as a vandal photo. That is, the thumbnail in the article was fine, but the photo underneath was bad.
At one point, I checked the history of that photo, and all revisions were from the same person, and all were evil. However, this does not seem to be the case in reality... the reality is, there was a caching problem... (?)
The poor other fellow almost got blocked by me for vandalism, it's just that I usually try not to block people if I'm the least bit confused, because since it is me, people will take notice and I'm the last person to want to violate any rules. :-)
When I got home to research it more, (a) I still saw the bad photo on my laptop, which had *NOT* looked at this article before, ever. This implies that the caching problem was not a local browser cache! and (b) the history now looked accurate, showing the original, the vandalism, and the fix.
Anyhow, my sense of things is just that it's hard for editors who are trying to combat photo vandalism to figure out what is going on.
--Jimbo
p.s. Separately, my wife called me while I was driving home, and she had looked at the article on her computer, and in her case she saw the goatse.cx image there. this was not a caching issue nor was it the same issue at all, but just routine vandalism. I am more convinced than ever now that we need a "soft protect" mode of "slow publishing" for certain very very popular and very very important articles.
By "slow publishing" this is not my idea, but one that has been discussed as far back as when I was in Berlin at least... the idea is that the latest version of an article is only shown on the main url once it is 10 minutes old, or if a sysop deliberately clicked on 'publish now'. This gives a rolling window to combat stupid vandalism, rather than having it on the site for even 3 minutes.
Jimmy (Jimbo) Wales wrote:
But, his photo, when I clicked on it, appeared as a vandal photo. That is, the thumbnail in the article was fine, but the photo underneath was bad.
It seems you are referring to Bug 743 (http://bugzilla.wikipedia.org/show_bug.cgi?id=743) - the image rollback functionality seems to be broken, instead of restoring the old version it overrides the old version with the current one - thus spreading the bad revision instead of hiding it. Day before yesterday the same happened, and I had to reupload the image to solve the problem. But as the same happended yesterday this vandal must be rather persistant, and the bug rather high priority.
Bye, Andy
Jimmy (Jimbo) Wales wrote:
p.s. Separately, my wife called me while I was driving home, and she had looked at the article on her computer, and in her case she saw the goatse.cx image there. this was not a caching issue nor was it the same issue at all, but just routine vandalism. I am more convinced than ever now that we need a "soft protect" mode of "slow publishing" for certain very very popular and very very important articles.
Adding this extra layer of tweakability between "not protected" and "protected" might be useful, however it is not the solution to the problem you describe - even if an article is fully protected a clever vandal can still upload trash to replace an image that appears on a protected page.
Allan's solution - disallow overwriting of images - would solve the problem completely, be trivial to implement (we already check for pre-existing pictures of the same filename), and has only the minor drawback of perhaps using a bit of extra disc space now and then.
I urge that it be implemented as soon as is practicable)
Pete
(Sidenote: "Clever vandals" who can figure out how to pull this trick are more dangerous than stupid vandals. They are thus rightly normally given very short latitude before banning, although with proxy ips abounding we still need the technical solution outlined above).
On Wed, 2004-20-10 at 23:00 +0100, Pete/Pcb21 wrote:
Allan's solution - disallow overwriting of images - would solve the problem completely, be trivial to implement (we already check for pre-existing pictures of the same filename), and has only the minor drawback of perhaps using a bit of extra disc space now and then.
One benefit of being allowed to overwrite files is that correcting an image will update that image in all articles that use it, automatically.
Perhaps Allan's real solution was hidden in his proposal. He said, "It's something vandals can use to alter articles without affecting the watchlist;". I'd suggest that we modify the watchlist feature to add a watchlist entry when an image that a page uses is changed.
This way, rather than taking features away from good users to punish bad ones, we enhance everyone's ability to monitor changes.
~ESP
I have submitted this as bug #778 on bugzilla.wikipedia.org
--Guttorm --- Evan Prodromou evan@wikitravel.org wrote:
Perhaps Allan's real solution was hidden in his proposal. He said, "It's something vandals can use to alter articles without affecting the watchlist;". I'd suggest that we modify the watchlist feature to add a watchlist entry when an image that a page uses is changed.
This way, rather than taking features away from good users to punish bad ones, we enhance everyone's ability to monitor changes.
~ESP
-- Evan Prodromou evan@wikitravel.org
Pete/Pcb21 wrote:
Allan's solution - disallow overwriting of images - would solve the problem completely, be trivial to implement (we already check for pre-existing pictures of the same filename), and has only the minor drawback of perhaps using a bit of extra disc space now and then.
I don't like this solution at all---overwriting images is frequently used to upload revisions of images while leaving a revision history. For example, maps may be edited, darkened/lightened, or otherwise tweaked, and it's useful to have the revision history available, or to be able to roll back to a previous revision.
If there's a problem with a particular image, we could instead use protection of images analogous to the protection on pages, rather than throwing the whole revision system out.
-Mark
Allan-
Hi,
Someone on IRC, I forget who, suggested that we should end this ability to upload new revisions of images. I agree.
Absolutely not. Images should be treated like regular wiki pages, otherwise we will give up much of the collaboration potential that is there. For example, it is quite feasible to create an interface for loading an image into an external application and uploading it transparently back to the server: http://www.zope.org/Members/Caseman/ExternalEditor
The process will be like this:
1) You load a page like [[Image:Diagram.svg]] 2) Below the page there will be an "edit this image in an external application" link 3) After clicking this link, the server sends you a file with a MIME type associated with a helper application 4) The helper application loads the file into an image editor like Freehand or Inkscape 5) You make changes to the image, save it, close the application 6) The helper application asks you for an edit comment and gives you a last chance to abort the edit 7) If you do not, the new image is uploaded to the server. (Optionally, the helper application could tell your browser to load the post-upload URL.)
Now, with an image history working like a page history, that process is fairly obvious and transparent. An image can easily have 50 different revisions without you having to track down the filename of each of them.
Question: Is there some library we could use to show the differences between two bitmap images?
Regards,
Erik
wikitech-l@lists.wikimedia.org